`#` is a repetition operator under `extendedglob`,
so `${VAR%%#*}` is an invalid pattern:
zsh aborts the expansion and `nvm_alias` silently prints nothing,
leaving the `default` alias unresolved when nvm.sh is sourced.
The read loop moves into `nvm_print_alias_file` so that `local_options`
scopes the option change to that section alone,
rather than to everything `nvm_alias` does,
and restores whatever the caller had set.
Fixes#3885
Co-authored-by: debaditya <debaditya2005hait@gmail.com>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
`unsetopt local_options nomatch` unsets both named options,
so LOCAL_OPTIONS is off by the time the function returns and the
`nomatch` change escapes into the caller's shell:
one `nvm ls` or `nvm alias` leaves NO_MATCH off for the rest of the session,
after which an unmatched glob is silently passed through as a literal.
`setopt local_options nonomatch`,
already used in `nvm_check_file_permissions`, restores on return.
The `markdirs` line also cancelled the snapshot
taken for `shwordsplit` on the line above it;
that one is latent,
as `nvm_ls` is only ever called inside a command substitution.
Every legend line is built inside a command substitution,
where `nvm_has_colors` can never succeed,
because `[ -t 1 ]` sees the capture pipe rather than the terminal.
The legend has therefore always printed plain,
on every terminal and in every shell.
Resolve color support once and pass it in,
the way `nvm_print_alias_path` already accepts the same flag.
A command-prefix assignment cannot carry it:
POSIX expands a command's arguments before applying its assignments,
so the substitutions would still see it unset,
and in sh and ksh it would outlive the call and override `--no-colors` for everything after.
The test needs no tty,
and fails against an unfixed `nvm.sh` in sh, bash, dash, and zsh.
Fixes#3896
The presence checks were still satisfiable by this test file itself,
which is an executable named `nvm_print_color_legend`.
Filtering `command -v` output on a `/` was not enough:
dash and zsh report a bare name,
not a path,
for a current-directory match reached through an empty `PATH` component,
and that is indistinguishable from a function.
So `nvm unload` looked as though it had left the function behind in exactly the shells CI runs as `sh`, `dash`, and `zsh`,
while bash, which reports `./name`, passed.
Emptying `PATH` for the lookup asks about the function alone,
and is immune to whatever `PATH` happens to hold.
Reproduced first, then fixed:
with `PATH=":${PATH}"` the previous check fails under dash and zsh
and passes under bash, matching CI exactly.
The assertions now hold in sh, bash, dash, and zsh
with the directory absent from `PATH`, present on it, and via an empty entry,
and both dropping `nvm_print_color_legend` from `nvm unload`
and renaming the function out from under the guard
are still caught in all twelve combinations.
`unset -f` was passed a name that has never been a function.
It arrived with `set-colors` in 6848c16d and has never existed.
That matters because shells disagree about what `unset -f` does with a name that is not a function.
bash unsets the rest of the list and carries on;
Linux dash and zsh appear to stop there,
which silently left every one of the ten names after it defined:
`nvm_echo_with_colors`, `nvm_err_with_colors`,
`nvm_get_artifact_compression`, `nvm_install_binary_extract`,
`nvm_extract_tarball`, `nvm_process_nvmrc`,
`nvm_process_nvmrc_content`, `nvm_nvmrc_invalid_msg`,
`nvm_write_nvmrc`, and most recently `nvm_print_color_legend`.
Nothing noticed until `nvm_print_color_legend` gained a test
asserting that `nvm unload` removes it,
because it sorts first among the survivors.
With the dead name gone,
every remaining entry is a real function,
so no shell has an undefined name to disagree about.
The presence checks used `command -v`,
which finds executables as readily as functions,
and this test file is itself an executable named `nvm_print_color_legend`.
Whenever its own directory is on `PATH`, as it is under CI,
`command -v` kept resolving to the file
long after `nvm unload` had removed the function,
so the unload assertion could never pass there
and the "is it defined" guard could never fail.
`command -v` prints a bare name for a function
and a path for an executable,
in sh, bash, dash, zsh, and ksh alike,
so requiring the result to contain no slash
distinguishes the two.
Verified both ways round:
with the test's directory on `PATH`
the suite passes in all four shells,
and removing `nvm_print_color_legend` from `nvm unload`'s list
is still caught in all four.
The `nvm unload` assertion failed every `fast` job on Linux
while passing on macOS,
and its shape made the cause impossible to read off the failure.
`set -e` aborts the command substitution
when `nvm unload` returns non-zero,
which leaves an empty string
that the assertion then reports as
"unload left nvm_print_color_legend defined".
Run the unload with `set +e` inside the subshell
and report its exit status next to the lookup,
so a failing unload can no longer be misread
as a function that survived it.
The accompanying `sed: couldn't flush stdout: Broken pipe`
came from the `grep -q` pipelines:
`grep -q` exits at its first match
and hands SIGPIPE to the `sed` feeding it,
which BSD sed swallows and GNU sed reports.
Match whole lines with `case` against the already-captured string instead,
which needs no pipe at all,
and capture `nvm --help` before stripping it
rather than piping it through two processes into `grep -q`.
Test stderr is now empty in sh, bash, dash, and zsh.
3c480159 correctly made this validator actually enforce,
instead of the no-op `awk '{ $0 ~ "..." }'` it had been,
but its character class had never been audited against real mirror URLs:
it has no `:`,
so enabling enforcement silently rejected every mirror URL bearing a port.
$ NVM_NODEJS_ORG_MIRROR=https://mirror.internal:8443/dist nvm_ls_remote
$NVM_NODEJS_ORG_MIRROR and $NVM_IOJS_ORG_MIRROR may only contain a URL
No request is made at all,
so an internal mirror on a non-default port has been unusable since v0.40.5.
Allow RFC 3986 `unreserved` plus the authority and path punctuation
a mirror URL legitimately needs:
`:` for a port,
`@` for userinfo,
`[`/`]` for an IPv6 literal host,
and `%` for percent-encoding.
`sub-delims` and the query/fragment delimiters stay rejected:
nvm appends a path to this value,
so a query string could never have worked,
and several of those characters are shell metacharacters.
`~` is a member of RFC 7235 §2.1 `token68`,
and thus of RFC 6750 §2.1 `b64token`,
but the allowlist stripped it,
silently corrupting any opaque Bearer credential containing it:
Bearer mF_9.B5f-4.1JqM~+/= -> Bearer mF_9.B5f-4.1JqM+/=
`Basic` credentials were never affected,
since RFC 4648 §4 base64 cannot emit `~`;
`;` stays stripped, as it belongs to no auth-scheme production.
Cover the charset in the unit test,
and assert the credential reaches the downloader intact via the existing fake-`wget` harness,
which needs no container.
In GitHub Actions, `gh` refuses to run without a token,
and `release-notes.sh` fails closed on `gh` errors,
so the `make release` dry run died once the script was checked in.
The workflow already permits `api.github.com` egress and only needs the default read-only token.
The `release` target has invoked `./release-notes.sh` since 0b8ed9fa,
but the script itself was never committed,
so the "Tests: release process" workflow fails on a fresh checkout.
New Stuff
- `nvm install`: serialize concurrent installs of the same version
- `nvm install`: add `NVM_NO_SOURCE_FALLBACK` to disable the source fallback
Robustness
- `nvm install`: reject a structurally broken installed version
- `nvm_install_binary_extract`: replace a broken version dir atomically
- `install.sh`: `nvm_download`: avoid `eval` so arguments aren't re-parsed by the shell
Docs
- [readme] link every referenced person and project to its canonical page
Misc
- [Dev Deps] update `markdown-link-check`
Tests
- install_nvm_from_git: don't fail when master is at the latest release tag
Link the first mention of each named person to their GitHub and each named project, tool, or OS to its official homepage or repo.
Mentions that appear only inside a heading (Ansible),
an HTML comment (doctoc),
or a multi-word code span (grunt) are left unlinked,
since a link there would
break the generated table-of-contents anchors or fail to render.
Two `nvm install <same version>` runs could race on the version directory
- one removing or replacing it while the other reads or writes it.
Take a per-version advisory lock
(an atomically-created directory under $NVM_DIR/.cache locks)
around the binary/source install,
so a second run of the same version waits for the first;
installs of different versions never contend.
NVM_INSTALL_LOCK_TIMEOUT (seconds, default 600) bounds the wait,
after which nvm reports the lock path so a lock left by a killed install can be removed.
NVM_INSTALL_LOCK_STALE (minutes, default 0 / off)
opts into automatically stealing a lock older than that,
for unattended or CI use.
By default a failed binary download falls back to compiling node from source,
which is slow and pointless on platforms that always have prebuilt binaries.
`-b` already disables the fallback per-invocation;
`NVM_NO_SOURCE_FALLBACK=1` makes it the default for every `nvm install`,
so CI images and dev setups need not thread `-b` through every callsite.
It behaves exactly like `-b`
- aborting with a non-zero exit on a failed binary download
- and is mutually exclusive with `-s`, for the same reason `-b` is.
`nvm_is_version_installed` only checks that `bin/node` has the execute bit,
which a zero-byte binary and a dangling `npm` symlink both pass, so a partial
install could be reported as a success — and a broken existing version could
short-circuit `nvm install` as "already installed".
Add `nvm_validate_install`, which requires a non-empty `bin/node` and an `npm`
entry that resolves, and use it in two places: gate the "already installed"
shortcut on it, so a broken version is reinstalled rather than reused, and
re-check it after an install reports success, so a broken result fails loudly
instead of being activated.
It checks layout, not execution: a correctly installed binary can still fail
to run on an incompatible host (e.g. a newer node on an older glibc), which is
not a broken install, and a corrupt download is already rejected by the
checksum check before extraction.
A version directory left without a working `bin/node`
- e.g. a partial or interrupted earlier install
- wedged reinstallation:
`nvm install` saw the version as not installed and re-extracted,
but the per-entry `mv` refused to overwrite the leftover non-empty `bin/`,
`lib/`, … subdirectories and left a half-updated tree behind
(and, without `-b`, fell back to a from-source compile)
Remove any pre-existing version directory and move the freshly extracted tree into place with a single rename,
so a version is either fully installed or not present at all.
The removal is safe: it runs only after the tarball has downloaded and extracted successfully into the cache.
Fall back to the previous per-entry move when a single rename cannot cross filesystems.
`install.sh` has its own `nvm_download`,
which joined `"$@"` into a single string with `nvm_echo` and rewrote the curl-style flags with `sed`,
then ran the result through `eval command wget $ARGS`.
Flattening argv into a string is the root cause: every argument was re-parsed by the shell,
so any shell metacharacter in a legitimate value was interpreted rather than passed through.
An `$NVM_DIR` containing a space silently word-split and wrote to the wrong path,
an apostrophe or parentheses were a syntax error,
a glob character expanded against the cwd,
and an `$NVM_SOURCE` mirror URL with an `&` in its query string backgrounded `wget` and ran the remainder as a bogus command.
The `sed` rewrites were also unanchored substring replacements that would mangle a URL legitimately containing `-o `,
and `ARGS` was an undeclared global that `nvm_reset` never unset.
Translate the flags per-argument with a POSIX `set --` loop and invoke `command wget "$@"` instead,
so each argument stays a literal argv element.
This is the same shape `nvm.sh`'s `nvm_download` has used since 6d870d18,
and it stops the two implementations from diverging.
Unlike `nvm.sh`, no mirror-supplied data reaches this function:
its arguments come only from `$NVM_SOURCE`, `$NVM_INSTALL_GITHUB_REPO`, `$NVM_INSTALL_VERSION`, `$NVM_DIR`, `$XDG_CONFIG_HOME`, and `$HOME`, and `install.sh`'s `nvm_latest_version` is a hardcoded string rather than `nvm.sh`'s `nvm_get_latest`.
This is therefore a robustness fix and not a security one,
since the only party who can influence these arguments is the one already running the installer.
The avoid_ref check read HEAD's tags via `git for-each-ref` with no --git-dir,
so it inspected the caller's checkout instead of the installed clone.
Whether it passed then depended on which ref triggered the workflow
(the same commit passed when built as the v0.40.6 tag but failed when built as master, since only the former had the tag present),
not on the install result.
Query the installed clone and compare commits,
so a HEAD that is legitimately the latest release commit
(eg master right after a release)
is exempted deterministically.
A mirror-supplied LTS codename (field 10 of index.tab) was used verbatim as an alias filename,
so a hostile codename such as `../../../.bashrc` could make nvm_make_alias write outside $NVM_DIR/alias
- with the default layout, into shell startup files.
Constrain remote codenames to safe filename characters at ingestion in nvm_ls_remote_index_tab,
and reject any `..` path component in nvm_make_alias as a backstop for every caller.
Payloads
(binaries, plus source tarballs that nvm compiles and runs at install time) are trusted by construction,
since nvm exists to build and run them;
parsed metadata (index.tab, SHASUMS, LTS codenames) is not,
and must never reach a command evaluator,
an awk/sed program body,
or an unvalidated filesystem path.
This records why the existing version-string and checksum hardening exists,
and scopes a malicious payload from a configured mirror as out of scope:
no privilege boundary is crossed.
The full suite cannot run on Alpine: the install-based suites pin ancient Node (0.10.x, io.js) that has no musl binary and cannot source-compile on musl.
Run the fast unit suite instead (mirroring the ubuntu runner: non-root via su-exec, passwordless sudo, a PTY, no system node), plus a binary-only regression matrix that installs every (Alpine, Node) pair with a real unofficial musl binary via `nvm install -b`: x64 back to node 8.17.0 on old Alpine, arm64 at the v20.20.1/v22.21.1/v24.9.0 floors on modern Alpine.
`nvm_get_arch`: skip the smartos arm64/armv8l cases, which have no uname mock and fall through to the real host (adding a musl suffix on Alpine).
`nvm_get_arch_unofficial`: skip the glibc chroot (fixed /lib64 loader, sudo); the musl mapping is already covered by the `nvm_get_arch alpine` test.
`nvm_install_no_progress_bar`: skip below the musl floor, since v0.12.18 has no musl binary and hardcodes the glibc tarball URL.
Sourcing nvm.sh under `set -u` on a POSIX shell that leaves `$_` unset (e.g. busybox ash or dash on Alpine, where the parent shell does not export it) aborted at `NVM_SCRIPT_SOURCE="$_"`.
Default to empty; the only consumer already falls back to `$0`.
The `/etc/alpine-release` check applied the -musl suffix regardless of the resolved OS.
In practice Alpine is always linux, so this is behavior-neutral, but it also makes the `nvm_get_arch` unit test hermetic: its mocked smartos/osx cases no longer pick up a real host's Alpine marker.
Node.js unofficial-builds publishes linux-arm64-musl binaries since v20.20.1 / v22.21.1 / v24+.
Map NVM_ARCH=arm64 to arm64-musl on Alpine so `nvm install`
resolves to the correct tarball instead of the glibc-linked arm64 build that won't run against musl.
[Tests] `nvm_get_arch`: expect arm64-musl on Alpine
Co-authored-by: Jesse Zhu <jesse@itjesse.com>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
urchin only executes test files that have the executable bit, silently skipping the rest,
and `npm run test:check-exec` would catch non-executable ones, but no workflow ran it -
so several test files have never actually run.
Make all of them executable, and fix the ones that were broken:
- the io.js source-install tests, skipped since 2016: io.js requires python 2 and gcc <= 5,
so they now skip on toolchains that can not compile it,
and a new gcc:4.9-container CI job runs them unmodified -
resolving, downloading, checksumming, and compiling io.js for real.
New `fake source` variants exercise nvm's source pipeline everywhere -
cache lookup, offline resolution, extraction, configure, make, make install, activation -
via a tiny fake source tree seeded into the download cache and installed with `--offline`.
Also strengthen the `nvm run | grep` assertions with `--silent`,
since the version banner used to satisfy the grep even when the built binary could not run,
and give the final assertions the `die` they always meant to call.
- `nvm uninstall ... incorrect file permissions fails nicely`, parked in 2025 as failing:
`sudo npm` resets PATH, so node 5's npm crashed under the system node.
The permissions check only trips on files that are neither writable nor self-owned,
and that precondition only needs `sudo touch` - not npm, jspm, or the network -
so use that, against a fake installed version,
and skip only where passwordless sudo does not exist.
- `nvm install --offline`: `nvm ls | tail -1` always grabbed an alias line, never a version;
use `nvm_ls` and skip its trailing `system <version>` line.
- `nvm exec ... help should not parse`: in a BRE, `[options]` is a bracket expression,
so the grep could never match node's literal `Usage: node [options]` output.
- `nvm use ... nvmrc containing not installed version`: current output once again matches its expectations verbatim; no changes needed.
Rewrite `test:check-exec` in POSIX sh - npm runs scripts with /bin/sh, which is dash on Ubuntu,
where the previous `[[`/`$'\n'` bashisms would break;
match by extension, so that filenames containing dots can not dodge the check;
and disable git's `core.quotePath` mangling of the non-ASCII test filenames.
Then wire it into the lint workflow.
`--offline` version resolution could only see cached node binaries:
`nvm_ls_cached` listed `.cache/bin` with a `node-` prefix filter,
so cached source tarballs, and everything io.js, could never resolve offline.
List both cache kinds, for both flavors,
and update the pinned test expectations to match.
The test was born without its executable bit,
and urchin silently skips non-executable files, so it has never run.
Also pin what `nvm_ls_cached` can currently see:
only bin-cached node artifacts - bin-cached io.js, and src-cached anything,
are invisible to it, and thus to `--offline` version resolution.
The cycle scenarios all pass with the old grep-based detection too;
the bug the `case`-based detection actually fixes is resolved names interpolated into the grep pattern as regexes,
where resolving axb -> a.b falsely reported ∞ because the pattern `a.b` matches the seen name `axb`.
Pin both directions: the fixed false positive, and a genuine cycle through a metachar name.
Also correct the space-name scenario comment
(the old anchored grep passed that scenario; only token-delimited seen-storage would not),
and register every new fixture name in the suite teardown,
so a mid-test failure can not leak aliases into later tests.
[Tests] `nvm_alias`, `nvm_resolve_alias`: add edge-case tests
nvm_alias() used a sed/awk pipeline to strip comments and blank lines from alias files that almost always contain a single word.
A while-read loop with parameter expansion does the same filtering more directly.
nvm_resolve_alias() piped nvm_alias through head and tail to extract one line, and used printf/grep for cycle detection.
Parameter expansion and a case statement replace both without the extra plumbing.
All replacements are POSIX (read -r, case, IFS=, parameter expansion).
As a side effect, this also removes 4 external process invocations during shell init.
[Fix] `nvm_resolve_alias`: detect cycles via newline-anchored `case`
The original commit referenced above changed SEEN_ALIASES from `\n`-delimited
storage (interpreted by `printf '%b' | nvm_grep -e "^${name}$"`) to space-
delimited but left the line-anchored grep in place — without newlines in
the haystack the anchored pattern can never match, so cycles never break.
Switch to literal-newline storage and a `case` pattern anchored on those
newlines. Newline anchoring also handles alias names containing spaces,
which token-based patterns false-positive on (e.g. lookup of `bar` matches
substring " bar " inside " foo bar midway " when the chain visits the
multi-token alias `foo bar`).
New test file covers self-loop, multi-hop loop, cycle through a
space-bearing alias name, and a non-cycle through a space-bearing
alias name. Existing `test/fast/Aliases/circular/` fixtures continue
to pass.
The sed/awk pipeline exits with awk's status,
so an existing-but-unreadable alias file produces empty output with status 0 - but only by accident,
alongside sed's read error on stderr.
Make that contract explicit:
a nonzero status here would flip `nvm_ensure_default_set` from "default is already set" to recreating it,
silently overwriting a write-only default alias.
The two `v0.40.0` + `nvmrc` jobs fail by design (https://github.com/nvm-sh/nvm/issues/3405),
but job-level `continue-on-error` still displays them as failures on every run,
which reads like the contributor broke something.
Tolerate failure only in the steps that exercise the bug, scoped to that matrix combination,
and add a final step that fails the job when the expected failure did not happen -
so those jobs are green exactly when v0.40.0 misbehaves as documented,
and turn red as a signal to remove this handling if v0.40.0 ever starts passing.
This also restores strict failure semantics to the passing `v0.40.0` + `no nvmrc` jobs,
which the job-level `continue-on-error` was needlessly masking.
- `cleanup` unset TEST_DIR before `rm -rf "${TEST_DIR-}"`, so the temp dir (with an executable fake `node`) was never removed,
and urchin executes any executable file it finds under the test dir on the next local run.
- the preexisting `foo#bar` assertions ran against the ambient NVM_DIR;
now that `#` patterns comment-strip to `foo`, a real local alias named `foo` would resolve and break them,
so all assertions now run against an isolated NVM_DIR.
- the multiline content used a full x.y.z version, which takes nvm_ls's explicit-version fast path and never reaches the find/sed pipeline where the newline actually broke sed;
a partial version exercises that path, and matching on "unterminated" covers both the BSD and GNU sed error wordings.
`nvm_has` matches shell functions and aliases,
but downloads now run via `command`, which skips them
- a `curl` shell function with no curl binary on the PATH would select the curl path and fail with exit 127,
instead of falling back to an available wget executable.
The new `nvm_has_executable` helper resolves names the same way `command` does, so downloader selection and execution agree.
zsh (and interactive bash with `expand_aliases`) bakes a preexisting `curl` alias into nvm's function bodies at source time,
and shell functions named `curl`/`wget` shadow the binaries at call time - either one breaks downloads.
Prefixing invocations with `command` bypasses both: here, `nvm_download`'s dispatch, `nvm_curl_version`, `nvm_curl_libz_support`, and the wget branch of `nvm_get_latest`;
the remaining bare `curl` invocations in `nvm_get_latest` and the install script are prefixed in a followup commit.
The tests that previously mocked curl/wget as shell functions now install fake executables on PATH instead,
via a shared `make_fake_curl` helper in `test/common.sh`,
and a new test asserts the bypass.
Refs #2923
On my system, even without using local mirrors, the build is only two
minutes, even though I have only a 1 Gbps Internet connection and I'm
half-way across the world in Tokyo.
There probably are still users with much slower Internet connections
where the build could take eight minutes or more, but "several" still
covers that.
The base image is updated regularly (it's currently 22.04), and it's
easy to forget to update this readme, so best we simply not repeat
ourselves and instead let people look at `Dockerfile` to see exactly
which version of Ubuntu it's using.
`is-nan@1.0.0` was published on 2014-07-05 and unpublished minutes later
(the registry's `time` map still lists it, but `versions` jumps from `0.0.0` to `1.0.1`),
so `npm install -g is-nan@1.0.0` fails with `ETARGET`,
and the regression test added in ce157343 fails deterministically in every shell.
See https://github.com/nvm-sh/nvm/actions/runs/28407118533
2026-07-02 14:35:57 -05:00
73 changed files with 2767 additions and 276 deletions
@@ -107,3 +107,35 @@ Additionally, the maintainer of a third-party dependency might introduce a vulne
**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.
## Trust boundary: mirror payloads vs. mirror metadata
`nvm` fetches two very different kinds of data from a Node.js/io.js mirror (`nodejs.org`/`iojs.org` by default, or whatever `$NVM_NODEJS_ORG_MIRROR` and `$NVM_IOJS_ORG_MIRROR` point at), and they sit on opposite sides of a trust boundary:
- **Payloads** — the Node.js/io.js binaries and source tarballs that `nvm install` downloads, unpacks, compiles (for source installs), and runs.
- **Metadata** — everything `nvm` parses *about* those payloads rather than executing: the `index.tab` version list (including each release's LTS codename), and the `SHASUMS`/`SHASUMS256` checksum files.
Conflating the two leads to mis-scoped reports, so the project draws the line explicitly.
### Payloads are trusted, by construction
The entire purpose of `nvm` is to download a mirror's build of Node.js and run it.
A mirror that serves a backdoored binary has arbitrary code execution the moment you `nvm install` and invoke `node`, and no validation inside `nvm` can prevent that - you have chosen to execute that code.
Installing from source (`nvm install -s`) is if anything more direct: the mirror-supplied source tarball is unpacked and its `configure`/`make` build runs arbitrary code on your machine *at install time*, before `node` is ever invoked.
Checksum verification protects **integrity** (a corrupted or truncated download, or a network intermediary that cannot also forge the same-origin `SHASUMS`), not **authenticity** against the mirror itself, since the checksums come from the same origin as the payload.
Selecting a mirror is therefore equivalent to selecting whom you trust for arbitrary code execution in your account.
A malicious payload from the configured mirror is consequently **out of scope**: no privilege boundary is crossed, so there is no privilege to escalate.
### Metadata is not trusted
Parsing a version list is a pure data operation.
A user who runs `nvm ls-remote` to browse available versions - and installs nothing - has not opted into running any code from the mirror.
Metadata can also be attacker-controlled with no mirror misconfiguration at all, via a compromised mirror/CDN or a man-in-the-middle of the channel (see *Threat ID 3*), so it is treated as hostile input.
The invariant `nvm` maintains is:
> Mirror-supplied metadata must never reach a shell/command evaluator, an `awk`/`sed` program body, or an unvalidated filesystem path (see *Threat ID 2*).
This is why version strings from `index.tab` are passed to the downloader as literal `argv` elements rather than re-parsed by the shell ([CVE-2026-10796](https://github.com/advisories/GHSA-3c52-35h2-gfmm), [CVE-2026-1665](https://github.com/advisories/GHSA-4fc5-r4vr-8rp7)); why checksum comparisons pass the mirror's values as `awk -v`**data** and never as program text; and why LTS codenames are constrained to safe alias filenames before naming a file under `$NVM_DIR/alias/lts`, so a hostile codename such as `../../../.bashrc` cannot traverse out of the alias directory.
The point is not that metadata is "more dangerous" than a payload — a trusted payload can obviously do anything.
It is that metadata carries **no** implied grant of code execution, so any code-execution or arbitrary-write primitive reachable purely by parsing it is a defect worth removing on its own merits, independent of how much the payload channel is trusted.
if [ "${SOURCE_OUTCOME}" = 'failure' ] || [ "${INSTALL_1_OUTCOME}" = 'failure' ] || [ "${INSTALL_2_OUTCOME}" = 'failure' ]; then
echo 'v0.40.0 failed as expected: https://github.com/nvm-sh/nvm/issues/3405'
else
echo '::error::v0.40.0 with an .nvmrc was expected to fail (https://github.com/nvm-sh/nvm/issues/3405), but every step succeeded. If v0.40.0 somehow works now, remove the expected-failure handling from this workflow.'
printf"=== Bumping version **$$old_ver** to **$$new_ver** before committing and tagging:\n=== TYPE 'proceed' TO PROCEED, anything else to abort: "&&read response &&["$$response"='proceed']||{echo'Aborted.' >&2;exit 2;};\
notes_file=`mktemp`||{echo'Failed to create a temp file for the release notes.' >&2;exit 1;};\
trap'rm -f "$$notes_file"' EXIT;\
./release-notes.sh"v$$new_ver" >"$$notes_file"||{echo'Failed to generate release notes.' >&2;exit1;};\
echo'=== Release notes: ===';\
cat "$$notes_file";\
printf"\n=== Bumping version **$$old_ver** to **$$new_ver** before committing and tagging with the above notes:\n=== TYPE 'proceed' TO PROCEED, anything else to abort: "&&read response &&["$$response"='proceed']||{echo'Aborted.' >&2;exit 2;};\
old_ver_re=`printf'%s'"$$old_ver"| sed 's/[.]/\\\\./g'`&&\
# Node Version Manager [][3] [][4] [](https://bestpractices.dev/projects/684)
# 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 -->
@@ -74,7 +74,7 @@
## Intro
`nvm` allows you to quickly install and use different versions of node via the command line.
`nvm` allows you to quickly install and use different versions of [node](https://nodejs.org) via the command line.
**Example:**
```sh
@@ -96,7 +96,7 @@ 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](https://git.kernel.org/pub/scm/utils/dash/dash.git), [ksh](https://github.com/ksh93/ksh), [zsh](https://www.zsh.org), [bash](https://www.gnu.org/software/bash/)), in particular on these platforms: unix, [macOS](https://www.apple.com/macos/), and [Windows WSL](https://github.com/nvm-sh/nvm#important-notes).
<a id="installation-and-update"></a>
<a id="install-script"></a>
@@ -104,12 +104,12 @@ nvm is a version manager for [node.js](https://nodejs.org/en/), designed to be i
### Install & Update Script
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:
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](https://curl.se) or [Wget](https://www.gnu.org/software/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 (`~/.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.
- 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.
- The installer can use [`git`](https://git-scm.com/), `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.5/install.sh | bash'`
- 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.7/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.
When invoking bash as a non-interactive shell, like in a [Docker](https://www.docker.com) container, none of the regular profile files are sourced. In order to use `nvm`, `node`, and [`npm`](https://www.npmjs.com) like normal, you can instead specify the special `BASH_ENV` variable, which bash sources when invoked non-interactively.
```Dockerfile
# Use bash for the shell
@@ -152,7 +152,7 @@ RUN touch "${BASH_ENV}"
RUNecho'. "${BASH_ENV}"' >> ~/.bashrc
# Download and install nvm
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh |PROFILE="${BASH_ENV}" bash
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.7/install.sh |PROFILE="${BASH_ENV}" bash
RUNecho node > .nvmrc
RUN nvm install
```
@@ -170,7 +170,7 @@ ARG NODE_VERSION=20
RUN apt update && apt install curl -y
# install nvm
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.7/install.sh | bash
# set env
ENVNVM_DIR=/root/.nvm
@@ -196,7 +196,7 @@ After creation of the image you can start container interactively and run comman
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.
On [Linux](https://www.kernel.org/), 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.
Alternatively, you can run the following commands for the different shells on the command line:
*bash*: `source ~/.bashrc`
@@ -228,7 +228,7 @@ These should pick up the `nvm` command.
#### Troubleshooting on macOS
Since OS X 10.9, `/usr/bin/git` has been preset by Xcode command line tools, which means we can't properly detect if Git is installed or not. You need to manually install the Xcode command line tools before running the install script, otherwise, it'll fail. (see [#1782](https://github.com/nvm-sh/nvm/issues/1782))
Since OS X 10.9, `/usr/bin/git` has been preset by [Xcode](https://developer.apple.com/xcode/) command line tools, which means we can't properly detect if Git is installed or not. You need to manually install the Xcode command line tools before running the install script, otherwise, it'll fail. (see [#1782](https://github.com/nvm-sh/nvm/issues/1782))
If you get `nvm: command not found` after running the install script, one of the following might be the reason:
@@ -278,9 +278,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 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.
If you're running a system without prepackaged binary available, which means you're going to install node or [io.js](https://iojs.org) from its source code, you need to make sure your system has a C++ compiler. For OS X, Xcode will work, for [Debian](https://www.debian.org)/[Ubuntu](https://ubuntu.com) based GNU/Linux, the `build-essential` and `libssl-dev` packages work.
**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 [Git Bash](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 [Git Bash](https://gitforwindows.org/) ([MSYS](https://www.msys2.org/)) or [Cygwin](https://cygwin.com). Otherwise, for Windows, a few alternatives exist, which are neither supported nor developed by us:
@@ -294,7 +294,7 @@ If you're running a system without prepackaged binary available, which means you
- [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:
**Note:** We still have some problems with [FreeBSD](https://www.freebsd.org), 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] node on FreeBSD may need to be patched](https://github.com/nvm-sh/nvm/issues/900)
@@ -309,11 +309,11 @@ If you're running a system without prepackaged binary available, which means you
- If you have an `~/.npmrc` file, make sure it does not contain any `prefix` settings (which is not compatible with `nvm`)
- You can (but should not?) keep your previous "system" node install, but `nvm` will only be available to your user account (the one used to install nvm). This might cause version mismatches, as other users will be using `/usr/local/lib/node_modules/*` VS your user account using `~/.nvm/versions/node/vX.X.X/lib/node_modules/*`
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.
[Homebrew](https://brew.sh) 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 ([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.
**Note:** Git versions before v1.7 may face a problem of cloning `nvm` source from [GitHub](https://github.com) 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.
### Git Install
@@ -321,7 +321,7 @@ 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.40.5`
1.`cd ~/.nvm` and check out the latest version with `git checkout v0.40.7`
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:
@@ -429,7 +429,7 @@ In place of a version pointer like "14.7" or "16.3" or "12.22.1", you can use th
-`node`: this installs the latest version of [`node`](https://nodejs.org/en/)
-`iojs`: this installs the latest version of [`io.js`](https://iojs.org/en/)
-`stable`: this alias is deprecated, and only truly applies to `node``v0.12` and earlier. Currently, this is an alias for `node`.
-`unstable`: this alias points to `node``v0.11` - the last "unstable" node release, since post-1.0, all node versions are stable. (in SemVer, versions communicate breakage, not stability).
-`unstable`: this alias points to `node``v0.11` - the last "unstable" node release, since post-1.0, all node versions are stable. (in [SemVer](https://semver.org), versions communicate breakage, not stability).
-`current`: the version currently active in this shell (i.e. what `node` resolves to via `$PATH`). It is **not** affected by `.nvmrc`. Useful when you want to refer to the active version explicitly — e.g. `nvm which current` always prints the path to the active `node`, regardless of whether an `.nvmrc` file is present.
### Long-term Support
@@ -872,6 +872,14 @@ nvm exposes the following environment variables:
Additionally, nvm modifies `PATH`, and, if present, `MANPATH` and `NODE_PATH` when changing versions.
The following environment variables can be set to configure `nvm install`:
-`NVM_NO_SOURCE_FALLBACK` - when `1`, a failed binary download aborts instead of silently falling back to a (much slower) from-source compile; the persistent equivalent of the `-b` flag, and mutually exclusive with `-s`.
-`NVM_INSTALL_LOCK_TIMEOUT` - seconds to wait for a concurrent install of the same version to finish before giving up (default `600`). On timeout, nvm prints the lock path so a lock left behind by a killed install can be removed.
-`NVM_INSTALL_LOCK_STALE` - minutes after which an install lock is assumed abandoned and stolen automatically; `0` (the default) never steals.
`nvm install <version>` takes a per-version advisory lock (a directory under `$NVM_DIR/.cache/locks`), so two shells installing the same version at once cannot corrupt its version directory; installs of *different* versions never block each other.
## Bash Completion
@@ -947,9 +955,9 @@ set -e
## Installing nvm on Alpine Linux
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).
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](https://www.centos.org), [RedHat](https://www.redhat.com) 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.
[Alpine Linux](https://www.alpinelinux.org), 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.
@@ -958,20 +966,20 @@ If installing nvm on Alpine Linux *is* still what you want or need to do, you sh
_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._
_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`](https://www.python.org/) 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).
As a potential alternative, [@mhart](https://github.com/mhart) (a Node contributor) has some [Docker images for Alpine Linux with Node and optionally, npm, pre-installed](https://github.com/mhart/alpine-node).
To make the development and testing work easier, we have a Dockerfile for development usage, which is based on Ubuntu 18.04 base image, prepared with essential and useful tools for `nvm` development, to build the docker image of the environment, run the docker command at the root of `nvm` repository:
To make development and testing work easier we supply a Dockerfile for development usage. It's based on an Ubuntu base image prepared with essential and useful tools for `nvm` development. To build the docker image of the environment, do a Docker build at the root of `nvm` repository:
```sh
$ docker build -t nvm-dev .
```
This will package your current nvm repository with our pre-defined development environment into a docker image named `nvm-dev`, once it's built with success, validate your image via `docker images`:
This will package your current nvm working copy with our pre-defined development environment into a Docker image named `nvm-dev`. After the build you should see it appear in the list of images:
```sh
$ docker images
@@ -1013,7 +1021,7 @@ REPOSITORY TAG IMAGE ID CREATED S
nvm-dev latest 9ca4c57a97d8 7 days ago 650 MB
```
If you got no error message, now you can easily involve in:
To start and enter a container based on this image:
Please note that it'll take about 8 minutes to build the image and the image size would be about 650MB, so it's not suitable for production usage.
It takes several minutes to build the image and the image size is about 650MB, so it's not suitable for production usage.
For more information and documentation about docker, please refer to its official website:
- https://www.docker.com/
- https://docs.docker.com/
For more information and documentation about Docker, please refer to its [official website][docker-www] and [documentation][docker-docs]:
## Problems
@@ -1046,7 +1051,7 @@ nvm install -s 0.8.6
## macOS Troubleshooting
**nvm node version not found in vim shell**
**nvm node version not found in [vim](https://www.vim.org) shell**
If you set node version to a version other than your system node version `nvm use 6.2.1` and open vim and run `:!node -v` you should see `v6.2.1` if you see your system version `v0.12.7`. You need to run:
@@ -1067,9 +1072,9 @@ 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)
@@ -1087,7 +1092,7 @@ Homebrew causes insecure directories like `/usr/local/share/zsh/site-functions`
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.
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.
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](https://support.apple.com/en-us/HT211861) can translate the `x86_64` processor instructions to ARM-based Apple Silicon instructions.
Here's what you will need to do:
- Install Rosetta, if you haven't already done so
@@ -1105,7 +1110,7 @@ Here's what you will need to do:
$ 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 same thing can also be accomplished by finding the Terminal or [iTerm](https://iterm2.com) 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.
@@ -1123,11 +1128,11 @@ Here's what you will need to do:
```
Note: You're probably curious why `--shared-zlib` is included.
There's a bug in recent versions of Apple's system `clang` compiler.
There's a bug in recent versions of Apple's system [`clang`](https://clang.llvm.org/) 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.576)
For more details, see [this issue](https://github.com/nodejs/node/issues/39313) and [this comment](https://github.com/nodejs/node/issues/39313#issuecomment-902395576)
- Exit back to your native shell.
@@ -1154,7 +1159,7 @@ Now you should be able to use node as usual.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:09 --:--:-- 0curl: (6) Could not resolve host: raw.githubusercontent.com
@@ -1189,7 +1194,7 @@ Currently, the sole maintainer is [@ljharb](https://github.com/ljharb) - more ma
## Project Support
Only the latest version (v0.40.5 at this time) is supported.
Only the latest version (v0.40.7 at this time) is supported.
## Enterprise Support
@@ -1205,3 +1210,7 @@ See [LICENSE.md](./LICENSE.md).
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.
[ "${EXIT_CODE}" != "0" ] || die 'acquire should fail when the lock is held and the timeout is 0'
case "${OUTPUT}" in
*"${lock}"*) ;;
*) die "the timeout message should name the lock path; got >${OUTPUT}<" ;;
esac
[ -d "${lock}" ] || die 'a failed acquire must not remove the held lock'
# By default, a held lock is never stolen no matter how old it is.
touch -t 202001010000 "${lock}" 2>/dev/null || die 'unable to age the lock dir'
NVM_INSTALL_LOCK_TIMEOUT=0 nvm_acquire_install_lock "${version}" 2>/dev/null && die 'an old lock must not be stolen unless NVM_INSTALL_LOCK_STALE is set'
[ -d "${lock}" ] || die 'the old lock should still be held'
# With NVM_INSTALL_LOCK_STALE set, a sufficiently old lock is stolen and re-acquired.
unset NVM_INSTALL_LOCK
NVM_INSTALL_LOCK_STALE=1 NVM_INSTALL_LOCK_TIMEOUT=0 nvm_acquire_install_lock "${version}" || die 'a stale lock should be stolen when NVM_INSTALL_LOCK_STALE is set'
[ "${NVM_INSTALL_LOCK}" = "${lock}" ] || die 'stealing a stale lock should acquire it'
grep -Fxqe '--header' "$ARGV_LOG" || die "wget did not receive --header; got: $(cat "$ARGV_LOG")"
grep -Fxq 'Authorization: Bearer test-token' "$ARGV_LOG" || die "wget did not receive a well-formed Authorization header; got: $(cat "$ARGV_LOG")"
# given a credential using every character RFC 7235 token68 permits, including '~'
# when nvm_download uses the wget path
NVM_AUTH_HEADER='Bearer mF_9.B5f-4.1JqM~+/=' nvm_download "https://nodejs.org/dist/x" -o - || die 'nvm_download (wget) returned nonzero for a token68 credential'
# then it reaches wget byte-for-byte, with no character silently dropped
grep -Fxq 'Authorization: Bearer mF_9.B5f-4.1JqM~+/=' "$ARGV_LOG" || die "wget did not receive the token68 credential intact; got: $(cat "$ARGV_LOG")"
mkdir -p "${version_path}/bin" "${version_path}/lib" || die 'unable to stage broken dir'
echo 'stale-npm' > "${version_path}/bin/npm"
echo 'stale' > "${version_path}/lib/STALEFILE"
[ -e "${version_path}/bin/node" ] && die 'precondition: broken dir should have no bin/node'
# Extract over the broken directory.
nvm_install_binary_extract 'linux' "${version}" "$(expr "${version}" : '.\(.*\)')" "${node_dir}.tar.gz" "${tmp_dir}/files" || die 'nvm_install_binary_extract failed over a broken version dir'
# bin/node is restored and runnable.
[ -x "${version_path}/bin/node" ] || die 'bin/node was not restored'
[ "$("${version_path}/bin/node")" = "${version}" ] || die 'restored bin/node has wrong contents'
# The stale file is gone: the whole directory was replaced, not merged into.
[ ! -e "${version_path}/lib/STALEFILE" ] || die 'stale lib file survived: install was not atomic'
[ -e "${version_path}/lib/FRESHFILE" ] || die 'fresh lib content missing after install'
# npm resolves to the freshly installed target.
[ -e "${version_path}/bin/npm" ] || die 'npm missing after install'
|| die "'nvm alias default' did not return 'default -> 0.10.1 (-> v0.10.1 *)', got '${NVM_ALIAS_DEFAULT}'"
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.
debadityaandJordan Harband
CJstate
Andres Mejia Sanchez
Jesse ZhuandJordan Harband
Mathew Dodgson
Jake Lodwick
jinhyuk9714
Yinan Qin
ryenus
Rahul Beniwal
Curt J. Sampson