Among the version management tools for
nvm is naturally well known, but we cannot forget
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
n is an
npm packagethat needs to be installed globally.
This means that we need a
node environment before we can use
n to manage
node versions. We can either install a
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.
n has the problem that the global module cannot be updated.
Let’s look at
nvm is not an
npm package, but a standalone package. This means we need to use its installation logic separately.
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
nvm stores the different versions of
~/.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
nvmis 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:
nvmdoes not depend on the
nodeenvironment, it is
nodethat depends on
n, which creates a circular dependency-like problem.
How to choose?
Looking at it this way, the differences between
n are still relatively large, as evidenced by.
- Ease of installation.
nvmis obviously a lot of trouble to install;
nis more in line with
node’s usual way of thinking. It’s a matter of opinion.
- System support. Note that
nvmdoes not support
- Management of global modules.
ndoes nothing with global modules, so there is a risk of global module execution errors after switching
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.
n is always
nvm requires a manually specified path.
So, how to choose?
It’s a matter of opinion, but here are some general suggestions.
- If you’re using
Windows, there’s no choice but to use
n, or get a
- If you switch
nodeversions frequently (e.g., to test the latest version of a feature locally, while keeping your code compatible in production), you should only use
nvmfor global module compatibility reasons.
- 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
- If you were to ask, which one did I end up with? I would say that I chose the more popular one.