Volta vs. Nvm for JavaScript Tooling | Hacker News Reader

Volta vs. Nvm for JavaScript Tooling

sirre.al

33 pointsradlad19 comments

Open articleView on HN

I am currently aware of the following Javascript "version managers":

- NVM: https://github.com/nvm-sh/nvm

- N: https://github.com/tj/n

- Volta: https://volta.sh/

- FNM: https://fnm.vercel.app/

- ASDF-VM: https://asdf-vm.com/

I started with NVM, which is so slow that I'm confused (and maybe even impressed) as to how it's possible to be so slow.

Then I switched to FNM, which is delightfully not-slow.

Then I switched to Volta, because it supports installing standalone "tools" other than just Node, like Yarn and the various LSP servers that I use. If it's slower than FNM, it's not enough slower to matter to me.

I tried N but don't use it. It seems to have a more "interactive" UI than FNM or Volta, so use N if you like that kind of thing.

I haven't used ASDF-VM, which apparently supports several languages/interpreters/compilers, including Node. I have been meaning to try it. I am somewhat skeptical that a general-purpose "do everything" tool would be better than a collection of purpose-built tools like Pyenv, Rbenv, Plenv, NVM/FNM/Volta/N, etc. etc., but people seem to really like it.

I'll throw nave (https://github.com/isaacs/nave) in there as well.

I'm leery of things that globally mess with my environment. When I run "nave use latest" or "nave auto" (for predictable setup) then it creates a subshell that knows about node. Very self-contained, which I find necessary.

I too dislike that, which is why I've been using fnm and conditionally execing its initialization env vars when I want it.

The idea of subshells instead is interesting, I might write a quick wrapper function that does that instead, thanks.

Nave seems interesting, and of course isaacs is well known, but taking a look at its primary source file that is just a massive shell script makes me slightly uneasy, I'd rather use something written in a proper language.

For a while I had a wrapper script around nvm (that I called "nvm-shell") that let me swap in a shell that was aware of nvm:

  exec $BASH --init-file <(echo '. ~/.bashrc; . $NVM_DIR/nvm.sh; PS1="<nvm>$PS1"')

This worked for me, but it's so ugly. When I found nave I switched over. I do wish bash had some sort of functionality for "after you do the standard initialization, run this script and then be interactive after that". This was the best I could do on that front. I suppose it might be worth having a more generic tool -- "launch_interactive_shell_session_after_executing_script" that could be reused here.

The fact that nave is done entirely in shell script is admittedly a bit terrifying.

Really the best option is just to use nix (and thus nix-shell) for this, but I work in some environments where nix is not yet an option.

What does it mean for NVM to be slow? It's never crossed my mind that it's slow.

maybe switching versions?

It's a bit slow, but not anything I do often enough that I care, normally the old project just has its own terminal tab.

The nvm shell initialization would take, sometimes, seconds for me, every time I started a new shell. And the cd hook to auto switch mode versions also added perceptible lag on each new terminal prompt.

this version check https://github.com/bdefore/dotfiles/blob/53a2e00c236a2d581ac... is much faster than the officially suggested https://github.com/nvm-sh/nvm#automatically-call-nvm-use (or at least used to be)

Strange, it's instantaneous for me(no perceptable delay) on Linux but I don't use the auto switching or anything.

What about asdf? Great because it's extensible and supports any language.

I'm interested in that extensibility. So many languages have their own "implementation/version manager" now.

In addition to the popular scripting languages (Python, Ruby, Perl), you have Rustup and Choosenim and OPAM et al., all with their own slightly different interfaces, even though they all mostly just set environment variables in your shell.

The flipside is that each of these purpose-built version manager tools can be as language/ecosystem-specific as it needs to be. How low is the "lowest common denominator" in ASDF? Should languages stop making their own version managers and embrace ASDF?

Also, the name ASDF is going to cause some unfortunate ambiguity for Common Lisp users.

worked great for me. Didn't try node though

> I can install tsc for use anywhere with npm install --global typescript, but when I switch to my project I have to remember to use its tsc from node_modules/.bin/tsc

Just use `npx tsc`

I use N. It's a drop-in replacement for nvm.

I asked #node.js on libera, and they put me `fnm` [1], after being finally being fed up with how slow `nvm` was--haven't noticed any differences other than now things have been really fast.

[1] https://github.com/Schniz/fnm

package.json integration isn't mentioned, but that is probably my favorite feature. You can add a `volta` block to you package.json with all the versions of node and npm and volta automatically installs them for you.

If programmers would just toughen up and stop creating new tooling at every minor inconvenience, we wouldn't have the bloat that make JS a laughingstock.

Confused - in what way is that sarcasm?

The amount of packages in JS world is truly impressive, while their quality... usually not.

nvm has .nvmrc for auto switching node versions automatically when entering a directory.

`npx` for global scripts or package.json scripts for project local dependencies.

Reply on news.ycombinator.com