nvm: Node versions and shell state
nvm quickstart: distinguish install, use, current and .nvmrc
Build a predictable first workflow using an explicit runtime and verify the difference between a project version request and the active Node binary.
What you will learn
- Start after installation has been consciously approved
- Project intent and active state can disagree
- Verify the command path, not just a success banner
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
- Install creates availability; use selects a runtime in the shell.
- An exact version is more reproducible than a moving selector.
- Check current when .nvmrc intent and actual execution disagree.
Start after installation has been consciously approved
The upstream installer downloads manager files and may append loading lines to a shell profile. Review that action separately from using an already installed manager. The following commands assume an approved installation loaded in a compatible shell; this review did not execute them against the user environment or download a Node distribution.
For a concrete exercise, choose one exact version already approved for your project. The example uses 24.14.0 as a fixed fixture value, not a recommendation that it is the newest or the right production version. nvm install can download and install the requested runtime, while nvm use selects an installed version and changes the shell environment.
Project intent and active state can disagree
A .nvmrc file can contain a version number or another recognized selector, with comments and whitespace under the documented format. Commands such as use, install and which can consult it when their version argument is omitted. Lookup walks upward from the current directory, so a parent file can govern a nested package that has no closer file.
The current selector means the version active in this shell and is not overridden by .nvmrc. This makes nvm which current useful for diagnosing a mismatch between project intent and actual execution. The README warns that omitted-version run and exec behavior can fall back to active Node when no file resolves; pass a version explicitly in scripts that require predictable behavior.
Verify the command path, not just a success banner
After selecting a runtime, inspect node --version and its resolved executable. Existing aliases, functions, custom directories or another manager may affect command resolution. The source intentionally preserves some PATH ordering, so a claim that every switch unconditionally puts its directory ahead of every custom entry would be incorrect.
Check the package manager and project test result too. Global npm packages belong to the selected installation context, and a custom npm prefix can conflict with nvm. Do not respond to a missing global command by immediately running a privileged install; first establish which Node and npm you are using and whether the project should use a local dependency instead.
Implementation steps
- 1
Confirm nvm is loaded and review the chosen runtime version.
- 2
Install the exact version only if that machine change is authorized.
- 3
Select it explicitly and inspect the resolved node path.
- 4
Run the project acceptance checks with the intended package manager.
Copy-ready example
# Optional exercise after approved nvm setup; not executed here
nvm install 24.14.0
nvm use 24.14.0
nvm which current
node --version
npm --version
# Explicit version avoids omitted-version fallback:
nvm exec 24.14.0 node --versionFrequently asked questions
Does writing .nvmrc switch my terminal immediately?
No. A command or separately configured directory hook must apply it. The file alone records a request.
Why can current differ from the project file?
Current reports the active shell runtime. The file may request another version that has not been selected or installed.