Volta | Hacker News Reader

Volta

volta.sh

271 pointstosh88 comments

From the comments here it looks like the project is missing a comparison table with other, similar tools. There are already questions about nvm, npx [1], asdf-vm [2], nodenv [3] (which also relies on shims).

[1]: https://news.ycombinator.com/item?id=27023701

[2]: https://news.ycombinator.com/item?id=27023909

[3]: https://news.ycombinator.com/item?id=27023881

I've only used nvm so far (it was enough effort to get the team to adopt one such tool, and nvm was the main one at the time), but as far as I can see the main differences are speed, native Windows support, and being able to specify both the Node and npm/Yarn versions — that latter point is an important part in getting reproducible results across machines as well. Additionally, at least nvm does encourage pinning to a major version, allowing people's minor/patch versions still to diverge. (The upside I suppose is that that can save you quite a bit of disk space with relatively manageable risks.)

Nix is one of the few package managers that really obviates building these custom solutions over and over for each different language.

You can also use nix ontop of any distro. It's UX isn't as good as a custom built solution, but if you're a polyglot you'll appreciate not needing to use a different solution for java, node, python etc

*any UNIX-like distro

Unfortunately, Windows support is not there yet (or am I wrong?).

I stopped using Linux as my main distro. I was tired of maintaining my OS with the only argument "but I can do whatever I want", and I've been doing that for 10 years (with Debian, Gentoo and even a LFS at some point), no more.

Windows 10 works well. The WSL works well. Docker Desktop works well (unless you use WSL2, then it's CPU/RAM/Disk IO hungry). chocolatey works well.

WSL works well, until it doesn't. For a non C# (or msft ecosystem) dev, Windows offers very little advantage for development. Every tool that is used mostly by Unix loving folks requires workarounds(when possible) to make it work on Windows. Terminal clients are subpar at best, the only selling point I see on Windows is the ability to play games. Without mentioning the privacy issues on Windows. Most mainstream Linux distros are rock solid stable. You can use out of the box Ubuntu as your daily driver with no configuration, besides installing the software you like. I'm not familiar with Gentoo, but yeah, if you install an arcane distro you could have issues with drivers, etc... MacOs is pretty solid too.

My daily driver is Debian WSL2, using wezterm (highly recommend) + tmux for terminal, and vscode integration for IDE. Aside from struggles getting custom subdomains to point to localhost, things have been quite stable.

I never thought I’d be saying this, but I find the Windows window manager the best out of the box, and as a bonus I get to do my unreal/vr dev side projects without booting into another OS.

I stayed on WSL1 for the shared localhost. And WSL2 still have some performance issues related to memory usage and Disk IO.

But yeah, I agree, Windows 10 has a great UX. I switched to windows because of the WSL, and I end up using it less and less over time: ssh, ansible, and avoiding cross-compiling toolchains when building releases, that's about it.

Yeah, I am in a similar boat. WSL 2 with Docker build environments gives me faster build times than my Mac. My default Windows Terminal is a Linux prompt with Zsh. It works surprisingly well. I built a Windows gaming rig and then wondered, “hmmm-this thing is fast. Can I work on it too?” And was delighted that our tool chain didn’t need any tweaking.

Does windows have super button to move and resize. Also im way more used to x style focus on hover. Windows is missing this.

> Terminal clients are subpar at best

https://github.com/microsoft/terminal

Windows Terminal is quite comparable with the vast majority of *NIX terminals and the 2.0 release will have more features than quite a few of them.

But oh well, downvote away if that makes you angry :-))

Git Bash integrated in VS Code works very well.

For Rust/Go/Python/Javascript development, I've never had to rely on any workaround.

It depends on what you mean by "Windows support". WSL is well-supported, I think: https://zaiste.net/os/nix/howtos/install-nix-windows-10/ .

In my experience, though, Windows 10 has proved really annoying. Over the past 8 weeks,

1) Windows 10 update has broken sound (I occasionally have to disable/enable the Realtek Audio device)

2) Windows 10 update has fixed sound (without seeming to have changed the Realtek Audio driver)

3) Has throttled the performance of my graphics card (hash rate on Autolykos V2 dropped by 10x after an update), without having had changed the graphics driver

4) Windows 10 Pro won't allow certain applications to be downloaded or installed (immediately quarantined) and Virus & Threat Protection isn't visible in the Control Panel. This is a common issue, apparently [1]

Generally, Windows 10 seems to take control of configuring the operating system away from the user while adding a bunch of "telemetry" and "application monitoring". Not too happy. I'm in the process of moving to NixOS as my primary system [2]. I'll boot from a flash drive with a live version of the OS including all applications and files I need for local development; the flash drive will mount the OS into RAM; I'll unplug the flash drive and continue my development from RAM; I'll shut down my machine at the end of the day and have a clean slate the next time I boot into the OS [3].

[1] https://www.reddit.com/r/techsupport/comments/d24wii/windows...

[2] https://github.com/johnrichardrinehart/nix

[3] https://grahamc.com/blog/erase-your-darlings

Never had any problems with updates (and my work computer has no graphic card except for the integrated chipset in the CPU).

> Generally, Windows 10 seems to take control of configuring the operating system away from the user

That's exactly what I wanted, I'm tired of spending hours to get a working setup.

> while adding a bunch of "telemetry" and "application monitoring".

I filter outgoing traffic on my router, so not really a problem.

You can run Nix in WSL.

Of course, but what's the point? I use WSL for 3-4 programs, that's it. My entire toolchain is Windows-compatible, and installed through chocolatey with the default configuration.

What about privacy/security issue? Windows 10 we have no control with, but with Linux we do.

I filter outgoing traffic on my router.

You can also do some cool things with configuration management and reproducible builds with Nix + ZFS or btrfs:

https://grahamc.com/blog/erase-your-darlings

https://mt-caret.github.io/blog/posts/2020-06-29-optin-state...

[Recent podcast with Nix author, https://changelog.com/podcast/437]

Volta shows promise and I like that it's fast. But to me it seems like it will be hard to adopt until it supports `.node-version` file (a working standard among node version managers). For example, while some may want to use Volta, others will likely be using `nvm`. And a project's CI likely uses `nvm`. Volta has `volta` property for `package.json` to pin the node and npm version. That's nice and more specific than the `engines` property which can be a range of versions. But it would be better to keep things DRY and leverage the working standard for how node version managers keep track of the node version. (Otherwise a project has to maintain node version information in multiple places.)

https://github.com/volta-cli/volta/issues/959

What’s the issue with the engines field? I don’t see any particularly strong reason to not use it.

In addition to the points raised by the other comments, a big reason we decided not to use `engines` in Volta is that `engines` can be a range: One of the design goals of Volta is to allow for reliable, reproducible environments, and a range is necessarily not static (new versions are released all the time).

Semantic versioning was supposed to prevent breaking changes. I guess this is more akin to package-lock.json then.

Yeah, conceptually the setting is intended to be closer to a lockfile than a semantic version.

Additionally, even with semantic versions, `engines` is often specified as something like `12 || 14 || >= 16`, so they span multiple major versions, which is where breaking changes can (and do) show up.

The engines field is generally used for package consumers so when you do an `npm install` you know if the package is compatible with your local node version.

Pinning the Node.js version for tools like nvm is used by developers of the package or app developers who want to use the same version of node locally and in production, for example.

It functions more like a suggestion than a hard restriction. And, as far as I'm aware, tools such as NVM plain ignore it in favour of their own configuration files.

We've been using volta at sentry.io for probably close to two years now, and I have to say, it's one of those tools I almost never think about because it legitimately "just works" (and is very very fast).

It has definitely helped to keep our team's environment in sync as we grow in # of people building Sentry. It's pretty much eliminated the need to ask 'are you on node / yarn x.y.z?

I switched from nvm to Volta. it is so much faster! if you had nvm switching your node versions per directory in your bash configs, you know it takes sometimes up to a second to cd into a directory. Volta does it so much better with `volta pin`

We’re using Volta for a long time now and it’s so good that i often forget i use it. That’s the best kind of tool. It just works.

What’s the difference between this and NVM or NPX? They both allow installing Node and running package utilities directly.

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?

Instead of one different tool for each runtime or ecosystem, I prefer to use ASDF. https://github.com/asdf-vm/asdf

Even better is different tools with the same name. I prefer this ASDF [1].

[1] https://common-lisp.net/project/asdf/

You might as well recommend them the Alabama State Defense Force too, it's about as related to ASDF the version manager as your example of the Common Lisp ASDF.

> curl https://get.volta.sh | bash

Anyone doing this after seeing the Codecov hack is asking for pain and suffering. Make sure to read every line of that script before running it.

What’s the problem, exactly? I don’t see how this is different from downloading a binary from the get.volta.sh domain and running it.

It's not just that, i.e. you may be fooled if you read the script "in the wrong way".

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

That's not really going to help most people. It's not hard to obfuscate the malicious parts of the script.

I remember someone saying that you could essentially backdoor a target machine by rolling back certain libraries by a few weeks to undo security patches. I don't know modern *nix package management well enough to know if that's true, but it's a scary idea.

How is this different or better than asdf? I'd love if asdf was rewritten in Rust and fast. Someone wrote the run script in Go and it was amazing.

Well, for one, Volta supports Windows! That's a huge differentiator in my book (though as a Windows user I guess I'm biased?).

I have never heard of asdf. When we started using volta (back then notion) more than two years ago, it replaced nvm for us which was just very slow and frustrating.

So not sure what asdf does or how it behaves, but volta is basically a painless "forget that you even have it installed" version of nvm.

asdf is a pluggable version manager for many languages and tools, not just one language.

This looks too complicated, I prefer the simpler solution: tj/n (https://github.com/tj/n)

Installed using n-install (https://github.com/mklement0/n-install)

Would be curious to hear what makes it complicated. Volta is from my experience a "works outside the box" type of arrangement. It installs quickly and once you have it, you no longer think about it.

yeah, n is great

As this is another shim based manager, you can expect that at some point in time, someone in your team will have a broken setup due to shims generation failing for some reason or because something else messed with the way the tool relies on the PATH.

This has been my experience with rbenv, asdf and all other solutions that relies on shims.

Depending on what you are trying to do (for example running short lived CLI), you will incur into a slightly performance cost because of the bash/zsh/fish shell you need to spawn before running your code. In ruby's case rbenv/asdf adds around 20-50ms (could be more etc depending on your shell and your shells initialization code etc).

> you will incur into a slightly performance cost because of the bash/zsh/fish shell you need to spawn before running your code

While Volta does have a shim, it’s written in a sensible systems language (Rust)[0], so it does not spawn a shell. It only determines the correct process and arguments to run and launches it as a subprocess. There will be overhead to read from disk and determine which version of node/npm to run and a syscall to actually launch the subprocess, but that should be very minimal and nowhere near the cost of initializing a shell.

The result is that Volta feels faster than similar tools that are written in scripting/shell languages. It also enables better Windows support since there’s no reliance on a system having a POSIX shell.

[0] https://github.com/volta-cli/volta/blob/main/src/volta-shim....

I think the Python alternative to this is pyenv: https://github.com/pyenv/pyenv

Is this a nodenv replacement? Why not nodenv, or even https://asdf-vm.com ?

I remember contributing a fix for an expansion issue in either bash or zsh (can't really recall) for nvm. Just running it was very, slow. This slowness is primarily why I usually use guix / nix on my distro of choice instead. I'm glad this exists as I can imagine this way of handling which node to use is much faster than how nvm was doing it.

Omg, Javascript tool inception.

There seems to be so many of these tools for Javascript. NVM, NPX, n, asdf, Volta. Coming from a Python background I don't understand why the tooling here is so much more complete than for other languages.

> Coming from a Python background I don't understand why the tooling here is so much more complete than for other languages.

Is python immune to this problem? I think not, in fact, I think it is much worse because we have to "hack" how packages are installed by creating a "virtual environment." How many different tools are there to manage python dependencies?

What about Ruby? In my experience, Bundler is about the only thing I've ever needed to use.

More popular languages enjoy a bigger ecosystem and with that, more tooling.

It’s not that Python is special, it’s Javascript that is.

cool, but am i like a complete grandpa if i'm a bit alarmed by how everyone these days seems to think curl bashing with stranges is totally normal and fine?

Probably the opposite. Back in real 'grandpa' time, nobody thought twice about downloading and make/make install random stuff off of the internet...

please, instead of creating something that's language/tool specific, work on asdf-vm[0]. We all benefit if we don't have to remember which version manager to use for which tool/language/whatever.

[0]: https://github.com/asdf-vm/asdf

If you use Java, there's https://sdkman.io/

nvm will never support deno as its scope is specific to nodejs. Volta however could in the future be a single tool to manage deno and nodejs environments, which would be a killer feature for me apart from better performance. the volta devs are sceptical but still not opposed to the idea.

So there are now more package managers than there are programming languages and operating systems?

Can I get a manager to manage my managers? Someone?

asdf

I can't help by think of this: https://xkcd.com/927/

Reply on news.ycombinator.com