Goodbye Volta?

Volta being an hassle-free JavaScript tool manager was very appealing to me.

Before I started using it, I had been using nvm for 5 years. The setup when you opened a shell took 2 to 3 seconds so I had to write placeholder functions to load it lazily/on-demand. Configuration wasn't great either —telling it what version of Node to use required yet an extra file in your project. And of course I had to manually recompile all my globally-installed node modules from a previous version every time I installed a new Node. This sucked. Volta looked like a decent solution was finally available.

• It's on-demand, so your terminal isn't held up when you enter your project's directory —rather, the right versions of the tools get resolved (and optionally installed) only when you invoke them. It just feels nice.

• It gets configuration mostly right. It's unobtrusive, just sitting there in your package.json. I still don't understand why the team went with a new "volta" key instead of using the standard "engines" one, but it's something I've managed to live with so far.

I've now used Volta for about a year, and I feel sad. The project itself has some problems:

• It has a ton of open issues, some still open after 3 years.

• It's not funded —it refers to some obscure sponsorship by LinkedIn and Netlify on its website but you won't find any list of sponsors or backers on the GitHub repo, nor any option to donate money to the project. This means the situation with issues left to rot won't improve. Development also is very slow, with a new patchlevel version release once every few months.

The issues that are making me consider saying goodbye right now are:

• An obscure update mechanism¹. My local install says I have Volta 1.0.1. GitHub says the latest version is 1.0.4. How Volta updates itself is a total mystery to me, but it's clearly broken. The docs proudly say to Install and forget!

• Its naive approach to globally-installed packages². Volta thinks you can share globally-installed packages across Node versions. Huh? No, you can't. If I build a package with Node 14, it will probably be broken in Node 16.

• How it messes with NPM. The NPM prefix is wrong. npm list -g won't find any globally-installed package. npm exec will also not properly resolve already available versions depending on the situation.

• Its lack of support for PNPM. Using Volta with PNPM is a pain. If you want to have per-project PNPM versions you're left with invoking PNPM through NPX, which brings me back to my NVM days.

What now?

I don't know. I still have to figure that out. I might give a shot at using miniconda to manage my Node environments. Or maybe I'll create a new tool, better than Volta, that will finally be really hassle-free. Then leave it to rot with hundreds of issues too.

1. Update 2021-08-21 An obscure update mechanism —I still have no clue how to update it, aside from installing it again, but I found that homebrew actually now has a volta formula. This seems to be the easiest and most robust way to keep Volta up-to-date, though it's not officially supported and doesn't get the slightest mention in the docs. ↩

2. Update 2021-08-21 All problems related to globally-installed packages go away if, well, you don't have any globally-installed package. I add global-dir = node_modules now in my projects' .npmrc, and prepend ./node_modules/.bin to my PATH. What's the point in passing -g to pnpm (or npm) then, you ask? Well, ignoring the project's package.json, for one. ↩