Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to Parcel #57

Closed
wants to merge 4 commits into from
Closed

Migrate to Parcel #57

wants to merge 4 commits into from

Conversation

101arrowz
Copy link
Member

@101arrowz 101arrowz commented Sep 26, 2023

Apologies for the large change, but the majority of this diff is from the lockfile. I thought it would be a good idea to move off of Create React App since I need to refactor most of the build tooling anyway to make things work nicely with Node.js.

I understand if switching the build tooling entirely is too big a change to make, but we will need to sacrifice a lot of developer experience on the server-side code if we stay with CRA. This change makes hot reload on the frontend dramatically faster, and it obviously makes backend HMR much more doable.

I did consider using ts-node-dev in parallel with the current CRA infrastructure, but I don't think it would be nearly as nice for DX. If you don't like this change we can do that instead though.

I'll highlight the parts of this diff that actually should get reviewed; the rest aren't very relevant.

@@ -1 +1,2 @@
REACT_APP_GOOGLE_CLIENT_ID=706375540729-sqnnig7o0d0uqmvav0h8nh8aft6l55u3.apps.googleusercontent.com
API_BASE=https://hydrant.xvm.mit.edu
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably need to use a separate xvm instance to do the server properly, unless we want to implement it all in CGI. @psvenk thoughts?

@@ -0,0 +1,64 @@
const { Reporter } = require('@parcel/plugin');
const { fork } = require('child_process');
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a small plugin to relaunch the server whenever you update the code. It's much more consistent than something like nodemon and not too hard to read.

@@ -32,7 +32,7 @@ function TypeSpan(props: { flag?: string; title: string }) {
<Image
alt={title}
boxSize="1em"
src={`img/${flag}.gif`}
src={flagURLs[flag]}
Copy link
Member Author

@101arrowz 101arrowz Sep 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get the old static links back if needed but this (i.e. letting Parcel generate URLs for assets) is the way Parcel suggests because it works better w.r.t. caching.

return 'Hello world!';
})

for (const file in data) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably going to change to something more robust eventually. I was thinking of migrating all the scraping stuff into the Node.js backend so we'd have a single codebase for everything; does that seem reasonable?

Copy link
Member

@cjquines cjquines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i will as a matter of principle block this PR until more of how to develop is documented in the README.md, i think.

it doesn't have to be much, but enough that someone who doesn't care about the backend can spin up the frontend to work on it. the ideal would even be to explain how the backend works to someone who knows nothing about servers.

this is a big PR and can be split into several PRs:

  • upgrading node to 18, which will need to touch the github workflows
  • adding eslint, and fixing the codebase so there are no errors
    • (while we're at it, get prettier… the formatting in these files is inconsistent)
  • importing the images rather than referring to them by url
  • setting up a fastify server, setting it up to serve the files properly, setting up a deployment workflow, testing it, making sure it works, and documenting all this
    • (which can be done independently of ejecting from c-r-a! and probably should)
  • moving the frontend to parcel (and touching the github workflows, etc)

i don't actually care if it gets split up or not, i'll leave that to other maintainers. my major blocker is that this needs to be documented better. (my minor blocker is that we need to get prettier and make sure all our files end with newlines…)

@cjquines
Copy link
Member

also thanks for the work!!

@101arrowz
Copy link
Member Author

Updated the docs a little but they're obviously not close to done. I'd like to be able to make the backend switch incrementally in a few separate PRs by the way; could you make a feature branch (node-backend or something) so I can PR to that without screwing up the main branch in the meanwhile? That should also make the incomplete docs less of an issue.

@101arrowz
Copy link
Member Author

As you mentioned it would be a good idea to get Prettier set up and make the Fastify backend actually work in a separate PR, but I'd prefer to do that after this is merged to avoid merge conflicts.

Also, it's possible (but a pretty big pain) to undo some of the changes that aren't strictly related to Parcel (e.g. the beginnings of the backend) and redo them in a PR without ejecting CRA. I decided to do them in one go because the backend's development lifecycle actually depends on Parcel too, and doing them separately would've been pretty annoying, but I can still undo it if needed.

@101arrowz
Copy link
Member Author

FYI I started some work on the Fastify server. Zod + Fastify is so much nicer to work with than Express!

Copy link
Member

@cjquines cjquines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unblocking, will leave someone else to approve

@cjquines cjquines self-requested a review September 28, 2023 03:01
@cjquines cjquines self-requested a review September 28, 2023 03:01
@psvenk psvenk self-requested a review October 2, 2023 22:57
@dtemkin1
Copy link
Collaborator

dtemkin1 commented Dec 5, 2024

Hi! Is there any desire to rebase this PR on main? Migrating off of CRA would be really nice, but if not, I can open a new pull request

@dtemkin1 dtemkin1 mentioned this pull request Dec 8, 2024
dtemkin1 added a commit that referenced this pull request Dec 10, 2024
Working with CRA is a bit of a pain and there's been work to move off of
it. I didn't update #57 since that involves the creation of a backend
server too (which involves setting up XVM and all that) and this is more
of an instant change, although rebasing that PR too would be good (maybe
over IAP when ppl have more time?).

This PR moves off of CRA and moves to Vite. This also involves having to
recreate some of the tooling integrated into CRA, such as an eslint
config (a lot of the diffs in component files were issues flagged by
tseslint that weren't being checked before). I didn't really have to
change the workings of any components, which was nice. This issue also
resolves all the security vulnerabilities found when running `npm
install`, and also closes #89.

Doing this would probably make anything we want to do in the future,
such as adding tests (which can be done with
[Vitest](https://vitest.dev/)) or integrating a backend server (which
can be done using [a
plugin](https://github.com/axe-me/vite-plugin-node)), a bit easier.
@gabrc52
Copy link
Contributor

gabrc52 commented Mar 2, 2025

@dtemkin1 Is this PR still relevant?

It has been open for 2 years now

@dtemkin1
Copy link
Collaborator

dtemkin1 commented Mar 2, 2025

Uhhh I think this PR was the start of making a backend for Hydrant, we should prob talk about it at today's meeting I suppose

@cjquines
Copy link
Member

cjquines commented Mar 3, 2025

this PR should be unnecessary now that we've moved to vite

@dtemkin1
Copy link
Collaborator

dtemkin1 commented Mar 3, 2025

I guess we can close it, would be good to continue discussing creating a backend (or we might be able to create similar features through a tighter integration with Fireroad?)

@dtemkin1 dtemkin1 closed this Mar 3, 2025
@cjquines
Copy link
Member

cjquines commented Mar 3, 2025

we should definitely use the fireroad backend instead when possible

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants