feat(CLI): add check node version middleware, rm .nvmrc, yarn engines

[jtoar]

Continuation of #8907. Following up on our meeting today (@Tobbe, @thedavidprice; this PR doesn't implement the configurable engines functionality yet).

This PR

• removes the .nvmrc file from CRWA and test project fixtures

  Setup deploy commands should add node version files if they need them, preferably something nvm agnostic like Netlify's .node-version

• removes yarn from engines in CRWA's root package.json since it doesn't do anything and just creates confusion

• adds a node version check to build and dev

  This piece of middleware is lightweight; it doesn't involve a child process or the file system, it just checks against process.version. I also removed the babel check because it's been ages since we've made that change and original concerns against checking for the node version were about adding overhead tot he CLI. So let's remove unnecessary middleware if we're going to add more

Right now, the node version check just emits a warning. Should it error out? (I should've taken better notes.)

Build:

Dev:

Tasks

• research deploy providers and update yarn rw setup deploy commands
• settle on warning or error for build and dev
• settle on the contents of the message
• update CRWA

Deploy providers

• baremetal

  Pretty sure it's completely up to you.

• coherence

  Via Nixpacks, engines.node in the root package.json: https://nixpacks.com/docs/providers/node#setup.

• flightcontrol

  Via Nixpacks, engines.node in the root package.json: https://www.flightcontrol.dev/docs/getting-started/javascript/setting-node-version#using-the-packagejson-file.

• netlify

  Via the .node-version file, or via in netlify.toml; see https://docs.netlify.com/configure-builds/manage-dependencies/#node-js-and-javascript, https://docs.netlify.com/configure-builds/file-based-configuration/#sample-netlify-toml-file.

• vercel

  Takes its cue from engines.node in the root package.json: https://vercel.com/docs/functions/serverless-functions/runtimes/node-js#version-overrides-in-package.json.

• render

  Same as netlify more or less, but also respects engines.node in the root package.json: https://docs.render.com/docs/node-version.

[Tobbe]

setup deploy commands should add node version files if they need them, preferably something nvm agnostic like Netlify's .node-version

I would go as far as saying "deploy target specific", not just "nvm agnostic"

For Netlify a .node-version file could be a good option. Another option is something like environment = { NODE_VERSION = "20.10.4" } in netlify.toml

Right now, the node version check just emits a warning. Should it error out? I should've taken better notes.

To me a warning makes sense for dev at least. Maybe error out on build? Or just go with a warning there as well 🤔

[thedavidprice]

I like how you're handling this @jtoar! Nothing I wrote below feels like a "must do" — consider them all a part of the discussion for you and Tobbe to finalize.

Behavior for dev and build

Recommendations:

• dev: warn
• build: error

I didn't read the new code --> confirming you're handling cases where package.json engine isn't defined, correct?

Package.json Node Engine

"node": "=20.x" vs. "node": ">=20.x"

• if we are only enforcing the lower bound, then I think we should use >= and let the user decide if they want to further restrict
• if we leave it as = then the CRWA setup will allow them to use a major greater than 20 but will then error when running dev or build. If we choose to leave as =, then we should have CRWA setup update the engine value if choice is to "permit use of non-LTS supported version"

Deploy Setup

Render
Node Version is hardcoded in Template here: https://github.com/redwoodjs/redwood/blob/main/packages/cli/src/commands/setup/deploy/templates/render.js

• Should we set during setup?

Netlify
I really like Tobbe's idea to use env var within Netlify toml. Makes it very clear what's going on.

Vercel
Looks like we are limited to using the package.json engine, but even that's not definitive if it is out of sync with the project dashboard setting. Also, it's much harder to understand that Vercel uses the engine. Maybe prompt during setup deploy vercel and ask user to set value, defaulting to the lower bound major in package.json engine (not sure how to handle default if no engine).

• https://vercel.com/docs/functions/serverless-functions/runtimes/node-js#version-overrides-in-package.json

And/or maybe we just message that use needs to manage Node version in dashboard settings... ?

Doc

I'd like to see a new doc about Node.js Version Support:

• Redwood "officially" supports the latest LTS (link to release schedule), which means CI is run against that version and packages are built to that version
• You can choose to use latest, non-LTS versions
• You cannot use versions prior to latest LTS version
• How to manage via package.json engine
• How to handle deploy providers (aka read the docs 'cause you need to manage it)
• table showing Redwood Version and Node Version supported

We can link to the new doc when CLI gives warning or error messages and/or during deploy setup.

Thoughts?

[jtoar]

I didn't read the new code --> confirming you're handling cases where package.json engine isn't defined, correct?

No I don't think we talked about that and I didn't think of it at all. We've shipped with it since forever, so someone would have to go in there and delete it. What were you imaging would happen in this case?

Re Render, i'd probably get rid of any trace of NODE_VERSION in the template since engines.node is enough. You're right that Vercel has more qualifications to engines.node so there should be more care there.

I know you'd like to see the doc; I didn't do it yet cause it's considerably more work.

[thedavidprice]

No I don’t think we talked about that and I didn’t think of it at all. We’ve shipped with it since forever, so someone would have to go in there and delete it. What were you imaging would happen in this case?

If someone deletes it, just make sure the code doesn’t throw. :man-shrugging:

Re Render, i’d probably get rid of any trace of NODE_VERSION in the template since engines.node is enough. You’re right that Vercel has more qualifications to engines.node so there should be more care there.

Agreed about both. Might need to confirm with Render it can be removed (fwiw).

I know you’d like to see the doc; I didn’t do it yet cause it’s considerably more work.

Understood.