nvm allows to install and switch node versions, volta does it automatically. It creates a proxy executable which checks package.json, nvmrc, and automatically chooses proper node version; and it remembers the version used when globally installing (npm -g) so stuff will keep working forever, without worrying "can I update node? Are all global deps compliant?"

Also, volta is cross-platform. Nvm is macos only and nvm-windows is a totally different project (slightly different behaviors etc)

> nvm allows to install and switch node versions, volta does it automatically. It creates a proxy executable which checks package.json, nvmrc, and automatically chooses proper node version

NVM also changes the runtime automatically based on the version in .nvmrc, as volta does. NVM does not read the engine version from package.json, as that version is not the _required_ version but rather the suggested version. Just because the author hasn't updated the version since version 4 while you're on version 5, doesn't mean it doesn't work on version 5, just that the author hasn't updated it.

> remembers the version used when globally installing (npm -g)

That's actually a pretty nifty feature, sounds like a good idea and might give Volta a try because I've ended up in that situation many times (or worse, upgrading node and now missing bunch of binaries without thinking about it).

> Nvm is macos only

NVM is also cross-platform (works on Linux too), just happens to not work on "standard" Windows as NVM works via environment variables (and aims to be POSIX compliant), something Windows is notoriously shitty at. Although, many Windows devs use WSL, which NVM also works with (and supposedly MSYS and Cygwin too, but I never tried that).

> NVM also changes the runtime automatically

NVM requires sourcing a very slow loading script. The overhead NVM caused on my shell session constantly was painful enough on a permanent basis that I went to look for alternatives. Even today based on experiences of some NVM holdouts it's still frustrating.

Agree, also had the same issue but it's easy to fix (and also cleans up your environment a bit) by doing the following alias:

    function n() {
      export NVM_DIR="$HOME/.nvm"
      [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
      [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion
    }

Now your shells startup time is not affected, and when you want to use node, you simply execute the `n` command first, and then you use nvm normally.

I had all kinds of workarounds for that, even a custom zsh thing that tried to automate it as much as possible. Thankfully I no longer have to deal with this :)

> NVM also changes the runtime automatically based on the version in .nvmrc, as volta does.

Does it? I thought it only changed once you use “nvm use”. The benefit of Volta is never having to worry about “using” it

> Nvm is macos only

Half true; NVM also works on Linux and *BSD OS types.

also, there is n, and a small comparison of volta vs nvm here:

https://gist.github.com/keimlink/def691fe2253a33d3e15f021458...

Although, nvm use should not even be necessary if your terminal is configured that way. Not having .nvmrc versions is less explicit, how would I change e.g. LTS and newest node versions in Volta?