Discussion on "5 Node Version Managers Compared – Which is Right for You?"

Pavel Romanov · 2024-05-05T14:22:42.628Z

Imagine you joined a Node.js project and want to bootstrap it to see how it goes, but you see an error. What is the problem? After spending some time, you find out that Node.js version you’re using on your machine is not the one that the project requ...

Excellent comparison of Node.js version managers! It really shows the effort needed for environment setup. I've found ServBay simplifies my entire local dev environment, letting me focus on development instead of managing versions. Super helpful analysis!

I use mise-en-place so I don't need a different tool for other languages, it's fast and very good. The broader standard of a asdf style .tool-versions is nice for consistency between e.g. Python and Node.

Hi there! So... I've been using FNM for a couple of years already. And I looked into it, and it seems that there's experimental support for the "engines" prop of the package.json file: github.com/Schniz/fnm/pull/839

Just wanted to point that out

Hey Santiago, I appreciate the read!

Wow, that would be a huge change. I would even consider switching to FNM if they can stabilize the feature.

In my opinion, it is the best way to manage the Node version.

You should also compare mise which manages node, neovim, python, etc for me and can be used for many more tools.

https:// mise.jdx.dev/

I'm not sure why it doesn't catches the conversation, maybe because they don't advertise it as "node version manager" or "python version manager" which is what people mostly search for. Instead, it is "almost anything version manager" and can be extended to support currently unsupported softwares by creating plugins.

As a long-time user of nvm and then n, I would like to add the crucial difference between those two, and why I prefer n over nvm. nvm works through usage of environment variables, changing the path for the node executable file. While this can be enough for most users, I've encountered problems in integrated shells in IDEs (namely in Sublime Text 2, back in the day). Back then, the IDE spawned a shell with a clean and minimal environment (using something like env -i), thus wiping any nvm configurations from the session. n uses symbolic links to manage node and npm versions, thus being a little more robust to differences in environments.

I appreciate the input, Bernardo!

Is it still a problem with modern-day IDEs?

Surprised to see no mention of nodenv 🤔

Thanks for the read Tushar!

There are just too many version managers to mention all of them in one article. That’s why I picked just five.

Maybe I'll post one or two more articles to review more of them. But I bet that they won't cover all of the managers either.

I also thought you could use .nvmrc to set node version within a project. You can even have your bash/zsh/fish automatically run nvm use on cd commands so it automatically picks up the version.

While you say that n is even more limited, it does work with fish, which is why I use it over all others and have for years. It also has some support for .nvmrc so that you can use n auto while others use nvm use.

Hey David, thank you for reading the article. I appreciate it!

You're right. We can use the .nvmrc file to declare the Node version for specific projects. And I'm mentioning it in the article.

You're also right that we can configure shell run run nvm use on cd. However, the reason why I decided not to include it in the article is that it is not maintained by the NVM team. To me, it looks more like a community attempt to fix the initial problem in the same way as nvm-widows doing it.

That's right, N does work with Fish as all of the other managers in this list except NVM by default.

Do you use it with .nvmrc? For me, the best part about N is the ability to detect the Node versions just based on the engines section of the package.json file.

If you need anything about crypto recovery just contact (bensoncryptorecoveryexpert@gmail.com) I have never seen such tech skills in my life before, They helped me recover my $95,000 btc i invested in a forex platform and couldn’t withdraw it. I contacted them via the above email address and everything worked out fine. They did exactly as they said.

It doesn’t switch Node.js version dynamically as you navigate from project to project.

This is somewhat correct for shells but not for projects. Using the use-node-version property in a .npmrc file forces PNPM to use that version of Node in its execution context and auto-installs the declared version of Node if not previously downloaded. You can have nested .npmrc files (think monorepo) to use different versions of Node for targeted projects all isolated from each other as well as your global version.

This means your global Node version (set by PNPM) does not affect your locally declared Node version and doesn't require any separate configuration or commands, like nvm use, to switch Node versions.

Hey Christopher, thanks for the read, and I appreciate your input!

I should've added the note of using .npmrc; that's a miss for sure.

As for "doesn't require any separate configuration." We pretty much do have a separate configuration in the .npmrc file.

In my ideal world, every tool that claims to manage the Node.js version should take it right from the engines section of package.json, like N does it.

Volta is pretty close to the ideal since it places configuration right inside of the file, which makes it easier to keep those sections in sync.

Discussion

5 Node Version Managers Compared – Which is Right for You?

Responses(7)

Recent in Forum

Search Hashnode

5 Node Version Managers Compared – Which is Right for You?

Responses(7)

Recent in Forum