What nvm use Actually Changes
For nvm-sh/nvm, nvm use is the point where an installed version becomes the runtime selected by a particular shell. This chapter focuses on that environment transition—not on downloading Node.js—so the reader can predict why one node command wins, how selection is reversed, and why npm configuration or a remembered command path can block an otherwise valid switch.
The key idea is simple: nvm does not replace every Node executable on the machine. It changes the lookup rules of the shell in which the function runs. The files for several versions may already exist, but the shell’s environment determines which one a command reaches.
PATH is the selector
A shell usually finds a command by searching the directories listed in PATH from left to right. If two directories contain an executable named node, the directory encountered first supplies the command. Nvm uses that ordinary shell rule as its selection mechanism. It computes the installation directory for the chosen version, then puts that version’s bin directory into the nvm-managed part of PATH.
This has an important consequence: nvm use is not primarily a file operation. It is an environment operation. A successful call does not copy one Node binary over another or change a system package database. It changes the current shell’s answer to “where should node, npm, and related tools be found?” Processes launched afterward inherit that answer. Another terminal, with a different environment, can continue using another version.
Nvm also has to remove or replace the path contribution from an earlier selection. Its path-changing logic recognizes nvm-managed locations and substitutes the newly selected version while preserving unrelated system entries. Without that replacement, switching from one version to another could leave both trees in PATH, allowing the old one to continue winning or creating an order that no longer reflects the user’s latest choice.
Imagine that two versions are installed and the shell begins with the first version’s binary directory near the front of PATH. Selecting the second version does not require deleting the first tree. Nvm removes the old nvm-managed contribution and places the second tree in the corresponding position. System tools that were already in PATH remain available, but the name node now resolves through the selected tree. The distinction is between changing an ordered search list and changing the resources that list points to.
That replacement also has to cope with a shell that has been switched more than once. If every call simply prepended another directory, PATH would accumulate stale selections and become harder to interpret. If every call rebuilt the whole path from scratch, it could discard unrelated tools supplied by the user or operating system. Nvm’s path logic instead treats its own entries as managed state and leaves the rest of the path alone. This is a small but important ownership rule: nvm edits what it owns, not every directory a user has configured.
The same reasoning applies to the surrounding paths that make a runtime useful. Nvm updates MANPATH when the host provides a manpath command, so manual pages from the selected installation can be found. It adjusts NODEPATH when that variable is already in use, connecting global Node modules with the selected version rather than leaving a previous version’s module directory in place.