nvm: Node versions and shell state
nvm explained: a Node version manager that lives in your shell
Understand per-user installations, per-shell runtime selection and why nvm-sh/nvm is not interchangeable with every Windows tool named nvm.
What you will learn
- Separate the manager from the runtime
- Platform names are part of the decision
- Evaluate a reproducible project workflow
Before you start
- Basic shell commands and process environments
- Distinguish runtime installation from runtime selection
Diagnose requested versus active Node versions and design explicit setup and verification boundaries.
Key takeaways
- Manager version and Node version are different identifiers.
- Selection affects the current shell and subsequently launched processes.
- The shell-based project and native Windows alternatives are distinct tools.
Separate the manager from the runtime
nvm-sh/nvm manages multiple Node.js installations and selects one for a shell. It is implemented mainly as shell functions, not as a resident server or a JavaScript runtime. The inspected repository reports nvm 0.40.7; that number describes the manager, while a selection such as Node 24.14.0 describes a different component with its own release lifecycle.
Installation is per user and selection is per shell. Two terminals can therefore resolve node to different installed binaries without replacing a single machine-wide executable. Existing application processes do not transform into another runtime when you change the current shell. This model is particularly useful when maintaining projects with incompatible Node requirements.
Platform names are part of the decision
The README describes POSIX-style shells on Unix, macOS and WSL, with qualified notes for Git Bash and Cygwin. Native Windows alternatives mentioned by the project are separate implementations, not packages maintained by nvm-sh. A tutorial written for PowerShell or another nvm product cannot be assumed to share installation paths, commands or switching behavior.
Because nvm is a shell function, command -v nvm is the documented installation check; searching only for an executable with which can mislead. The shell must load the inspected nvm.sh from its chosen directory. An installed file that a noninteractive process never sources is not an available command in that process.
Evaluate a reproducible project workflow
A project can place a version request in .nvmrc, then explicitly install or use it. This file records intent; it neither downloads Node by existing nor switches every future terminal automatically. Directory hooks shown in the documentation are additional shell integration, and some can install missing versions, so their behavior deserves review.
This series uses fixed source and a 16-case experiment on extracted PATH and .nvmrc helpers in isolated Bash children. It did not install nvm or Node, change profiles, run the entire upstream suite or qualify any production deployment. The MIT-licensed project is evaluated through these stated boundaries rather than an invented speed or compatibility ranking.
Implementation steps
- 1
Identify your operating environment and shell.
- 2
Check whether the shell has loaded nvm.
- 3
Record the project runtime requirement separately from manager version.
- 4
Verify the actual selected binary before running project tests.
Copy-ready example
# Inspection only; assumes nvm is already loaded
command -v nvm
nvm --version
nvm current
nvm which current
node --versionFrequently asked questions
Does switching nvm update a running server?
No. Existing processes retain the executable and environment they started with. Select the intended version before launching a new process.
Is this the same as a native Windows nvm program?
No. This series covers nvm-sh/nvm and its shell model. Other Windows implementations have separate maintainers and behavior.
Sources
- README.mdSource checked 2026-09-08
- package.jsonSource checked 2026-09-08
- LICENSE.mdSource checked 2026-09-08
- nvm.shSource checked 2026-09-08