[HN Gopher] Volta vs. Nvm for JavaScript Tooling
___________________________________________________________________
Volta vs. Nvm for JavaScript Tooling
Author : johnmaguire
Score : 25 points
Date : 2021-11-22 15:29 UTC (7 hours ago)
(HTM) web link (sirre.al)
(TXT) w3m dump (sirre.al)
| nerdponx wrote:
| 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.
| andrewla wrote:
| 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.
| jacobmischka wrote:
| 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.
| andrewla wrote:
| 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.
| Rapzid wrote:
| What does it mean for NVM to be slow? It's never crossed my
| mind that it's slow.
| hamandcheese wrote:
| 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.
| throwawaycuriou wrote:
| 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)
| chrisan wrote:
| 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.
| amir734jj wrote:
| I use N. It's a drop-in replacement for nvm.
| munro wrote:
| 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
| antihero wrote:
| What about asdf? Great because it's extensible and supports any
| language.
| molszanski wrote:
| worked great for me. Didn't try node though
| nerdponx wrote:
| 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.
| SavantIdiot wrote:
| 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.
|
| /s
| trulyme wrote:
| Confused - in what way is that sarcasm?
|
| The amount of packages in JS world is truly impressive, while
| their quality... usually not.
| Ginden wrote:
| > 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`
| [deleted]
| picardo wrote:
| 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.
___________________________________________________________________
(page generated 2021-11-22 23:02 UTC)