- `nvm-exec` test: expect "Found .nvmrc" message in output, since `nvm_rc_version` now outputs it to stdout via fd 3 redirection (ef162036)
- `nvm_install_binary_nosource`: fix exit code capture by running the command directly instead of inside a subshell with `echo $?` (05d78477)
- `nvm_iojs_version_has_solaris_binary`: bare versions like `v3.3.1` (without `iojs-` prefix) are node versions and should be rejected. The old tests relied on the buggy comparison that let them through (53e6244a)
- `nvm_get_arch_unofficial`: copy `uname` into the chroot. The old test passed only because the unconditional `NVM_ARCH=x64-musl` masked the missing binary, but the `case` fix now requires a real arch to match (39e71eab)
If directory creation fails (e.g., permissions), the script would continue and fail with confusing errors later.
Fail early with a clear error message instead.
Bugs introduced in 68bf93514b, 6cee20a071, and 703babe60a.
- Use `=` instead of `==` for string comparison (POSIX compliance)
- Use `printf '%b'` instead of variable as format string (prevents `%` characters in paths from being interpreted as format specifiers)
- Fix `TRIED_PROFILE` to reference `PROFILE` instead of `NVM_PROFILE` which is known to be empty at that point
Bugs introduced in a24ff3e605, b6f1c156da, and a461a0fffc (PR https://github.com/nvm-sh/nvm/pull/1605).
`${2}` was empty because positional parameters had been consumed by `shift` in the argument parsing loop.
Use `${provided_version}` which holds the resolved alias name.
Bug introduced in 1c00753fd9.
The `*` glob was inside double quotes, preventing shell expansion. `nvm_grep -l` received a literal `*` filename instead of the list of alias files, so aliases pointing to uninstalled versions were never cleaned up.
Bug introduced in 7807a9f09e.
Missing `_` prefix on the right side of the comparison meant the guard clause that rejects non-iojs versions almost never matched, allowing non-iojs versions to fall through.
Bug introduced in 2d692d9d78 / #854.
`return` inside `(...)` subshells only exits the subshell, not the calling function.
Errors in mkdir, download, and checksum verification were silently ignored.
Use `{ ...; }` brace groups instead.
Bug introduced in ba3ad8e460.
When `nosource=1` (the `-b` flag) and binary download fails, the function returned 0 (success) instead of a non-zero exit code, masking the installation failure.
Bug introduced in 4fdef427e4 / #2439.
Alpine detection unconditionally set `x64-musl` regardless of actual architecture, which would be incorrect on ARM-based Alpine containers.
Bug introduced in ef7fc2f2c0 / #3212.
Fixes#3616.
Other `uname` calls in the file use `command uname` to bypass any user aliases or functions.
This one was missing it.
Bug introduced in 779a34e6a9 / #2469.
Using a variable as the format string means `%` characters in alias names would be interpreted as format specifiers.
Use `%b` format with the variable as an argument to safely interpret `\n` escapes.
Bug introduced in 9b91734f0b.
The awk expression `$0 ~ "regex"` as a bare statement in the action block evaluates the match but doesn't affect the exit code.
awk always prints the line and exits 0, making the validation a no-op.
Bug introduced in b1fa143dd8.
`return $A || $B` only evaluates the first argument, since `return` always succeeds.
The io.js exit code was never checked, silently swallowing remote listing failures.
Bug introduced in ea12784629 / #616.
The error message for using `-s` and `-b` together was calling
`nvm err` (invoking nvm with subcommand "err") instead of the
`nvm_err` helper function, causing the error message to never be displayed and instead showing the help text with exit code 127.
Bug introduced in 4fdef427e4 / #2439
Colors were lost because `nvm_has_colors` checks `[ -t 1 ]`, which is false inside the `(...) | sort` pipeline in `nvm_list_aliases`.
Evaluate `nvm_has_colors` before the pipe and propagate via `NVM_HAS_COLORS`, matching the approach used by `nvm_print_versions`.
Bug introduced in 35212c1346.
Add `--offline` flag to `nvm install` that resolves versions using only locally installed versions and cached downloads. No network calls are made.
New helper functions `nvm_ls_cached` and `nvm_offline_version` scan `$NVM_DIR/.cache/bin/` for previously downloaded tarballs.
In offline mode, `nvm_download_artifact` returns cached tarballs directly without checksum verification or download attempts.
The curl/wget requirement is skipped when `--offline` is set.
Supports `--lts` via locally stored LTS alias files.
Add `try` and `try_err` helper functions to `test/common.sh` that capture stdout/stderr and exit code from a single invocation, eliminating duplicate command executions in tests.
Convert all existing tests that used the `OUTPUT`/`EXIT_CODE` double-invocation pattern to use the new helpers.
Also fixes a pre-existing bug in the `nvm_die_on_prefix` test where ASCII apostrophes were used instead of U+2019 to match nvm.sh output.
Normalize `nvm_version` output when `nvm_ls` returns "system vX" so alias and .nvmrc resolutions treat system correctly.
Add fast tests for system alias behavior in `nvm ls`, `nvm use`, and `nvm which`.
Move .github/copilot-instructions.md to AGENTS.md, and generalize the
wording, so it will apply to Codex CLI, Cursor, OpenCode, RooCode, and
many other AI coding agents.
Also add CLAUDE.md as a symlink to AGENTS.md so Claude Code reads the
same guidance.
Copilot coding agent now supports AGENTS.md custom instructions, as
more coding agents support it. Migrating from GitHub Copilot's custom
instructions file to AGENTS.md will help developers leverage more and
different coding agents than just GitHub Copilot.
Reference:
- https://agents.md/
- https://github.blog/changelog/2025-08-28-copilot-coding-agent-now-supports-agents-md-custom-instructions/
nvm.sh uses `NVM_SCRIPT_SOURCE="$_"` to detect its source location.
Adding `: nvm.sh` before each source line ensures `$_` is set correctly, preventing breakage when the previous command (e.g., `set -ex`) overwrites it.
Old Node.js versions have Makefiles with unquoted glob patterns like
`rm -f *.o` that fail in zsh's strict glob mode. By passing
SHELL=/bin/sh to make, we ensure POSIX-compliant shell behavior
regardless of what shell nvm is running in.
[Tests] `install.sh`: add tests for PROFILE=/dev/null profile skip
Verify that when PROFILE="/dev/null" is set:
- The "Profile not found" warning is suppressed
- Profile modification is skipped as expected
Co-authored-by: Wes Todd <wes@wesleytodd.com>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
Inserted missing colons in specific parts of the text to maintain consistency with the existing format. This adjustment ensures a uniform writing style, improves readability, and aligns the text structure with the rest of the document.
Previously, `nvm install Argon` would succeed by matching the LTS name
in the version description (e.g., "v4.9.1 (Latest LTS: Argon)"), but
`nvm uninstall Argon` would fail because "Argon" is not a valid alias or not a valid version.
Changes:
- Added pattern matching check in nvm_remote_version (nvm.sh:785-791)
- Skips check for implicit aliases (node, stable, etc.) to preserve
existing functionality
- Added unit tests to verify LTS names are rejected while version
numbers still work
After this fix:
- `nvm install Argon` → fails (use `nvm install lts/argon` instead)
- `nvm install 4` → still works
- `nvm install node` → still works
- `nvm install lts/argon` → still works
This makes install and uninstall behavior consistent.
Fixes#3474.
When `.nvmrc` or alias files contained comments (lines with `#`),
the `#` character could end up in the search pattern passed to sed,
causing "unterminated regular expression" errors because `#` is
used as the sed address delimiter.
This commit fixes the issue in two places:
1. `nvm_alias`: Strip comments from alias file contents before
returning them, and trim trailing whitespace
2. `nvm_ls`: Escape `#` characters in SEARCH_PATTERN so they're
treated as literal characters in the sed address
Fixes#3761
The Debian WSL image has stale apt sources pointing to ftp.debian.org
which no longer hosts bullseye-backports. The previous fix ran sed
after the first setup-wsl call, but that call already failed because
additional-packages triggers apt-get update internally.
For wsl_matrix (Debian, Ubuntu):
- Ubuntu: install with additional-packages directly (no apt issue)
- Debian: install without packages first, fix sources.list with sed,
then run apt-get update/upgrade/install manually with retries
- Exclude Debian and Ubuntu-20.04 --lts since node v24+ has exec
format errors on WSL1
For wsl_matrix_unofficial (Alpine):
- Remove the Debian-specific fix entirely (Alpine uses apk, not apt)
See https://github.com/Vampire/setup-wsl/issues/76
The script assumes that the name of the remote is `origin`, but this
is not the case if the user has set `clone.defaultRemoteName` to
another value in the ~/.gitconfig (or elsewhere in the configuration).
Adding `-o origin` ensures that the remote will be called `origin`
regardless of the `clone.defaultRemoteName` setting.
Per PR #3341:
- The minimum Git version this should work with is v1.7.10. (This is not
documented in the repo itself; it's just an implicit requirement.)
- The `--origin` option was added to `git clone` in commit 98a4fef3f2 which
was released in v1.2.5. From the diff of that commit, the `-o` option was
already available at that time. So this easily satisfies the above.
- A comment in #3341 indicates that `-o` was added in v1.1.0. I've not
verified this, but we probably don't need to track that down since by the
above we're already well within requirements.
This comprehensive guide helps GitHub Copilot better understand and navigate the nvm codebase by providing:
- Complete architecture explanation of nvm's POSIX-compliant design across multiple shells
- Detailed mapping of top-level commands to internal functions (install, use, ls, alias, etc.)
- Comprehensive testing infrastructure guide using urchin framework
- Shell environment setup for bash, zsh, dash, sh, and ksh
- CI environment details for GitHub Actions and Travis CI
- shellcheck setup and usage guidelines
- Development best practices for POSIX compliance and multi-shell compatibility
- Windows support via WSL2, Cygwin, and Git Bash
- Complete internal function categorization and debugging techniques
The documentation covers all aspects of the codebase to enable more accurate AI assistance when working with nvm's complex shell script architecture.
New Stuff
- `install.sh`: add `$ZDOTDIR` to zsh search (#3458)
Fixes
- `reinstall-packages`: do not reinstall corepack (#3544)
- avoid bash-specific syntax (#3499)
- `install-latest-npm`: npm v11 is out
- `nvm_install_latest_npm`: avoid unbound variable (#3447)
- give a more helpful message when `lts` alias is mistakenly used (#3441)
- `nvm ls`, `nvm alias`, `nvm install`: error when an LTS name is invalid
- `nvm_normalize_lts`: error when an LTS name is not lowercase (#3417)
Documentation
- [readme] update link
- [readme] fix `--no-use` example (#3479)
- [readme] update copyright notice (#3507)
- [readme] note zsh-nvm's AUTO_USE option (#2670)
- [readme] add note about reloading zshrc after editing (#3052)
- [readme] Update shell profile file install notes (#2241)
- [readme] add docker tips (#2318)
- [readme] remove `avn` from readme (#3469)
- [readme] fnm -> nvm.fish (#2541)
Refactors
- prefer `case` over if/else chains
- combine `sed -e` invocations/arguments
Tests
- `nvm exec`/`nvm run`: add `--silent` tests (#1259)
- [actions] release test needs git tags
- migrate `installation_iojs` test suite to GitHub Actions (#3476)
- Migrate slow test suite from Travis CI (#3470)
- temporarily skip this failing travis test to unblock progress
- [actions] TOC: use latest LTS node
- `install.sh`: clean up `nvm_detect_profile` tests
- `nvm_detect_profile`: refactor (#3467)
- run urchin tests on pull requests (#3466)
- update mocks
- ensure that unit tests use only mocked LTS names
- [actions] use `node/install` instead of `node/run`
Meta
- disable blank issues
- update issue template
- add DCO (#3456)
- Rename .github/ISSUE_TEMPLATE.md to .github/ISSUE_TEMPLATE/ISSUE_TEMPLATE.md (#3454)
In theory, `npx nvmrc` can now be used to validate an `.nvmrc` file that `nvm` will support. Allowances have been made for future extensibility, and aliases may no longer contain a `#`.
Fixes#3336. Closes#2288.
Co-authored-by: Jordan Harband <ljharb@gmail.com>
Co-authored-by: Yash Singh <saiansh2525@gmail.com>
Path lists in environmental variables often give special meaning to
empty entries (e.g. in PATH or MANPATH). These are represented by
leading or trailing colons, or by doubled colons in the middle of the
list.
Adjust the awk invocation to correctly deal with trailing colons by
printing the separator before every field except the first, and then
printing the final separator that is read from the input - this will
either be a colon or the null string. This preserves leading and
trailing colons in all cases while not adding extra colons in the wrong
place.
Add test to confirm the correct behaviour.
Fixes#3144
I had to dig into #2410 to learn about the `PROFILE=/dev/null` technique to install without appending to my shell config. Figured this note would be good to add in the main installation docs.
Also added a note on how to do this as a one-liner which was not obvious for me.
the `nvm.sh` file assigns and exports an `NVM_CD_FLAGS` variable if it
was sourced from a zsh shell. the fact that it's exported means that
it'll be assigned in all child processes, including the `nvm-exec`
script, which uses bash as the interpreter.
Bash's `cd` command doesn't have a `-q` flag, so if the `NVM_CD_FLAGS`
is assigned `-q`, the script will error out and incorrectly claim that
the node version isn't installed.
this also manifests itself in the `nvm exec` command.
Example:
```console
$ nvm exec 16.14.0 npm --version
Running node v16.14.0 (npm v8.3.1)
/Users/<ME>/.nvm/nvm.sh: line 28: cd: -q: invalid option
cd: usage: cd [-L|[-P [-e]] [-@]] [dir]
both the tree and the node path are required
N/A: version "v16.14.0 -> N/A" is not yet installed.
You need to run "nvm install v16.14.0" to install it before using it.
```
To address this, we unset the `NVM_CD_FLAGS` at the start of the
`nvm-exec` script, before loading `nvm.sh`.
Remove the call to `ls` that was used to determine the symlink
destination
Reasoning :
* `od` resolves symlink itself due to the use of `fopen`
* Prevent the behaviour of `od` which will hang if the filename is
empty (i.e. `/sbin/init` missing) as it will be waiting for `stdin`
compared to quitting with error if the file just doesn't exist
Fixes#3006
Incorporates old Contributing.md with more thorough details on how to contribute, create bug reports, set up the dev environment, and creating PR's itself.
No need to escape the `/` char in a grep pattern.
This is to fix the below error when using newer grep with `nvm_command_info`
> $ nvm_command_info curl
> grep: warning: stray \ before /
> /usr/bin/curl
This happens with at least GNU grep 3.8 version.
Fixes#2860.
This fixes these two linting errors:
- fqcn-builtins: Use FQCN for builtin actions.
- name: All names should start with an uppercase letter. (name[casing])
`nvm install` fails with "Binary download failed, trying source" when
- running on Bash;
- errtrace (`set -E`) is enabled;
- an ERR trap uses `exit` to return a non-zero status; and
- /sbin/init doesn't exist.
Resolved by moving `ls -dl /sbin/init` to the following `if` statement.
In this context, returning non-zero isn't an error and the ERR trap
isn't executed.
Nesting the `elif` at the same level as the `if` and `fi` makes it clear which code applies to which branch (no .nvmrc file / found .nvmrc file).
I wasted a while looking at it trying to work out how it did anything if there was a .nvmrc file, because obviously the `if` didn't match and I couldn't see the `elif` branch.
We take the security of **nvm** very seriously. If you believe you’ve found a security vulnerability, please inform us responsibly through coordinated disclosure.
### How to Report
> **Do not** report security vulnerabilities through public GitHub issues, discussions, or social media.
Instead, please use one of these secure channels:
1.**GitHub Security Advisories**
Use the **Report a vulnerability** button in the Security tab of the [nvm-sh/nvm repository](https://github.com/nvm-sh/nvm).
2.**Email**
Follow the posted [Security Policy](https://github.com/nvm-sh/nvm/security/policy).
### What to Include
**Required Information:**
- Brief description of the vulnerability type
- Affected version(s) and components
- Steps to reproduce the issue
- Impact assessment (what an attacker could achieve)
**Helpful Additional Details:**
- Full paths of affected scripts or files
- Specific commit or branch where the issue exists
- Required configuration to reproduce
- Proof-of-concept code (if available)
- Suggested mitigation or fix
## Our Response Process
**Timeline Commitments:**
- **Initial acknowledgment**: Within 24 hours
- **Detailed response**: Within 3 business days
- **Status updates**: Every 7 days until resolved
- **Resolution target**: 90 days for most issues
**What We’ll Do:**
1. Acknowledge your report and assign a tracking ID
2. Assess the vulnerability and determine severity
3. Develop and test a fix
4. Coordinate disclosure timeline with you
5. Release a security update and publish an advisory and CVE
6. Credit you in our security advisory (if desired)
## Disclosure Policy
- **Coordinated disclosure**: We’ll work with you on timing
- **Typical timeline**: 90 days from report to public disclosure
- **Early disclosure**: If actively exploited
- **Delayed disclosure**: For complex issues
## Scope
**In Scope:**
- **nvm** project (all supported versions)
- Installation and update scripts (`install.sh`, `nvm.sh`)
- Official documentation and CI/CD integrations
- Dependencies with direct security implications
**Out of Scope:**
- Third-party forks or mirrors
- Platform-specific installs outside core scripts
- Social engineering or physical attacks
- Theoretical vulnerabilities without practical exploitation
## Security Measures
**Our Commitments:**
- Regular vulnerability scanning via GitHub Actions
- Automated security checks in CI/CD pipelines
- Secure scripting practices and mandatory code review
- Prompt patch releases for critical issues
**User Responsibilities:**
- Keep **nvm** updated
- Verify script downloads via PGP signatures
- Follow secure configuration guidelines for shell environments
## Legal Safe Harbor
**We will NOT:**
- Initiate legal action
- Contact law enforcement
- Suspend or terminate your access
**You must:**
- Only test against your own installations
- Not access, modify, or delete user data
- Not degrade service availability
- Not publicly disclose before coordinated disclosure
- Act in good faith
## Recognition
- **Advisory Credits**: Credit in GitHub Security Advisories (unless anonymous)
## Security Updates
**Stay Informed:**
- Subscribe to GitHub releases for **nvm**
- Enable GitHub Security Advisory notifications
**Update Process:**
- Patch releases (e.g., v0.40.3 → v0.40.4)
- Out-of-band releases for critical issues
- Advisories via GitHub Security Advisories
## Contact Information
- **Security reports**: Security tab of [nvm-sh/nvm](https://github.com/nvm-sh/nvm/security)
- **General inquiries**: GitHub Discussions or Issues
<!-- Thank you for being interested in nvm! Please help us by filling out the following form if you‘re having trouble. If you have a feature request, or some other question, please feel free to clear out the form. Thanks! -->
Please email [@ljharb](https://github.com/ljharb) or see https://tidelift.com/security if you have a potential security vulnerability to report.
Please file a private vulnerability report via GitHub, email [@ljharb](https://github.com/ljharb), or see https://tidelift.com/security if you have a potential security vulnerability to report.
## Escalation
If you do not receive an acknowledgement of your report within 6 business days, or if you cannot find a private security contact for the project, you may escalate to the OpenJS Foundation CNA at `security@lists.openjsf.org`.
If the project acknowledges your report but does not provide any further response or engagement within 14 days, escalation is also appropriate.
## OpenSSF CII Best Practices
[](https://bestpractices.coreinfrastructure.org/projects/684)
There are three “tiers”: passing, silver, and gold.
### Passing
We meet 100% of the “passing” criteria.
### Silver
We meet 100% of the “silver” criteria.
### Gold
We meet 78% of the “gold” criteria. The gaps are as follows:
- because we only have one maintainer, the project has no way to continue if that maintainer stops being active.
- We do not include a copyright or license statement in each source file. Efforts are underway to change this archaic practice into a suggestion instead of a hard requirement.
## Threat Model
See [THREAT_MODEL.md](.github/THREAT_MODEL.md).
## Incident Response Plan
Please see our [Incident Response Plan](.github/INCIDENT_RESPONSE_PLAN.md).
Threat model analysis assists organizations to proactively identify potential security threats and vulnerabilities, enabling them to develop effective strategies to mitigate these risks before they are exploited by attackers.
Furthermore, this often helps to improve the overall security and resilience of a system or application.
The aim of this section is to facilitate the identification of potential security threats and vulnerabilities that may be exploited by adversaries, along with possible outcomes and appropriate mitigations.
## Relevant assets and threat actors
The following assets are considered important for the `nvm` project:
-`nvm` source code and project documentation
- Underlying `nvm` dependencies
-`nvm` development infrastructure
-`nvm` installed devices including servers
The following threat actors are considered relevant to the `nvm` application:
- External malicious attackers
- Internal malicious attackers
- Services
- Malicious insider actors
- Third-party libraries
## Attack surface for external/internal attackers and services
In threat modeling, an attack surface refers to any possible point of entry that an attacker might use to exploit a system or application.
This includes all the paths and interfaces that an attacker may use to access, manipulate or extract sensitive data from a system.
By understanding the attack surface, organizations are typically able to identify potential attack vectors and implement appropriate countermeasures to mitigate risks.
In the following diagrams, _External Malicious Attacker_ applies to threat actors who do not yet have direct access to the `nvm` application and the underlying operating system, while the _Internal Malicious Attacker_ applies to an attacker with access to the device (computer, server), potentially after successfully exploiting a threat from the _External Malicious Attacker_ scenario.
**Please note that some of the external threats may be also exploitable from internal threats and vice versa.**
<img src="./external-threat-actor.png" alt="Fig.: Possible attacks from internal and external threat actors and services" />
Fig.: Possible attacks from internal and external threat actors and services
## Identified threats
The identified threats against the `nvm` application are as follows:
### Threat ID 1: `nvm` commands
Overview: The `nvm` commands and subcommands take user input for handling and executing appropriate functions from the project directory (or any parent directory).
When user-controlled inputs are not adequately validated and later passed to the `nvm` functions as a part of a command, an attacker might be able to execute operating system commands triggered by any parsing functionality.
Possible Outcome: Attacks against `nvm` commands could lead to unauthorized access to user data or unauthorized access to the device (i.e. laptop or server, depending on where `nvm` is installed), resulting in loss of user private data stored on the device, among other possibilities.
Recommendation: Input validation should be implemented to prevent attackers from requesting operating system commands.
Similarly, secure coding practices ought to be in place to minimize the risk of buffer overflow vulnerabilities.
### Threat ID 2: URI scheme
Overview: `nvm` commands heavily use the [Secure HyperText Transfer](https://datatracker.ietf.org/doc/html/rfc2660) protocol for `nvm` related actions.
Missing [scheme](https://datatracker.ietf.org/doc/html/rfc3986#section-3.1) validation for any `nvm` command might result in file retrieval, enumeration, file overwrite, or [path traversal](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/01-Testing_Directory_Traversal_File_Include) attacks.
An example of this could be path validation for [`nvm_download`](https://github.com/nvm-sh/nvm/blob/ef7fc2f2c06ad75fe7fbabf28d427561ae7b007d/nvm.sh#L118), among many other possibilities.
Possible Outcome: Security misconfiguration flaws for URI scheme may lead to unauthorized access to user data, as well as data integrity compromises.
Recommendation: Adequate input validation should be implemented to prevent attackers from enumerating, retrieving and writing to application files and paths.
### Threat ID 3: Communication channel
Overview: The `nvm` commands and its subcommands use network protocol to communicate with external services.
Insecure communication may allow malicious attackers to perform [_Man-in-the-Middle_](https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack) attacks in order to manipulate the data sent during the users’ active connection.
Possible Outcome: Usage of plaintext communication protocols, like HTTP could lead to data sniffing and modification through insecure communications channels.
Recommendation: Mitigation countermeasures such as data encryption should be in place to prevent data manipulation via insecure communication channels.
### Threat ID 4: Environment variables
Overview: Each `nvm` installation defines its environment variables, which should be secured from internal malicious attackers, preventing access control attack vectors.
Missing stringent restrictions on setting variables, might allow attackers to prepare various targeted attacks against other local users, who use `nvm` in their user space.
For example, [_Privilege Escalation_](https://owasp.org/Top10/A01_2021-Broken_Access_Control/), [_Command Injection_](https://cwe.mitre.org/data/definitions/77.html), as well as many other parser-related attacks.
Possible Outcome: Attacks against environment variables could lead to unauthorized access to the user space, resulting in the loss of user private data and disruptions in service availability.
Recommendation: Adequate hardening of configuration file permissions should be in place for all relevant configuration files, as this provides protection against attackers able to manipulate variables and inject malicious code.
## Attack surface for malicious insider actors and third-party libraries
The following diagram summarizes the main possible threats against the `nvm` project from malicious insider actors and third-party libraries:
<img src="./insider-threat-actor-and-libs.png" alt="Fig.: Possible attacks from insider threat actors and third-party libraries" />
Fig.: Possible attacks from insider threat actors and third-party libraries
The identified threats against the `nvm` project are as follows:
### Threat ID 1: Insider threat actor
**Overview**: An insider threat actor, such as an `nvm` project contributor or employee with access to the code base, might abuse their role in the organization to modify the `nvm` application source code.
For example, intentionally adding malicious code snippets, clearing logs after being written and/or modifying specific sections of the documentation.
**Recommendation**: Secure coding practices, code reviews, automated code scanning and separation of duties (i.e. requiring at least two developers to approve any code change) are potentially useful security controls to identify and mitigate vulnerabilities that may be introduced by an insider threat actor.
### Threat ID 2: Third-party libraries
**Overview**: Please note that while `nvm` does not currently make use of any third-party libraries, this might become an attack vector if that changes in the future.
Third-party libraries may introduce potential risks related to maintaining security requirements by third-party vendors.
As a result, third-party libraries used by the `nvm` project, might contain vulnerabilities, such as [_Buffer Overflows_](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow), [_Format String Vulnerabilities_](https://owasp.org/www-community/attacks/Format_string_attack), as well as many other types of weaknesses that, in a worst-case scenario may lead to _Remote Code Execution_ (_RCE_).
Additionally, the maintainer of a third-party dependency might introduce a vulnerability on purpose, or be compromised by an attacker that subsequently introduces vulnerable code.
**Possible Outcome**: Code vulnerabilities may lead to unauthorized access to user data, loss of user private data, service disruptions and reputation damage.
**Recommendation**: Third-party libraries should be kept up-to-date, applying patches to address publicly known vulnerabilities in a timely fashion.
Monitoring and logging capabilities should also be in place to detect and respond to potential attacks.
SLSA compliance may also be considered for further supply chain security hardening.
BODY="Updates the English nvm install snippet to [\`${NEW_VERSION}\`](https://github.com/nvm-sh/nvm/releases/tag/${NEW_VERSION}). The translation system handles other locales.
TAGS="$((echo "HEAD" && git tag --sort=-v:refname --merged HEAD --format='%(refname:strip=2) %(creatordate:short)' | grep '^v' | while read tag date; do
if [ "$(uname)" == "Darwin" ]; then
timestamp=$(date -j -f "%Y-%m-%d" "$date" +%s)
threshold=$(date -j -v-4y +%s)
else
timestamp=$(date -d "$date" +%s)
threshold=$(date -d "4 years ago" +%s)
fi
if [ $timestamp -ge $threshold ]; then echo "$tag"; fi
- if [ -n "${SHELL-}" ] && [ -n "${TEST_SUITE}" ]; then if [ "${TEST_SUITE}" = 'installation_iojs' ]; then travis_retry make TEST_SUITE=$TEST_SUITE URCHIN="$(npm bin)/urchin" test-$SHELL ; else make TEST_SUITE=$TEST_SUITE URCHIN="$(npm bin)/urchin" test-$SHELL; fi; fi
before_cache:
- if [ -n "$WITHOUT_CURL" ]; then sudo apt-get install curl -y ; fi
This document provides guidance for AI coding agents when working with the Node Version Manager (nvm) codebase.
## Overview
nvm is a version manager for Node.js, implemented as a POSIX-compliant function that works across multiple shells (sh, dash, bash, ksh, zsh). The codebase is primarily written in shell script and emphasizes portability and compatibility.
### Core Architecture
- **Main script**: `nvm.sh` - Contains all core functionality and the main `nvm()` function
1.**Quoting**: Always quote variables: `"${VAR}"` instead of `$VAR`
2.**POSIX compliance**: Avoid bash-specific features in portable sections
3.**Array usage**: Use `set --` for positional parameters instead of arrays, which are not supported in POSIX
4.**Local variables**: Declared with `local FOO` and then initialized on the next line (the latter is for ksh support)
## Development Best Practices
### Code Style
- Use 2-space indentation
- Follow POSIX shell guidelines for portability
- Prefix internal functions with `nvm_`
- Use `nvm_echo` instead of `echo` for output
- Use `nvm_err` for error messages
### Compatibility
- Test changes across all supported shells
- Avoid bash-specific features in core functionality
- Use `nvm_is_zsh` to check when zsh-specific behavior is needed
- Mock external dependencies in tests
### Performance
- Cache expensive operations (like remote version lists)
- Use local variables to avoid scope pollution
- Minimize subprocess calls where possible
- Implement lazy loading for optional features
### Debugging
- Use `nvm debug` command for environment information
- Enable verbose output with `set -x` during development
- Test with `NVM_DEBUG=1` environment variable
- Check `$NVM_DIR/.cache` for cached data issues
## Common Gotchas
1.**PATH modification**: nvm modifies PATH extensively; be careful with restoration
2.**Shell sourcing**: nvm must be sourced, not executed as a script
3.**Version resolution**: Aliases, partial versions, and special keywords interact complexly
4.**Platform differences**: Handle differences between Linux, macOS, and other Unix systems
5.**Network dependencies**: Many operations require internet access for version lists
6.**Concurrent access**: Multiple shells can conflict when installing versions simultaneously
## Windows Support
nvm works on Windows via several compatibility layers:
### WSL2 (Windows Subsystem for Linux)
- Full nvm functionality available
- **Important**: Ensure you're using WSL2, not WSL1 - see [Microsoft's WSL2 installation guide](https://docs.microsoft.com/en-us/windows/wsl/install) for up-to-date instructions
- Install Ubuntu or other Linux distribution from Microsoft Store
- Follow Linux installation instructions within WSL2
### Cygwin
- POSIX-compatible environment for Windows
- Download Cygwin from [cygwin.com](https://www.cygwin.com/install.html) and run the installer
- During installation, include these packages: bash, curl, git, tar, and wget
- May require additional PATH configuration
### Git Bash (MSYS2)
- Comes with Git for Windows
- Limited functionality compared to full Linux environment
- Some features may not work due to path translation issues, including:
- Binary extraction paths may be incorrectly translated
- Symlink creation may fail
- Some shell-specific features may behave differently
- File permissions handling differs from Unix systems
### Setup Instructions for Windows
#### WSL2 (recommended)
1. Install WSL2 using the official Microsoft guide: https://docs.microsoft.com/en-us/windows/wsl/install
2. Install Ubuntu or preferred Linux distribution from Microsoft Store
3. Follow standard Linux installation within WSL2
#### Git Bash
1. Install Git for Windows (includes Git Bash) from https://git-scm.com/download/win
2. Open Git Bash terminal
3. Run nvm installation script
#### Cygwin
1. Download and install Cygwin from https://www.cygwin.com/install.html
2. Include bash, curl, git, tar, and wget packages during installation
3. Run nvm installation in Cygwin terminal
This guide should help AI coding agents understand the nvm codebase structure, testing procedures, and development environment setup requirements.
`nvm`, as a member project of the OpenJS Foundation, uses [Contributor Covenant v1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct) as their code of conduct. The full text is included [below](#contributor-covenant-code-of-conduct) in English, and translations are available from the Contributor Covenant organisation:
`nvm`, as a member project of the OpenJS Foundation, uses [Contributor Covenant v2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct/) as their code of conduct. The full text is included [below](#contributor-covenant-code-of-conduct) in English, and translations are available from the Contributor Covenant organisation:
Refer to the sections on reporting and escalation in this document for the specific emails that can be used to report and escalate issues.
@@ -14,93 +14,112 @@ Refer to the sections on reporting and escalation in this document for the speci
For reporting issues in spaces related to `nvm` please use the email `ljharb@gmail.com`. `nvm` handles CoC issues related to the spaces that it maintains. Projects maintainers commit to:
- maintain the confidentiality with regard to the reporter of an incident
- to participate in the path for escalation as outlined in
the section on Escalation when required.
- to participate in the path for escalation as outlined in the section on Escalation when required.
### Foundation Spaces
For reporting issues in spaces managed by the OpenJS Foundation, for example, repositories within the OpenJS organization, use the email `report@lists.openjsf.org`. The Cross Project Council (CPC) is responsible for managing these reports and commits to:
For reporting issues in spaces managed by the OpenJS Foundation, for example, repositories within the OpenJS organization, use the email `report@lists.openjsf.org`.
The Cross Project Council (CPC) is responsible for managing these reports and commits to:
- maintain the confidentiality with regard to the reporter of an incident
- to participate in the path for escalation as outlined in
the section on Escalation when required.
- to participate in the path for escalation as outlined in the section on Escalation when required.
## Escalation
The OpenJS Foundation maintains a Code of Conduct Panel (CoCP). This is a foundation-wide team established to manage escalation when a reporter believes that a report to a member project or the CPC has not been properly handled. In order to escalate to the CoCP send an email to `coc-escalation@lists.openjsf.org`.
The OpenJS Foundation maintains a Code of Conduct Panel (CoCP).
This is a foundation-wide team established to manage escalation when a reporter believes that a report to a member project or the CPC has not been properly handled.
In order to escalate to the CoCP send an email to `coc-escalation@lists.openjsf.org`.
For more information, refer to the full [Code of Conduct governance document](https://github.com/openjs-foundation/cross-project-council/blob/master/CODE_OF_CONDUCT.md).
For more information, refer to the full [Code of Conduct governance document](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/CODE_OF_CONDUCT.md).
---
## Contributor Covenant Code of Conduct
# Contributor Covenant Code of Conduct
### Our Pledge
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
orientation.
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
### Our Standards
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Examples of behavior that contributes to creating a positive environment include:
## Our Standards
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of behavior that contributes to a positive environment for our community include:
Examples of unacceptable behavior by participants include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall community
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Publishing others' private information, such as a physical or email address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
### Our Responsibilities
## Enforcement Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
### Scope
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
### Enforcement
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at the email addresses listed above in
the [Reporting](#reporting) and [Escalation](#escalation) sections. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an
incident. Further details of specific enforcement policies may be posted
separately.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [@ljharb](ljharb@gmail.com).
All complaints will be reviewed and investigated promptly and fairly.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of actions.
**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct/](https://www.contributor-covenant.org/version/1/4/code-of-conduct/)
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at
:+1::tada: First off, thanks for taking the time to contribute to `nvm`! :tada::+1:
We love pull requests and issues, they're our favorite.
The following is a set of guidelines for contributing to `nvm` managed by [@LJHarb](https://github.com/ljharb), which is hosted on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
However, before submitting, please review the following:
For bug reports:
# How Can I Contribute?
- Please make sure the bug is reproducible, and give us the steps to reproduce it, so that we can dig into the problem.
- Please give us as much detail as possible about your environment, so we can more easily confirm the problem.
There are lots of ways to get involved. Here are some suggestions of things we'd love some help with.
For pull requests:
## Resolving existing issues
You can consider helping out with issues already requiring attention - look for a "help wanted" label.
### How Do I Submit a (Good) Bug Report? :bug:
Explain the problem and include additional details to help maintainers reproduce the problem:
* **Use a clear and descriptive title** for the issue to identify the problem.
* **Describe the exact steps which reproduce the problem** in as many details as possible. For example, start by explaining which command exactly you used in the terminal. When listing steps, **don't just say what you did, but explain how you did it**. For example, if you moved the cursor to the end of a line, explain if you used the mouse, or a keyboard shortcut or a command, and if so which one?
* **Provide specific examples to demonstrate the steps**. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use [Markdown code blocks](https://help.github.com/articles/markdown-basics/#multiple-lines).
* **Describe the behavior you observed after following the steps** and point out what exactly is the problem with that behavior.
* **Explain which behavior you expected to see instead and why.**
* **Provide as much context as possible** in order to help others verify and ultimately fix the issue. This includes giving us as many details as possible about your environment, so we can more easily confirm the problem.
## Documentation
We are happy to welcome contributions from anyone willing to improve documentation by adding missing information or making it more consistent and coherent.
# Dev Environment
Please refer to the [README](README.md) for complete instructions how to install, update, as well as troubleshoot `nvm` in your environment depending on your Operating System.
# Style Guide / Coding conventions
### Pull requests
#### Before creating a pull request
- Please include tests. Changes with tests will be merged very quickly.
- Please manually confirm that your changes work in `bash`, `sh`/`dash`, `ksh`, and `zsh`. Fast tests do run in these shells, but it's nice to manually verify also.
- Please maintain consistent whitespace - 2-space indentation, trailing newlines in all files, etc.
- Any time you make a change to your PR, please rebase freshly on top of master. Nobody likes merge commits.
- Any time you make a change to your PR, please rebase freshly on top of the default branch. Nobody likes merge commits.
Even if you don't have all of these items covered, please still feel free to submit a PR/issue! Someone else may be inspired and volunteer to complete it for you.
Thanks again!
#### How to create a pull request
Create a new branch
```
git checkout -b issue1234
```
Commit the changes to your branch, including a coherent commit message that follows our [standards](#commit-messages)
```
git commit -a
```
Before sending the pull request, make sure your code is running on the latest available code by rebasing onto the upstream source
```
git fetch upstream
git rebase upstream/main
```
Verify your changes
```
npm test
```
Push your changes
```
git push origin issue1234
```
Send the [pull request](https://docs.github.com/en/pull-requests), make requested changes, and get merged.
### Commit Messages
* Limit the first line of the commit message (message summary) to 72 characters or less.
* Use the present tense ("Add feature" not "Added feature") and imperative mood ("Move cursor to..." not "Moves cursor to...") when providing a description of what you did.
* If your PR addresses an issue, reference it in the body of the commit message.
* See the rest of the conventions [here](https://gist.github.com/ljharb/772b0334387a4bee89af24183114b3c7)
#### Commit message example
```
[Tag]: Short description of what you did
Longer description here if necessary
Fixes #1234
```
> **Note:** Add co-authors to your commit message for commits with multiple authors
```
Co-authored-by: Name Here <email@here>
```
# Code of Conduct
[Code of Conduct](https://github.com/nvm-sh/nvm/blob/HEAD/CODE_OF_CONDUCT.md)
# Where can I ask for help?
If you have any questions, please contact [@LJHarb](mailto:ljharb@gmail.com).
# Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
- The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
- The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
- The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
- I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
# Note that preexisting NVM_* variables are unset to avoid interfering with tests, except when running the Travis tests (where NVM_DIR must be passed in and the env. is assumed to be pristine).
.PHONY:$(SHELL_TARGETS)
$(SHELL_TARGETS):
@shell='$@';shell=$${shell##*-}; which "$$shell" >/dev/null ||{printf'\033[0;31m%s\033[0m\n'"WARNING: Cannot test with shell '$$shell': not found." >&2;exit 0;}&&\
@shell='$@';shell=$${shell##*-};\
which "$$shell" >/dev/null ||{printf'\033[0;31m%s\033[0m\n'"WARNING: Cannot test with shell '$$shell': not found." >&2;exit 0;}&&\
printf'\n\033[0;34m%s\033[0m\n'"Running tests in $$shell";\
[ -z "$$TRAVIS_BUILD_DIR"]&&for v in $$(set| awk -F'=''$$1 ~ "^NVM_" { print $$1 }');dounset$$v;done&&unset v;\
for suite in $(TEST_SUITE);do$(URCHIN) -f -s $$shell test/$$suite || exit;done
[ -z "$$TRAVIS_BUILD_DIR"]&&[ -z "$$GITHUB_ACTIONS"]&&for v in $$(set| awk -F'=''$$1 ~ "^NVM_" { print $$1 }');dounset$$v;done&&unset v;\
for suite in $(TEST_SUITE);do\
echo"Running test suite: $$suite";\
$(URCHIN) -f -s $$shell test/$$suite || exit;\
done
# All-tests target: invokes the specified test suites for ALL shells defined in $(SHELLS).
# Node Version Manager [][3] [][4] [](https://bestpractices.dev/projects/684)
<!-- To update this table of contents, ensure you have run `npm install` then `npm run doctoc` -->
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
@@ -10,6 +18,8 @@
- [Installing and Updating](#installing-and-updating)
- [Docker For Development Environment](#docker-for-development-environment)
- [Problems](#problems)
- [macOS Troubleshooting](#macos-troubleshooting)
- [WSL Troubleshooting](#wsl-troubleshooting)
- [Maintainers](#maintainers)
- [Project Support](#project-support)
- [Enterprise Support](#enterprise-support)
- [License](#license)
- [Copyright notice](#copyright-notice)
@@ -62,25 +77,25 @@
**Example:**
```sh
$ nvm use 16
Now using node v16.9.1(npm v7.21.1)
$ nvm install 24
Now using node v24.14.0(npm v11.9.0)
$ node -v
v16.9.1
$ nvm use 14
Now using node v14.18.0(npm v6.14.15)
v24.14.0
$ nvm use 22
Now using node v22.22.1(npm v10.9.4)
$ node -v
v14.18.0
$ nvm install 12
Now using node v12.22.6(npm v6.14.5)
v22.22.1
$ nvm use 20
Now using node v20.20.1(npm v10.8.2)
$ node -v
v12.22.6
v20.20.1
```
Simple as that!
## About
nvm is a version manager for [node.js](https://nodejs.org/en/), designed to be installed per-user, and invoked per-shell. `nvm` works on any POSIX-compliant shell (sh, dash, ksh, zsh, bash), in particular on these platforms: unix, macOS, and [windows WSL](https://github.com/nvm-sh/nvm#important-notes).
nvm is a version manager for [node.js](https://nodejs.org/en/), designed to be installed per-user, and invoked per-shell. `nvm` works on any POSIX-compliant shell (sh, dash, ksh, zsh, bash), in particular on these platforms: unix, macOS, and [Windows WSL](https://github.com/nvm-sh/nvm#important-notes).
<a id="installation-and-update"></a>
<a id="install-script"></a>
@@ -90,13 +105,13 @@ nvm is a version manager for [node.js](https://nodejs.org/en/), designed to be i
To **install** or **update** nvm, you should run the [install script][2]. To do that, you may either download and run the script manually, or use the following cURL or Wget command:
Running either of the above commands downloads a script and runs it. The script clones the nvm repository to `~/.nvm`, and attempts to add the source lines from the snippet below to the correct profile file (`~/.bash_profile`, `~/.zshrc`, `~/.profile`, or `~/.bashrc`).
Running either of the above commands downloads a script and runs it. The script clones the nvm repository to `~/.nvm`, and attempts to add the source lines from the snippet below to the correct profile file (`~/.bashrc`, `~/.bash_profile`, `~/.zshrc`, or`~/.profile`). If you find the install script is updating the wrong profile file, set the `$PROFILE` env var to the profile file’s path, and then rerun the installation script.
[ -s "$NVM_DIR/nvm.sh"]&&\."$NVM_DIR/nvm.sh" --no-use # This loads nvm, without auto-using the default version
```
- You can customize the install source, directory, profile, and version using the `NVM_SOURCE`, `NVM_DIR`, `PROFILE`, and `NODE_VERSION` variables.
Eg: `curl ... | NVM_DIR="path/to/nvm"`. Ensure that the `NVM_DIR` does not contain a trailing slash.
- The installer can use `git`, `curl`, or `wget` to download `nvm`, whichever is available.
- You can instruct the installer to not edit your shell config (for example if you already get completions via a [zsh nvm plugin](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/nvm)) by setting `PROFILE=/dev/null` before running the `install.sh` script. Here's an example one-line command to do that: `PROFILE=/dev/null bash -c 'curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash'`
#### Installing in Docker
When invoking bash as a non-interactive shell, like in a Docker container, none of the regular profile files are sourced. In order to use `nvm`, `node`, and `npm` like normal, you can instead specify the special `BASH_ENV` variable, which bash sources when invoked non-interactively.
```Dockerfile
# Use bash for the shell
SHELL["/bin/bash","-o","pipefail","-c"]
# Create a script file sourced by both interactive and non-interactive bash shells
ENV BASH_ENV ~/.bash_env
RUN touch "${BASH_ENV}"
RUNecho'. "${BASH_ENV}"' >> ~/.bashrc
# Download and install nvm
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh |PROFILE="${BASH_ENV}" bash
RUNecho node > .nvmrc
RUN nvm install
```
##### Installing in Docker for CICD-Jobs
More robust, works in CI/CD-Jobs. Can be run in interactive and non-interactive containers.
See https://github.com/nvm-sh/nvm/issues/3531.
```Dockerfile
FROMubuntu:latest
ARGNODE_VERSION=20
# install curl
RUN apt update && apt install curl -y
# install nvm
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash
# set env
ENVNVM_DIR=/root/.nvm
# install node
RUN bash -c "source $NVM_DIR/nvm.sh && nvm install $NODE_VERSION"
After creation of the image you can start container interactively and run commands, for example:
```
docker run --rm -it nvmimage
root@0a6b5a237c14:/# nvm -v
0.40.4
root@0a6b5a237c14:/# node -v
v19.9.0
root@0a6b5a237c14:/# npm -v
9.6.3
```
Noninteractive example:
```
user@host:/tmp/test $ docker run --rm -it nvmimage node -v
v19.9.0
user@host:/tmp/test $ docker run --rm -it nvmimage npm -v
9.6.3
```
#### Troubleshooting on Linux
On Linux, after running the install script, if you get `nvm: command not found` or see no feedback from your terminal after you type `command -v nvm`, simply close your current terminal, open a new terminal, and try verifying again.
@@ -136,7 +233,7 @@ If you get `nvm: command not found` after running the install script, one of the
- Since macOS 10.15, the default shell is `zsh` and nvm will look for `.zshrc` to update, none is installed by default. Create one with `touch ~/.zshrc` and run the install script again.
- If you use bash, the previous default shell, your system may not have a `.bash_profile` file where the command is set up. Create one with `touch ~/.bash_profile` and run the install script again. Then, run `source ~/.bash_profile` to pick up the `nvm` command.
- If you use bash, the previous default shell, your system may not have `.bash_profile` or `.bashrc` files where the command is set up. Create one of them with `touch ~/.bash_profile` or `touch ~/.bashrc` and run the install script again. Then, run `. ~/.bash_profile` or `. ~/.bashrc` to pick up the `nvm` command.
- You have previously used `bash`, but you have `zsh` installed. You need to manually add [these lines](#manual-install) to `~/.zshrc` and run `. ~/.zshrc`.
@@ -146,20 +243,22 @@ If you get `nvm: command not found` after running the install script, one of the
If the above doesn't fix the problem, you may try the following:
- If you use bash, it may be that your `.bash_profile` (or `~/.profile`) does not source your `~/.bashrc` properly. You could fix this by adding `source ~/<your_profile_file>` to it or follow the next step below.
- If you use bash, it may be that your `.bash_profile` (or `~/.profile`) does not source your `~/.bashrc` properly. You could fix this by adding `source ~/<your_profile_file>` to it or following the next step below.
- Try adding [the snippet from the install section](#profile_snippet), that finds the correct nvm directory and loads nvm, to your usual profile (`~/.bash_profile`, `~/.zshrc`, `~/.profile`, or `~/.bashrc`).
- For more information about this issue and possible workarounds, please [refer here](https://github.com/nvm-sh/nvm/issues/576)
**Note** For Macs with the Apple Silicon chip, node started offering **arm64** arch Darwin packages since v16.0.0 and experimental **arm64** support when compiling from source since v14.17.0. If you are facing issues installing node using `nvm`, you may want to update to one of those versions or later.
@@ -178,9 +277,9 @@ which should output `nvm` if the installation was successful. Please note that `
### Important Notes
If you're running a system without prepackaged binary available, which means you're going to install nodejs or io.js from its source code, you need to make sure your system has a C++ compiler. For OS X, Xcode will work, for Debian/Ubuntu based GNU/Linux, the `build-essential` and `libssl-dev` packages work.
If you're running a system without prepackaged binary available, which means you're going to install node or io.js from its source code, you need to make sure your system has a C++ compiler. For OS X, Xcode will work, for Debian/Ubuntu based GNU/Linux, the `build-essential` and `libssl-dev` packages work.
**Note:**`nvm` also support Windows in some cases. It should work through WSL (Windows Subsystem for Linux) depending on the version of WSL. It should also work with [GitBash](https://gitforwindows.org/) (MSYS) or [Cygwin](https://cygwin.com). Otherwise, for Windows, a few alternatives exist, which are neither supported nor developed by us:
**Note:**`nvm` also supports Windows in some cases. It should work through WSL (Windows Subsystem for Linux) depending on the version of WSL. It should also work with [GitBash](https://gitforwindows.org/) (MSYS) or [Cygwin](https://cygwin.com). Otherwise, for Windows, a few alternatives exist, which are neither supported nor developed by us:
@@ -191,17 +290,17 @@ If you're running a system without prepackaged binary available, which means you
- [bass](https://github.com/edc/bass) allows you to use utilities written for Bash in fish shell
- [fast-nvm-fish](https://github.com/brigand/fast-nvm-fish) only works with version numbers (not aliases) but doesn't significantly slow your shell startup
- [plugin-nvm](https://github.com/derekstavis/plugin-nvm) plugin for [Oh My Fish](https://github.com/oh-my-fish/oh-my-fish), which makes nvm and its completions available in fish shell
- [fnm](https://github.com/fisherman/fnm) - [fisherman](https://github.com/fisherman/fisherman)-based version manager for fish
- [nvm.fish](https://github.com/jorgebucaran/nvm.fish) - The Node.js version manager you'll adore, crafted just for Fish
- [fish-nvm](https://github.com/FabioAntunes/fish-nvm) - Wrapper around nvm for fish, delays sourcing nvm until it's actually used.
**Note:** We still have some problems with FreeBSD, because there is no official pre-built binary for FreeBSD, and building from source may need [patches](https://www.freshports.org/www/node/files/patch-deps_v8_src_base_platform_platform-posix.cc); see the issue ticket:
- [[#900] [Bug] nodejs on FreeBSD may need to be patched](https://github.com/nvm-sh/nvm/issues/900)
- [[#900] [Bug] node on FreeBSD may need to be patched](https://github.com/nvm-sh/nvm/issues/900)
**Note:** On OS X, if you do not have Xcode installed and you do not wish to download the ~4.3GB file, you can install the `Command Line Tools`. You can check out this blog post on how to just that:
- [How to Install Command Line Tools in OS X Mavericks & Yosemite (Without Xcode)](http://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/)
- [How to Install Command Line Tools in OS X Mavericks & Yosemite (Without Xcode)](https://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/)
**Note:** On OS X, if you have/had a "system" node installed and want to install modules globally, keep in mind that:
@@ -211,7 +310,7 @@ If you're running a system without prepackaged binary available, which means you
Homebrew installation is not supported. If you have issues with homebrew-installed `nvm`, please `brew uninstall` it, and install it using the instructions below, before filing an issue.
**Note:** If you're using `zsh` you can easily install `nvm` as a zsh plugin. Install [`zsh-nvm`](https://github.com/lukechilds/zsh-nvm) and run `nvm upgrade` to upgrade.
**Note:** If you're using `zsh` you can easily install `nvm` as a zsh plugin. Install [`zsh-nvm`](https://github.com/lukechilds/zsh-nvm) and run `nvm upgrade` to upgrade ([you can set](https://github.com/lukechilds/zsh-nvm#auto-use) `NVM_AUTO_USE=true` to have it automatically detect and use `.nvmrc` files).
**Note:** Git versions before v1.7 may face a problem of cloning `nvm` source from GitHub via https protocol, and there is also different behavior of git before v1.6, and git prior to [v1.17.10](https://github.com/git/git/commit/5a7d5b683f869d3e3884a89775241afa515da9e7) can not clone tags, so the minimum required git version is v1.7.10. If you are interested in the problem we mentioned here, please refer to GitHub's [HTTPS cloning errors](https://help.github.com/articles/https-cloning-errors/) article.
@@ -220,8 +319,8 @@ Homebrew installation is not supported. If you have issues with homebrew-install
If you have `git` installed (requires git v1.7.10+):
1. clone this repo in the root of your user profile
-`cd ~/` from anywhere then `git clone https://github.com/nvm-sh/nvm.git .nvm`
1.`cd ~/.nvm` and check out the latest version with `git checkout v0.39.0`
-`cd ~/` from anywhere then `git clone https://github.com/nvm-sh/nvm.git .nvm`
1.`cd ~/.nvm` and check out the latest version with `git checkout v0.40.4`
1. activate `nvm` by sourcing it from your shell: `. ./nvm.sh`
Now add these lines to your `~/.bashrc`, `~/.profile`, or `~/.zshrc` file to have it automatically sourced upon login:
@@ -285,6 +384,13 @@ To install a specific version of node:
nvm install 14.7.0 # or 16.3.0, 12.22.1, etc
```
To set an alias:
```sh
nvm alias my_alias v14.4.0
```
Make sure that your alias does not contain any spaces or slashes.
The first version installed becomes the default. New shells will start with the default version of node (e.g., `nvm alias default`).
You can list available versions using `ls-remote`:
@@ -338,10 +444,10 @@ Node has a [schedule](https://github.com/nodejs/Release#release-schedule) for lo
Any time your local copy of `nvm` connects to https://nodejs.org, it will re-create the appropriate local aliases for all available LTS lines. These aliases (stored under `$NVM_DIR/alias/lts`), are managed by `nvm`, and you should not modify, remove, or create these files - expect your changes to be undone, and expect meddling with these files to cause bugs that will likely not be supported.
To get the latest LTS version of node and migrate your existing installed packages, use
To get the latest LTS version of node and migrate your existing installed packages, use:
If you want to install a new version of Node.js and migrate npm packages from a previous version:
```sh
nvm install node --reinstall-packages-from=node
nvm install --reinstall-packages-from=node node
```
This will first use "nvm version node" to identify the current version you're migrating packages from. Then it resolves the new version to install from the remote server and installs it. Lastly, it runs "nvm reinstall-packages" to reinstall the npm packages from your prior version of Node to the new one.
@@ -357,8 +463,8 @@ This will first use "nvm version node" to identify the current version you're mi
You can also install and migrate npm packages from specific versions of Node like this:
```sh
nvm install6 --reinstall-packages-from=5
nvm install v4.2 --reinstall-packages-from=iojs
nvm install --reinstall-packages-from=56
nvm install --reinstall-packages-from=iojs v4.2
```
Note that reinstalling packages _explicitly does not update the npm version_ — this is to ensure that npm isn't accidentally upgraded to a broken version for the new node version.
@@ -366,7 +472,7 @@ Note that reinstalling packages _explicitly does not update the npm version_ —
To update npm at the same time add the `--latest-npm` flag, like this:
or, you can at any time run the following command to get the latest supported npm version on the current node version:
@@ -374,9 +480,25 @@ or, you can at any time run the following command to get the latest supported np
nvm install-latest-npm
```
If you've already gotten an error to the effect of "npm does not support Node.js", you'll need to (1) revert to a previous node version (`nvm ls` & `nvm use <your latest _working_ version from the ls>`, (2) delete the newly created node version (`nvm uninstall <your _broken_ version of node from the ls>`), then (3) rerun your `nvm install` with the `--latest-npm` flag.
If you've already gotten an error to the effect of "npm does not support Node.js", you'll need to (1) revert to a previous node version (`nvm ls` & `nvm use <your latest _working_ version from the ls>`), (2) delete the newly created node version (`nvm uninstall <your _broken_ version of node from the ls>`), then (3) rerun your `nvm install` with the `--latest-npm` flag.
### Offline Install
If you've previously downloaded a node version (or it's still in the cache), you can install it without any network access using the `--offline` flag:
```sh
nvm install --offline 14.7.0
```
This resolves versions using only locally installed versions and cached downloads. It will not attempt to download anything. This is useful in air-gapped environments, on planes, or when you want to avoid network latency.
You can combine `--offline` with `--lts` to install the latest cached LTS version (as long as LTS aliases have been populated by a prior `nvm ls-remote --lts`):
```sh
nvm install --offline --lts
```
### Default Global Packages From File While Installing
If you have a list of default packages you want installed every time you install a new version, we support that too -- just add the package names, one per line, to the file `$NVM_DIR/default-packages`. You can add anything npm would accept as a package argument on the command line.
@@ -391,7 +513,10 @@ stevemao/left-pad
### io.js
If you want to install [io.js](https://github.com/iojs/io.js/):
> [!WARNING]
> io.js was a [fork of Node.js](https://en.wikipedia.org/wiki/Node.js#History), created in 2014 and merged back in 2015. io.js shipped v1, v2, and v3 release lines; post-merge, node.js began releasing with v4.
If you want to install io.js:
```sh
nvm install iojs
@@ -400,7 +525,7 @@ nvm install iojs
If you want to install a new version of io.js and migrate npm packages from a previous version:
```sh
nvm install iojs --reinstall-packages-from=iojs
nvm install --reinstall-packages-from=iojs iojs
```
The same guidelines mentioned for migrating npm packages in node are applicable to io.js.
@@ -457,7 +582,7 @@ nvm set-colors rgBcm
#### Persisting custom colors
If you want the custom colors to persist after terminating the shell, export the NVM_COLORS variable in your shell profile. For example, if you want to use cyan, magenta, green, bold red and bold yellow, add the following line:
If you want the custom colors to persist after terminating the shell, export the `NVM_COLORS` variable in your shell profile. For example, if you want to use cyan, magenta, green, bold red and bold yellow, add the following line:
```sh
exportNVM_COLORS='cmgRY'
@@ -473,21 +598,23 @@ nvm help --no-colors
TERM=dumb nvm ls
```
#### Restoring PATH
### Restoring PATH
To restore your PATH, you can deactivate it:
```sh
nvm deactivate
```
#### Set default node version
### Set default node version
To set a default Node version to be used in any new shell, use the alias 'default':
```sh
nvm alias default node
nvm alias default node# this refers to the latest installed version of node
nvm alias default 18# this refers to the latest installed v18.x version of node
nvm alias default 18.12 # this refers to the latest installed v18.12.x version of node
```
#### Use a mirror of node binaries
### Use a mirror of node binaries
To use a mirror of the node binaries, set `$NVM_NODEJS_ORG_MIRROR`:
`nvm use` will not, by default, create a "current" symlink. Set `$NVM_SYMLINK_CURRENT` to "true" to enable this behavior, which is sometimes useful for IDEs. Note that using `nvm` in multiple shell tabs with this environment variable enabled can cause race conditions.
#### Pass Authorization header to mirror
To pass an Authorization header through to the mirror url, set `$NVM_AUTH_HEADER`
You can create a `.nvmrc` file containing a node version number (or any other string that `nvm` understands; see `nvm --help` for details) in the project root directory (or any parent directory).
@@ -525,7 +659,7 @@ $ echo "node" > .nvmrc # to default to the latest version
[NB these examples assume a POSIX-compliant shell version of `echo`. If you use a Windows `cmd` development environment, eg the `.nvmrc` file is used to configure a remote Linux deployment, then keep in mind the `"`s will be copied leading to an invalid file. Remove them.]
Then when you run nvm:
Then when you run nvm use:
```sh
$ nvm use
@@ -533,74 +667,93 @@ Found '/path/to/project/.nvmrc' with version <5.9>
Now using node v5.9.1 (npm v3.7.3)
```
Running nvm install will also switch over to the correct version, but if the correct node version isn't already installed, it will install it for you.
```sh
$ nvm install
Found '/path/to/project/.nvmrc' with version <5.9>
`nvm use` et. al. will traverse directory structure upwards from the current directory looking for the `.nvmrc` file. In other words, running `nvm use` et. al. in any subdirectory of a directory with an `.nvmrc` will result in that `.nvmrc` being utilized.
The contents of a `.nvmrc` file **must**be the `<version>` (as described by `nvm --help`) followed by a newline. No trailing spaces are allowed, and the trailing newline is required.
The contents of a `.nvmrc` file **must**contain precisely one `<version>` (as described by `nvm --help`) followed by a newline. `.nvmrc` files may also have comments. The comment delimiter is `#`, and it and any text after it, as well as blank lines, and leading and trailing white space, will be ignored when parsing.
Key/value pairs using `=` are also allowed and ignored, but are reserved for future use, and may cause validation errors in the future.
Run [`npx nvmrc`](https://npmjs.com/nvmrc) to validate an `.nvmrc` file. If that tool’s results do not agree with nvm, one or the other has a bug - please file an issue.
### Deeper Shell Integration
You can use [`avn`](https://github.com/wbyoung/avn) to deeply integrate into your shell and automatically invoke `nvm`when changing directories. `avn` is **not** supported by the `nvm` maintainers. Please [report issues to the `avn` team](https://github.com/wbyoung/avn/issues/new).
You can use [`nvshim`](https://github.com/iamogbz/nvshim) to shim the `node`, `npm`, and `npx` bins to automatically use the `nvm`config in the current directory. `nvshim` is **not** supported by the `nvm` maintainers. Please [report issues to the `nvshim` team](https://github.com/iamogbz/nvshim/issues/new).
If you prefer a lighter-weight solution, the recipes below have been contributed by `nvm` users. They are **not** supported by the `nvm` maintainers. We are, however, accepting pull requests for more examples.
#### bash
#### Calling `nvm use` automatically in a directory with a `.nvmrc` file
##### Automatically call `nvm use`
In your profile (`~/.bash_profile`, `~/.zshrc`, `~/.profile`, or `~/.bashrc`), add the following to `nvm use` whenever you enter a new directory:
##### bash
Put the following at the end of your `$HOME/.bashrc`:
This alias would search 'up' from your current directory in order to detect a `.nvmrc` file. If it finds it, it will switch to that version; if not, it will use the default version.
#### zsh
##### zsh
##### Calling `nvm use` automatically in a directory with a `.nvmrc` file
This shell function will install (if needed) and `nvm use` the specified Node version when an `.nvmrc` is found, and `nvm use default` otherwise.
Put this into your `$HOME/.zshrc` to call `nvm use` automatically whenever you enter a directory that contains an
`.nvmrc` file with a string telling nvm which node to `use`:
@@ -608,30 +761,34 @@ Put this into your `$HOME/.zshrc` to call `nvm use` automatically whenever you e
```zsh
# place this after nvm initialization!
autoload -U add-zsh-hook
load-nvmrc(){
localnode_version="$(nvm version)"
localnvmrc_path="$(nvm_find_nvmrc)"
localnvmrc_path
nvmrc_path="$(nvm_find_nvmrc)"
if[ -n "$nvmrc_path"];then
localnvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")
local nvmrc_node_version
nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")
`nvm` will encounter some issues if you have some non-default settings set. (see [#606](https://github.com/creationix/nvm/issues/606))
`nvm` will encounter some issues if you have some non-default settings set. (see [#606](https://github.com/nvm-sh/nvm/issues/606))
The following are known to cause issues:
Inside `~/.npmrc`:
@@ -777,19 +934,28 @@ set -e
## Installing nvm on Alpine Linux
In order to provide the best performance (and other optimisations), nvm will download and install pre-compiled binaries for Node (and npm) when you run `nvm install X`. The Node project compiles, tests and hosts/provides these pre-compiled binaries which are built for mainstream/traditional Linux distributions (such as Debian, Ubuntu, CentOS, RedHat et al).
In order to provide the best performance (and other optimizations), nvm will download and install pre-compiled binaries for Node (and npm) when you run `nvm install X`. The Node project compiles, tests and hosts/provides these pre-compiled binaries which are built for mainstream/traditional Linux distributions (such as Debian, Ubuntu, CentOS, RedHat et al).
Alpine Linux, unlike mainstream/traditional Linux distributions, is based on [BusyBox](https://www.busybox.net/), a very compact (~5MB) Linux distribution. BusyBox (and thus Alpine Linux) uses a different C/C++ stack to most mainstream/traditional Linux distributions - [musl](https://www.musl-libc.org/). This makes binary programs built for such mainstream/traditional incompatible with Alpine Linux, thus we cannot simply `nvm install X` on Alpine Linux and expect the downloaded binary to run correctly - you'll likely see "...does not exist" errors if you try that.
There is a `-s` flag for `nvm install` which requests nvm download Node source and compile it locally.
If installing nvm on Alpine Linux *is* still what you want or need to do, you should be able to achieve this by running the following from you Alpine Linux shell:
If installing nvm on Alpine Linux *is* still what you want or need to do, you should be able to achieve this by running the following from your Alpine Linux shell, depending on which version you are using:
_Note: Alpine 3.5 can only install NodeJS versions up to v6.9.5, Alpine 3.6 can only install versions up to v6.10.3, Alpine 3.7 installs versions up to v8.9.3, Alpine 3.8 installs versions up to v8.14.0, Alpine 3.9 installs versions up to v10.19.0, Alpine 3.10 installs versions up to v10.24.1, Alpine 3.11 installs versions up to v12.22.6, Alpine 3.12 installs versions up to v12.22.12, Alpine 3.13 & 3.14 install versions up to v14.20.0, Alpine 3.15 & 3.16 install versions up to v16.16.0 (**These are all versions on the main branch**). Alpine 3.5 - 3.12 required the package `python2` to build NodeJS, as they are older versions to build. Alpine 3.13+ requires `python3` to successfully build newer NodeJS versions, but you can use `python2` with Alpine 3.13+ if you need to build versions of node supported in Alpine 3.5 - 3.15, you just need to specify what version of NodeJS you need to install in the package install script._
The Node project has some desire but no concrete plans (due to the overheads of building, testing and support) to offer Alpine-compatible binaries.
As a potential alternative, @mhart (a Node contributor) has some [Docker images for Alpine Linux with Node and optionally, npm, pre-installed](https://github.com/mhart/alpine-node).
@@ -801,8 +967,12 @@ As a potential alternative, @mhart (a Node contributor) has some [Docker images
To remove `nvm` manually, execute the following:
First, use `nvm unload` to remove the nvm command from your terminal session and delete the installation directory:
```sh
$ rm -rf "$NVM_DIR"
$ nvm_dir="${NVM_DIR:-~/.nvm}"
$ nvm unload
$ rm -rf "$nvm_dir"
```
Edit `~/.bashrc` (or other shell resource config) and remove the lines below:
@@ -884,13 +1054,13 @@ You have to make sure that the user directory name in `$HOME` and the user direc
To change the user directory and/or account name follow the instructions [here](https://support.apple.com/en-us/HT201548)
zsh compinit: insecure directories, run compaudit for list.
@@ -899,69 +1069,126 @@ Ignore insecure directories and continue [y] or abort compinit [n]? y
Homebrew causes insecure directories like `/usr/local/share/zsh/site-functions` and `/usr/local/share/zsh`. This is **not** an `nvm` problem - it is a homebrew problem. Refer [here](https://github.com/zsh-users/zsh-completions/issues/680) for some solutions related to the issue.
**Macs with M1 chip**
**Macs with Apple Silicon chips**
_January 2021:_ there are no pre-compiled NodeJS binaries for versions prior to 15.x for Apple's new M1 chip (arm64 architecture).
Experimental support for the Apple Silicon chip architecture was added in node.js v15.3 and full support was added in v16.0.
Because of this, if you try to install older versions of node as usual, you will probably experience either compilation errors when installing node or out-of-memory errors while running your code.
Some issues you may encounter:
So, if you want to run a version prior to v16.0 on an Apple Silicon Mac, it may be best to compile node targeting the `x86_64` Intel architecture so that Rosetta 2 can translate the `x86_64` processor instructions to ARM-based Apple Silicon instructions.
Here's what you will need to do:
-using `nvm` to install, say, `v14.15.4`:
- the C code compiles successfully
- but crashes with an out of memory error when used
- increasing the memory available to node still produces the out of memory errors:
- when using `nvm` to install some versions, the compilation fails
-Install Rosetta, if you haven't already done so
One solution to this issue is to change the architecture of your shell from arm64 to x86.
```sh
$ softwareupdate --install-rosetta
```
Let's assume that:
- you already have versions `12.20.1` and `14.15.4` installed using `nvm`
- the current version in use is `14.15.4`
- you are using the `zsh` shell
- you have Rosetta 2 installed (macOS prompts you to install Rosetta 2 the first time you open a Intel-only non-command-line application, or you may install Rosetta 2 from the command line with `softwareupdate --install-rosetta`)
You might wonder, "how will my Apple Silicon Mac know to use Rosetta for a version of node compiled for an Intel chip?".
If an executable contains only Intel instructions, macOS will automatically use Rosetta to translate the instructions.
```sh
# Check what version you're running:
$ node --version
v14.15.4
# Check architecture of the `node` binary:
$ node -p process.arch
arm64
# This confirms that the arch is for the M1 chip, which is causing the problems.
# So we need to uninstall it.
# We can't uninstall the version we are currently using, so switch to another version:
$ nvm install v12.20.1
# Now uninstall the version we want to replace:
$ nvm uninstall v14.15.4
# Launch a new zsh process under the 64-bit X86 architecture:
$ arch -x86_64 zsh
# Install node using nvm. This should download the precompiled x64 binary:
$ nvm install v14.15.4
# Now check that the architecture is correct:
$ node -p process.arch
x64
# It is now safe to return to the arm64 zsh process:
$ exit
# We're back to a native shell:
$ arch
arm64
# And the new version is now available to use:
$ nvm use v14.15.4
Now using node v14.15.4 (npm v6.14.10)
```
- Open a shell that's running using Rosetta
```sh
$ arch -x86_64 zsh
```
Note: This same thing can also be accomplished by finding the Terminal or iTerm App in Finder, right clicking, selecting "Get Info", and then checking the box labeled "Open using Rosetta".
Note: This terminal session is now running in `zsh`.
If `zsh` is not the shell you typically use, `nvm` may not be `source`'d automatically like it probably is for your usual shell through your dotfiles.
If that's the case, make sure to source `nvm`.
```sh
$ source "${NVM_DIR}/nvm.sh"
```
- Install whatever older version of node you are interested in. Let's use 12.22.1 as an example.
This will fetch the node source code and compile it, which will take several minutes.
```sh
$ nvm install v12.22.1 --shared-zlib
```
Note: You're probably curious why `--shared-zlib` is included.
There's a bug in recent versions of Apple's system `clang` compiler.
If one of these broken versions is installed on your system, the above step will likely still succeed even if you didn't include the `--shared-zlib` flag.
However, later, when you attempt to `npm install` something using your old version of node.js, you will see `incorrect data check` errors.
If you want to avoid the possible hassle of dealing with this, include that flag.
For more details, see [this issue](https://github.com/nodejs/node/issues/39313) and [this comment](https://github.com/nodejs/node/issues/39313#issuecomment-90.40.476)
- Exit back to your native shell.
```sh
$ exit
$ arch
arm64
```
Note: If you selected the box labeled "Open using Rosetta" rather than running the CLI command in the second step, you will see `i386` here.
Unless you have another reason to have that box selected, you can deselect it now.
- Check to make sure the architecture is correct. `x64` is the abbreviation for `x86_64`, which is what you want to see.
This deletes your `resolv.conf` file that is automatically generated when you run WSL, creates a new file and puts `nameserver 8.8.8.8`, then creates a `wsl.conf` file and adds `[network]` and `generateResolveConf = false` to prevent auto-generation of that file.
You can check the contents of the file by running:
```sh
cat /etc/resolv.conf
```
## Maintainers
Currently, the sole maintainer is [@ljharb](https://github.com/ljharb) - more maintainers are quite welcome, and we hope to add folks to the team over time. [Governance](./GOVERNANCE.md) will be re-evaluated as the project evolves.
## Project Support
Only the latest version (v0.40.4 at this time) is supported.
## Enterprise Support
If you are unable to update to the latest version of `nvm`, our [partners](https://openjsf.org/ecosystem-sustainability-program) provide commercial security fixes for all unsupported versions:
Copyright [OpenJS Foundation](https://openjsf.org) and `nvm` contributors. All rights reserved. The [OpenJS Foundation](https://openjsf.org) has registered trademarks and uses trademarks. For a list of trademarks of the [OpenJS Foundation](https://openjsf.org), please see our [Trademark Policy](https://trademark-policy.openjsf.org/) and [Trademark List](https://trademark-list.openjsf.org/). Node.js is a trademark of Joyent, Inc. and is used with its permission. Trademarks and logos not indicated on the [list of OpenJS Foundation trademarks](https://trademark-list.openjsf.org) are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
Copyright [OpenJS Foundation](https://openjsf.org) and `nvm` contributors. All rights reserved. The [OpenJS Foundation](https://openjsf.org) has registered trademarks and uses trademarks. For a list of trademarks of the [OpenJS Foundation](https://openjsf.org), please see our [Trademark Policy](https://trademark-policy.openjsf.org/) and [Trademark List](https://trademark-list.openjsf.org/). Trademarks and logos not indicated on the [list of OpenJS Foundation trademarks](https://trademark-list.openjsf.org) are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
EXPECTED_OUTPUT="Aliases with a comment delimiter (#) are not supported."
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias with a hash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to create an alias with a hash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
try_err nvm alias foo# baz
EXPECTED_OUTPUT="Aliases with a comment delimiter (#) are not supported."
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias ending with a hash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to create an alias ending with a hash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
try_err nvm alias \#bar baz
EXPECTED_OUTPUT="Aliases with a comment delimiter (#) are not supported."
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias starting with a hash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to create an alias starting with a hash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
EXPECTED_OUTPUT="Aliases in subdirectories are not supported."
[ "$OUTPUT" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias with a slash should fail with '$EXPECTED_OUTPUT', got '$OUTPUT'"
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias with a slash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to create an alias with a slash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
EXIT_CODE="$(nvm alias foo/bar baz >/dev/null 2>&1 ; echo $?)"
[ "$EXIT_CODE" = "1" ] || die "trying to create an alias with a slash should fail with code 1, got '$EXIT_CODE'"
OUTPUT="$(nvm alias foo/ baz 2>&1)"
try_err nvm alias foo/ baz
EXPECTED_OUTPUT="Aliases in subdirectories are not supported."
[ "$OUTPUT" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias ending with a slash should fail with '$EXPECTED_OUTPUT', got '$OUTPUT'"
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias ending with a slash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to create an alias ending with a slash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
EXIT_CODE="$(nvm alias foo/ baz >/dev/null 2>&1 ; echo $?)"
[ "$EXIT_CODE" = "1" ] || die "trying to create an alias ending with a slash should fail with code 1, got '$EXIT_CODE'"
OUTPUT="$(nvm alias /bar baz 2>&1)"
try_err nvm alias /bar baz
EXPECTED_OUTPUT="Aliases in subdirectories are not supported."
[ "$OUTPUT" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias starting with a slash should fail with '$EXPECTED_OUTPUT', got '$OUTPUT'"
EXIT_CODE="$(nvm alias /bar baz >/dev/null 2>&1 ; echo $?)"
[ "$EXIT_CODE" = "1" ] || die "trying to create an alias starting with a slash should fail with code 1, got '$EXIT_CODE'"
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias starting with a slash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to create an alias starting with a slash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
EXPECTED_OUTPUT="Aliases in subdirectories are not supported."
[ "$OUTPUT" = "$EXPECTED_OUTPUT" ] || die "trying to remove an alias with a slash should fail with '$EXPECTED_OUTPUT', got '$OUTPUT'"
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to remove an alias with a slash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to remove an alias with a slash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
[ "$EXIT_CODE" = "1" ] || die "trying to remove an alias with a slash should fail with code 1, got '$EXIT_CODE'"
OUTPUT="$(nvm unalias foo/ 2>&1)"
try_err nvm unalias foo/
EXPECTED_OUTPUT="Aliases in subdirectories are not supported."
[ "$OUTPUT" = "$EXPECTED_OUTPUT" ] || die "trying to remove an alias ending with a slash should fail with '$EXPECTED_OUTPUT', got '$OUTPUT'"
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to remove an alias ending with a slash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to remove an alias ending with a slash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
[ "$EXIT_CODE" = "1" ] || die "trying to remove an alias starting with a slash should fail with code 1, got '$EXIT_CODE'"
[ "$CAPTURED_STDERR" = "$EXPECTED_OUTPUT" ] || die "trying to remove an alias starting with a slash should fail with '$EXPECTED_OUTPUT', got '$CAPTURED_STDERR'"
[ "$CAPTURED_EXIT_CODE" = "1" ] || die "trying to remove an alias starting with a slash should fail with code 1, got '$CAPTURED_EXIT_CODE'"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.