Among the version management tools for node, nvm is naturally well known, but we cannot forget n from TJ. These two, are the most mainstream solutions at the moment.

For more information on how to install and use these two tools, please see their respective homepages.

Next we focus on the operation and characteristics of nvm and n.

n

  • n depends on node

n is an npm package that needs to be installed globally.

1

npm install -g n

This means that we need a node environment before we can use n to manage node versions. We can either install a node with Homebrew, or download pkg from the website, or we have to install a node ourselves – n itself can’t do that for you.

Then we can use n to install different versions of node. During installation, n stores the specified version of node and then copies it to the familiar path /usr/local/bin, which is pretty straightforward. Of course, since n will operate on non-user directories, you need to add sudo to execute the command.

So it seems that n is a very easy to understand solution in its implementation.

However, n has the problem that the global module cannot be updated.

nvm

Let’s look at nvm. Unlike n, nvm is not an npm package, but a standalone package. This means we need to use its installation logic separately.

1

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.29.0/install.sh | bash

Or use Homebrew to install it. After the installation, you need to change the shell configuration (~/.zshrc or whatever), see the official documentation.

Then we can use nvm to install different versions of node.

During installation, nvm stores the different versions of node under ~/.nvm/<version>/ and then modifies $PATH to include the path to the specified version of node, so that the node command we invoke will use the specified version of node.

nvm is obviously more complex than n, but on the other hand, since it is a standalone package, the relationship between it and node looks more logical: nvm does not depend on the node environment, it is node that depends on nvm; unlike n, which creates a circular dependency-like problem.

How to choose?

Looking at it this way, the differences between nvm and n are still relatively large, as evidenced by.

  • Ease of installation. nvm is obviously a lot of trouble to install; n is more in line with node’s usual way of thinking. It’s a matter of opinion.
  • System support. Note that nvm does not support Windows.
  • Management of global modules. n does nothing with global modules, so there is a risk of global module execution errors after switching node versions.

The global modules of nvm exist in the sandbox of their respective versions and need to be reinstalled after switching versions, and there is no conflict between different versions.

About the node path. n is always /usr/local/bin; nvm requires a manually specified path.

So, how to choose?

It’s a matter of opinion, but here are some general suggestions.

  1. If you’re using Windows, there’s no choice but to use n, or get a Mac.
  2. If you switch node versions frequently (e.g., to test the latest version of a feature locally, while keeping your code compatible in production), you should only use nvm for global module compatibility reasons.
  3. If you’re a lightweight user who doesn’t need to worry about compatibility issues and is more concerned about the experience of installing and using node, then choose n.
  4. If you were to ask, which one did I end up with? I would say that I chose the more popular one.