4 ms·

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

> 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).

the_mitsuhiko 6y ago
> 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.
- capableweb 6y ago
  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.
  - the_mitsuhiko 6y ago
    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 :)
noahtallen 6y ago
> 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

the_mitsuhiko 6y ago

> 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.

capableweb 6y ago
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.
- the_mitsuhiko 6y ago
  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 :)

noahtallen 6y ago

> 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