`.nvmrc` is too specific

[avivkeller]

Our .nvmrc file is currently set to v22.14.0. This is too specific, since the website supports any version greater than v22.14.0 in the v22 release line.

For me, using fnm, it's annoying to get this pop-up whenever I open my terminal:

Can't find an installed Node version matching v22.14.0.
Do you want to install it? answer [y/N]: 

We should broaden this to v22

[AugustinMauroy]

Hold on I think there are a reason with cloudflare thing cc @dario-piotrowicz

[dario-piotrowicz]

@AugustinMauroy thanks for the ping 😄, I don't think there's any issue with the Cloudflare open-next adapter

There is however an issue with the generate script on versions of node <22.14.0, see the description here: #8005

So broadening the nvm to just 22 might result in people getting errors (if they are already using a version of node between 22.0.0 and 22.14.0), I don't think that nvm supports ranges, does it? 🤔

(PS: I know that setting the value to 22 can bump to the latest 22 version, but that only only applies if the user hasn't already installed any version of 22, if for example the user has already previously installed 22.9.0 that would be used)

[dario-piotrowicz]

I personally think that having a correct version of node specified is better instead of risking to alienate/confuse potential new contributors

But I can imagine Aviv's frustration... can't fnm be set to use 22.14.0? 😕

[dario-piotrowicz]

PS: in my PR I said "minimum" version of node... sorry on hindsight I can see that that was definitely misleading 😓

[ljharb]

While I agree there's a use case for being able to say ^22.14 in .nvmrc, in reality production is (i assume) locked to a specific version of node, and that's the only version that I'd expect developers to be able to use.

[avivkeller]

I personally think that having a correct version of node specified is better instead of risking to alienate/confuse potential new contributors

But I can imagine Aviv's frustration... can't fnm be set to use 22.14.0? 😕

I mean, it can, and, this'll all be irrelevant in October, but still, it seems unnecessary for a user to have a specific version of an LTS release, when the latest version of said release works fine

[dario-piotrowicz]

it seems unnecessary for a user to have a specific version of an LTS release, when the latest version of said release works fine

Agreed, this does feel a bit forced to me too, on the other hand having something that I could go in, run nvm use and get an incorrect result feels worse to me

I think there's indeed a tradeoff to be made here, I stated my preference although I can also understand your point of view and am not strongly against it either, especially since, as you said this will be irrelevant when 24 goes LTS

[ljharb]

If it works fine, upgrade it in both production and .nvmrc for everyone :-)

[bmuenzenmeyer]

right - this is all about determinism. same reason i continue to advocate for pinning everything, dependencies, SHAs, etc

[bmuenzenmeyer]

I would move to close this as not planned, since this value is basically a production constant - per https://github.com/nodejs/nodejs.org/blob/main/.github/workflows/build.yml#L69