Comment by nerdponx | Hacker News Reader

Comment by nerdponx | Hacker News Reader

Parent Full thread

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.

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

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.

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

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)

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.

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.

Reply on news.ycombinator.com