If you never had to use Node.js with npm, you're a fortunate person. For those poor souls that have had to use Node.js and npm to build software at least once in your life, you've probably encountered a similar problem while upgrading your Node or npm packages to newer versions. In this post we'll focus on how to be able to use multiple versions of Node in the same system, and when this might be important for you.
Why we may need to have multiple versions of Node?
Let's start from answering the question:The answer is quite simple. You may need multiple Node versions if you have at least few projects on your machine where each may require different versions of Node, and/or sometimes you have to also develop them.
The most common case here would be the frontend developers (and/or backend node developers), where they most likely might have a few projects they have to take care of, but each might use slightly different versions of Node. For example, some projects could be from the brownfield (e.g.: using v12), and some from the greenfield, where they naturally may be able to more safely utilizing the latest available versions of Node.
Keep your engine up-to-date
Whenever possible try to not stay behind and using older version of Node, but rather always try keeping your project up-to-date with the newest version of Nodes.The best would be to use the latest LTS version, although if you feel edgy and created some greenfield project, use the latest current version, which is usually always bit more ahead LTS.From what I observer the Node community have tendency to always trying and update their projects to newer versions of Node. Although keep it reasonable and do not go to extremes by upgrading in first day when info about new release comes (unless you know what you do) as some older packages may not be yet upgraded to latest releases and you may encounter some npm packages with an incompatibility between the versions.
Usually, running a command like the one below in the directory of your project should give you a result similar to this.
The output above means that the project will need at minimum Node version 24 or higher, and npm 11.6 or higher.
Do I need to have multiple versions of Node?
In most cases, no. Usually you can use a single version of Node (for example LTS) for all your projects, and in most cases you will be fine.
However, if like me, you have different projects from different brownfield or greenfield codebases, plus utilize some additional Node packages for your external programs (I use some for Vim), having the option to run multiple versions of Node might be a necessity in order to have a proper and smooth development process across all workspaces, and also feel comfortable when switching between them.
How do I install multiple versions of Node?
The simplest way is to use nvm1. In short, under the hood nvm takes care of installing different versions of Node in separate directories, and also provides a way to easily switch between them in your PATH. In essence, when using nvm you can easily switch between any Node version when there is a need. For example, you can open 2 separate terminals and each one can instructed to use a different version of Node by nvm use 24 and nvm use 18, and there will be no problems or conflicts while running. How easy and convenient is that, right!
The output below will tell you what is currently on your OS. For example, in one of my systems I have something like this:
In the output above you will notice, I have there two major versions installed, an old v22 and newer v24. The v24 is also currently selected (marked by sign -> in front of it). At the time of writing this article, v24 is also the LTS version, and is set up to be my default version, but if you read this article in a few months time, you may notice this will change.
sh
# setup v24 as default versionnvm alias default v24
You may notice there is also another version, called system, which in my case (due to using macOS) can be checked in multiple ways. Here is one when you are already using nvm:
sh
# switch to system version→ nvm use systemNow using system version of node: v25.9.0 (npm v11.12.1)# check where is node program located→ command -v node/opt/homebrew/bin/node
Now we know, the "system" Node on my machine is located at /opt/homebrew/bin/node.
Don't use Node directly from brew
Many people actually using the Node program directly from Homebrew. Although I really don't recommend using a Node version directly from the Homebrew package manager for developing apps in your projects.The version of Node from Homebrew is used mostly for other internal tools installed within Homebrew2. For example, if you install yarn or pnpm via brew package manager, they most likely will also using same latest version of Node installed globally from Homebrew. In other words, this means if you use the Node version from Homebrew to develop your project, you will lock yourself the only to that specific version, which is not generally good as later may cause you troubles.Imagine that some day when you will be enjoying the day doing something else (not programming), and some point you'll decide to upgrade some Homebrew packages because you noticed there are some updates available. Then some time later, after you will go back to your Node project, you may be surprised with potential error case where the project you work on won't work3. This would be exactly due to some incompatibility of the versions.
My Node best practices for versioning
Always specify used versions of Node and the package manager.
use at least the minimal supported version based on LTS (e.g.: >=24.0.0)
define a version entry for Node
define a version entry for the package manager
In the best case, use a Node version from nvm as this will guarantee you independence from system or other local package managers like Homebrew. This is important since system versions change over time out of your control, which may lead to unwanted behavior. See the message above if you missed it.
In the best case, use pnpm as a package manager as at the moment of writing this article it is the most reliable and fastest package manager for Node that will save you time and also disk space due to deduplication of packages.
Define pnpm-lock.yaml file for your project
Decide on a single package manager with your team. Mixing different Node.js package managers (npm, yarn, pnpm, etc.) can be later difficult to fix without introducing breaking changes to package versions due to package incompatibility.
Always try to define .npmrc file. This configuration file helps you define further specific requirements for your project.
Add @scope to the package.json
Add engine-strict = true - this will make sure that your project uses an exact Node version across all developers.
Do not commit .npmrc file, make it as a template to copy
Most private Node projects, may also use a private registry to download proprietary packages. This is because they are not available in public spaces, and usually also require additional steps to access them (i.e: registry or authentication tokens).I've seen so many times where developers by accident commit their auth tokens to the repository, and later we had to renew their auth tokens in order to persist their privacy. This is the main reason to not commit .npmrc in the repo, rather maintain template .npmrc.example. That's why I find it's a good practice to define .npmrc.example as a template file in your project, and inject it as part of your project setup with all mandatory fields1.
sh
cp .npmrc.example .npmrc
Also, do not forget to add a .npmrc file to .gitignore and commit this change.
sh
echo ".npmrc" >> .gitignore
This will help other developers avoid accidentally committing private access tokens in the repository, and later reduce the overhead of renewing them in case of a leak.
Always try to define .npmignore files.
For production code, try to stick to Node.js LTS versions. This is important as those versions are usually more stable and will be supported for a longer period of time.
Nowadays, around Node v24-v26, this would be actually a rare case, as the Node API become much more stable. Although, in the past, this was quite common to break project between version, and with "general programmer tendency to always upgrade", plus my enormous luck, this potential error case has actually happened to me too many times that I could simply ignore it 😆. Well, I'm not saying that you should never upgrade, rather do it responsibly to spare you lot of time - you've been warned 😇. ↩
Why would you need to use multiple versions of Node?
How to check which version of Node my project requires?