feat: nvmrc

[jordanpurinton]

Is your feature request related to a problem? Please describe.

Would be nice to have a default node ver to be using when initializing. Sometimes I'm working in different projects that require different versions, so would be nice to add that here.

Describe the solution you'd like to see

An nvmrc file that shows pinned node version

Describe alternate solutions

Documentation giving guidance on node version

Additional information

No response

[c-ehrlich]

I think recommending (or maybe even requiring) a specific node version could be a good idea for the scaffolded app.

In the CLI on the other hand I think we should be as flexible as possible (we have in the past for example prevented Next-Auth from being installed while on Node 18, but only because we had no other choice).

Would it maybe make sense to instead of using an nvmrc (we already have a lot of root level files) to use engines and possibly also engineStrict in package.json for this? See: https://www.marcusoft.net/2015/03/packagejson-and-engines-and-enginestrict.html

[juliusmarminge]

Would it maybe make sense to instead of using an nvmrc (we already have a lot of root level files) to use engines and possibly also engineStrict in package.json for this? See: https://www.marcusoft.net/2015/03/packagejson-and-engines-and-enginestrict.html

Do tools like nvm and fnm read engines? With nvmrc fnm automatically updates the node version when cd'ing into the directory

[nexxeln]

Would it maybe make sense to instead of using an nvmrc (we already have a lot of root level files) to use engines and possibly also engineStrict in package.json for this? See: https://www.marcusoft.net/2015/03/packagejson-and-engines-and-enginestrict.html

Do tools like nvm and fnm read engines? With nvmrc fnm automatically updates the node version when cd'ing into the directory

I think fnm needs either .nvmrc or .node-version.

[c-ehrlich]

Would it maybe make sense to instead of using an nvmrc (we already have a lot of root level files) to use engines and possibly also engineStrict in package.json for this? See: https://www.marcusoft.net/2015/03/packagejson-and-engines-and-enginestrict.html

Do tools like nvm and fnm read engines? With nvmrc fnm automatically updates the node version when cd'ing into the directory

I think fnm needs either .nvmrc or .node-version.

ok in that case i think its good to add this. should we require exactly 18, or still be ok with 16 (which is still in LTS)?

[needim]

that is the question: which version to put in .nvmrc?

• put lts/* - are we sure the scaffolded app running on all LTS versions?
• put 18 or 16 or specific version - still are we sure?
• do we have a matrix test to run the scaffolded app in specific node versions?
• this also depends on the packacage.json dependencies. maybe some packages are not ready for that version? (hard shot but can happen)

I think it is up to developers to choose the node version to run the scaffolded app.

[c-ehrlich]

After looking at the options that nvmrc allows, the most sensible choice to me seems like either lts/*or not creating the file at all. What does everyone else think?

[juliusmarminge]

After looking at the options that nvmrc allows, the most sensible choice to me seems like either lts/*or not creating the file at all. What does everyone else think?

Im good with not including it at all, if I need to lock the node version I'll just add a nvmrc later

[c-ehrlich]

After looking at the options that nvmrc allows, the most sensible choice to me seems like either lts/*or not creating the file at all. What does everyone else think?

Im good with not including it at all, if I need to lock the node version I'll just add a nvmrc later

Seems good to me as well. I'm not sure the benefits outweigh the annoyances.

Closing this for now, but anyone feel free to reopen.