`nvm use` should write a `.nvmrc` file by default

[colearendt]

Thanks for the great work on this!

I am most familiar with a lot of the semantics of the pyenv project. One of the nice features that keeps things consistent is that when pyenv uses the following logic:

• if there is a .python_version file in the current directory use that
• if there is a .python_version in a parent directory, use that
• if there is no .python_version in this or a parent directory, use the default
• you can change the version by selecting pyenv local
• when pyenv local is called, a .python_version file is written to the current directory

I just learned that nvm supports the same via the .nvmrc file. However, it is opt-in behavior (which I found surprising). I also found it hard to discover, because there was no command-line option related to writing a file / etc.

And to the main thrust of this issue, the last bullet is different - I must write a .nvmrc file myself. I would expect that if I went to the trouble of nvm use in the current, then I am expecting other shells in this directory to do the same.

Perhaps there is another use case I am not thinking of. However, at a minimum I would expect a flag to "write a .nvmrc file for me" as an opt-in. And the opt-out of writing such a file feels like the better interface.

[ljharb]

I definitely don't think this should be done by default; just because someone is nvm useing does not mean that's the version other developers should be expected to use - and just because one developer is using nvm doesn't mean that a project's git repo should get an .nvmrc file unless every other developer is also expected to use it.

I think some kind of option on nvm use/nvm install that created/updated an $PWD/.nvmrc file would be reasonable, tho.

[colearendt]

That makes sense. For the record, I think the way we generally work around that in .python-version is by either .gitignoreing it, or committing it and people can either choose to use it or not. I will say, after digging into #2850, that this may be related to python-virtualenv and another "overstepping reasonable bounds."

This is the help docs on nvm use for reference:

  nvm use [<version>]                         Modify PATH to use <version>. Uses .nvmrc if available and version is omitted.
   The following optional arguments, if provided, must appear directly after `nvm use`:
    --silent                                  Silences stdout/stderr output
    --lts                                     Uses automatic LTS (long-term support) alias `lts/*`, if available.
    --lts=<LTS name>                          Uses automatic alias for provided LTS line, if available.

Does nvm use -w v16 seem like a reasonable interface? (-w for "write"). It saves the hassle of nvm use v16 && echo 'v16' > .nvmrc.

[mouday]

this good a idea!

[ryenus]

I second that --save can exist but it should NOT be the default. I want to be able to change the current node version regardless which directory I'm currently in.

[katcaola]

As a heads up, the windows version of nvm does not support certain version strings the way that nvm-sh does. I'm trying to script an automatic repository setup for both windows and unix users, and

• you can't use vX.Y.Z as a version string in the windows version (it must be X.Y.Z)
• you can't have lts version name strings like lts/hydrogen in the windows version (it must be ltsX such as lts18).

Making it default might not work for users who use nvm for windows.

[ryenus]

BTW, there's direnv, here's a related issue: https://github.com/direnv/direnv/issues/335

[ljharb]

@katcaola you mean nvm-windows? That's a completely different project. nvm itself (which works on windows in some shells) supports the same strings as on non-windows.