Add support for .nvmrc lookup when running nvm use and no version is specified

[taur]

When running nvm use without a version parameter expected behaviour is that it will look in the .nvmrc file for a version-number to use

[coreybutler]

We considered this before release and had mixed views. We're seeking community feedback, so I'm switching this to a discussion.

Case For: Convenience

Obviously this would be convenient if you want to switch your default system version without knowing which version you're switching to. But how often are people doing this, and for what purposes?

Case Against: Security/Awareness

Scripts can manipulate .nvmrc files, which could allow an old compromised version to be configured as the default for the entire computer. An agent could specify a version with a known CVE/CWE, run nvm use, and execute against it. This is a bit of a strawman argument, since an agent could just run nvm use <version> too.

By requiring a version in the command, users know which version they're configuring. The point is awareness. More importantly, logging nvm use <version> captures the explicit choice instead of inferring it from the .nvmrc, which can be modified after the fact.

---

Since this is a question of convenience and not function, we opted for the case against. Again though, we're open to community feedback.

[taur]

The case against is somewhat prevented by not allowing uninstalled versions and just throwing an error / warning if that versions has to be installed first, just like how actually specifying a uninstalled version would. With power comes responsibility and so on.
I think it's too much doting and we can't have nice things just because, if it's already installed - let them shoot their foot!
I buy the case against argument for the install command, but not the use command, I think it's very useful right after cloning a repo with a .nvmrc file in it to manually load the right node version, and that benefit greater outweigh the risk with the use command.

[coreybutler]

But do you really need to nvm use right after cloning? If there is a .nvmrc, just running npm start or node index.js runs the version specified in .nvmrc. What use case is there for immediately switching the machine default version?

There's also a conflict with another convenience option: auto-install missing versions. There is an option to forcibly disallow this (or prompt), but we can't unilaterally disallow missing versions on nvm use without adding another config option to override behavior specifically for that command.

[taur]

Why do I want to use the machine default version and not the one the codebase was developed for?
As a developer I juggle many customers in different stages of version regression, neither npm nor node is aware of .nvmrc and will happily try to run with w/e willy nilly version that happens to be active. ofc the config of other convinience options has to be dealt with as not to interfere.

[coreybutler]

I've realized this is lacking in the documentation (I opened #33), but there is a flag for the node shim to specify an adhoc version. Run node --nvm-use <version> <file> to cherry pick a specific version for that specific execution. If nothing is specified, it reads from the .nvmrc, .node-version, package.json, etc. If that doesn't exist, it falls back to the system default.

Version Resolution:

graph LR
  s[node --nvm-use]
  rc[.nvmrc/etc]
  d[System Default]
  f[Fails Missing Version]
  s-->rc
  rc-->d
  d-->f

Loading

This will also resolve native and custom aliases, so you can do node --nvm-use default file.js or node --nvm-use my_project_alias file.js (assuming you have an alias called "my_project_alias").

In shim mode, the node and npm shims are both aware of .nvmrc. That's why I'm not clear about this use case. What you're saying is true in link mode, but that is one of the limitations of link mode (and why we recommend shim mode).