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
When `nvm install <target>` found that `<target>` was already installed,
the post-`nvm use` steps
(`--reinstall-packages-from`, default packages, and `--alias`/`--default`)
were gated on `[ $EXIT_CODE -ne 0 ]`.
Since that branch is only entered when `nvm use` succeeded (EXIT_CODE == 0),
those conditions were always false, so the steps were silently skipped.
The fresh-install branch correctly uses `-eq 0`;
mirror that here so `--reinstall-packages-from` actually migrates global packages
(and the alias/default get set) when the target version already exists.
Includes a regression test covering the already-installed path.
Fixes#3858
The standalone `nvm reinstall-packages <version>`
command can migrate global npm packages between already-installed versions,
but it was only mentioned in `nvm --help`, not in the README.
Add a section covering it.
Refs #3858
- Help text for `nvm install`/`use`/`exec`/`run`/`which` now ends with
"Uses .nvmrc if version is omitted; otherwise errors."
so it's clear that omitting the version is not a free fallback.
- Help signatures for `use`/`exec`/`run` now show `[current | <version>]`
to mirror `nvm which` and document that `current` is accepted.
- `nvm current` description now spells out that it resolves via `$PATH`
and is not affected by `.nvmrc`.
- README: add `current` to the list of special aliases, with the same caveat.
The `.nvmrc` section now states that `nvm use`/`install`/`which`
exit with status 127 when neither a version nor an `.nvmrc` resolves,
notes the (current) `exec`/`run` fallback as undefined behavior,
and points readers at `current` for the explicit "active node" use case.
Refs #3755
Previously a number of subcommands dumped the entire `nvm --help`
output (~100 lines) when arguments were missing or invalid,
drowning the real error.
Replace each dump with a short,
command-specific usage block that names the expected syntax and points to `nvm --help` for full help.
The exit code (127) is unchanged.
Affected subcommands:
- `nvm install` (no version + no .nvmrc)
- `nvm use` (version unresolvable)
- `nvm run` (no version + no .nvmrc)
- `nvm which` (no version + no .nvmrc)
- `nvm cache` (unknown subcommand)
- `nvm uninstall` (wrong arg count)
- `nvm unalias` (wrong arg count)
- `nvm install-latest-npm` (wrong arg count)
- `nvm reinstall-packages` / `nvm copy-packages` (wrong arg count)
The catch-all unknown-subcommand handler still dumps full help, since
in that case the user has no narrower context to be reminded about.
Refs #3755
Previously the message read "No .nvmrc file found",
which obscured the fact that the user also did not pass a version.
The new wording names both halves of the actual problem.
Refs #3755
Currently these commands silently fall back to the active node version when neither a version argument nor an `.nvmrc` resolves,
making them invisibly dependent on shell state and impossible to script predictably (see #3755).
Print a stderr deprecation warning in this case (suppressed by `--silent`) and continue with the active node version,
so existing callers keep working.
The follow-up change will turn this into a hard error;
pass `current` explicitly (e.g. `nvm exec current node ...`) to silence the warning and lock in the new behavior now.
Refs #3755
The branch-reset step sent `force` as a string via `gh api -f "force=true"`,
which the Git refs API rejects ("not a boolean", HTTP 422), failing the release run.
Use `-F` so it is sent as a boolean.
Also resolve the version from the latest `vX.Y.Z` tag
(via the tags API) rather than `releases/latest`,
so a manual `workflow_dispatch` with no input works even before the GitHub release object for a freshly pushed tag is published.
Upstream's `.gitmodules` uses a relative submodule url (`../nvmrc.git`),
which resolves against the superproject's origin:
on a fork without its own `nvmrc` fork that is `<owner>/nvmrc`,
which 404s and fails `actions/checkout` with `submodules: true`.
Keep `submodules: true` (so a fork's own `nvmrc` is used when present),
but mark checkout `continue-on-error` and, only when it failed,
re-point the submodule at `nvm-sh/nvmrc` and update.
The mirror-supplied (untrusted) version flows into download URLs,
filesystem paths, and the checksum awk match.
Reject any version outside the node/io.js grammar
(`[0-9A-Za-z._+-]`) before it is used.
A blocklist of metacharacters is used rather than a strict semver allowlist so RCs, nightlies, v8-canary, and io.js versions still install.
Completes the remediation of GHSA-3c52-35h2-gfmm.
The awk program string-interpolated the slug
(which embeds the untrusted, mirror-supplied version)
into its source, so a crafted version such as
`v1"==$2){system("touch${IFS}/tmp/x")}#`
was executed by awk's `system()`.
Pass the value via `-v tarball=...` so awk treats it as data and never as code.
See GHSA-3c52-35h2-gfmm
(a second injection sink fed by the same untrusted version field that `nvm_download`'s eval was; the source-install path reaches this during a normal `nvm install <version>`).
`nvm_download` built a curl/wget command string and ran it with `eval`.
The download URLs embed the version string taken from the mirror's `index.tab`,
which is untrusted.
Wrapping each argument in double quotes inside the `eval` does not prevent command substitution,
so a version field such as `v1$(touch /tmp/proof)` was executed by the shell.
This bypassed the earlier quoting hardening in 0ce8f5a.
Pass every argument as a literal argv element instead of constructing a string for `eval`,
on both the curl and wget paths,
so URL arguments are never re-parsed by the shell.
The wget flag translation is now done per-argument with a POSIX
`set --` loop rather than `sed` over the joined string.
The auth header is sanitized and added once,
before invoking the downloader.
The wget path passed `NVM_AUTH_HEADER` as the raw header line
(e.g. `--header "Bearer secret-token"`),
omitting the `Authorization:` header name that the curl path includes.
Per the documented usage
(`NVM_AUTH_HEADER="Bearer secret-token"`) the value is the credential,
so wget was sending a malformed header.
Prefix it with `Authorization: ` to match the curl path.
The test's `rm -rf "$NVM_DIR"` intermittently failed with
`rm: cannot remove...: Directory not empty`
and aborted under `set -e`.
Cause: after the clone/fetch, git can spawn a detached background gc/maintenance process that keeps writing into the clone dir while `rm -rf` runs (a concurrent writer makes the final rmdir fail).
It is not egress- or version-related
(it reproduces with all endpoints allowed),
and it is environment-timing dependent
(recently became consistent on the GitHub runners).
Disable git's background work for the test (gc.autoDetach / maintenance.auto)
so all git operations finish synchronously, and retry the rm once as a safety net.
`[ "${head_ref}" != "${avoid_ref}"]` is missing the space before the closing bracket,
so the shell prints `[: missing ']'` and the avoid_ref assertion never actually runs
(it is inside an `if` condition, so the error was non-fatal and silently disabled the check)
CodeQL (actions/missing-workflow-permissions)
flagged the matrix, test, and finisher jobs of nvm-install-test.yml for not declaring permissions.
Every other test workflow already sets least-privilege permissions per job; add them here to match:
`contents: read` for the matrix and test jobs, `contents: none` for the no-op finisher.
harden-runner runs with `egress-policy: block`, and the allow-list only included
`production.cloudflare.docker.com`. DockerHub serves image blobs from either its
Cloudflare or its CloudFront CDN; when a pull was routed to CloudFront
(`production.cloudfront.docker.com`) the connection was dropped, causing
`error pulling image configuration: ... connect: connection refused` and exit
125 in the xenial, installation_node, and fast (httpbin) suites. Allow both CDNs.
Container-based suites and the `nvm_download` httpbin check hard-fail whenever DockerHub is briefly unreachable
(observed: `dial tcp ...:443: connect: connection refused` while pulling images),
even though the change under test is fine.
This is unrelated to any test logic.
- tests-xenial / tests-installation-node: retry the `docker pull` up to 5 times before `docker run`, mirroring the existing apt-get retry
- `nvm_download` test: retry the httpbin pull and skip the auth-header checks (rather than fail) when the image cannot be pulled or run, and make cleanup tolerant of a missing container.
GNU Tar has `--preserve-permissions` as a default enabled when executed as the superuser (root).
This will cause the binaries to be installed using the permissions (owner and group) as defined in the tarball.
The argument `--no-same-owner` prevents this and will install the binaries as the effective owner/group just like when nvm is executed as a non superuser.
Updated the install from binary test from the installation_node test
suite because this test is run in a docker container as root. Without
--no-same-owner this test will fail beause the binaries of node v0.10.7
are owned by isaacs/admin in the tarball.
The lowercase check was in the `*` catch-all branch of the `case` statement, rejecting any alias name with uppercase characters.
This prevented creating or reading uppercase aliases like `TESTY`.
The check should only apply to `lts/*` patterns, since LTS codenames are always lowercase.
Fixes#3764.
Bug introduced in https://github.com/nvm-sh/nvm/commit/9fb9dec710e2c8d3aecb24c2a7c9f9fb45b1435b as part of fixing #3417.
- `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)
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 https://github.com/nvm-sh/nvm/commit/7807a9f09e54a14f9b493c6eeda0022489cda496.
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 https://github.com/nvm-sh/nvm/commit/4fdef427e4b1d563570ba5992bdbe7d7e23f025b / #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 https://github.com/nvm-sh/nvm/commit/35212c134652197c779dffd42b9567a270355987.
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.
@@ -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.
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.
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.'
@@ -23,10 +23,10 @@ Explain the problem and include additional details to help maintainers reproduce
* **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).
* **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 much details as possible about your environment, so we can more easily confirm the problem.
* **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.
# 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 -->
@@ -31,6 +31,8 @@
- [Usage](#usage)
- [Long-term Support](#long-term-support)
- [Migrating Global Packages While Installing](#migrating-global-packages-while-installing)
- [Migrating Global Packages Between Installed Versions](#migrating-global-packages-between-installed-versions)
- [Offline Install](#offline-install)
- [Default Global Packages From File While Installing](#default-global-packages-from-file-while-installing)
- [io.js](#iojs)
- [System Version of Node](#system-version-of-node)
@@ -76,25 +78,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>
@@ -104,10 +106,10 @@ 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 (`~/.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.
@@ -134,7 +136,7 @@ Eg: `curl ... | NVM_DIR="path/to/nvm"`. Ensure that the `NVM_DIR` does not conta
- 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'`
- 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.6/install.sh | bash'`
#### Installing in Docker
@@ -145,12 +147,12 @@ When invoking bash as a non-interactive shell, like in a Docker container, none
SHELL["/bin/bash","-o","pipefail","-c"]
# Create a script file sourced by both interactive and non-interactive bash shells
ENV BASH_ENV /home/user/.bash_env
ENV BASH_ENV "${HOME}/.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
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh |PROFILE="${BASH_ENV}" bash
RUNecho node > .nvmrc
RUN nvm install
```
@@ -168,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.4/install.sh | bash
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
# set env
ENVNVM_DIR=/root/.nvm
@@ -194,7 +196,7 @@ After creation of the image you can start container interactively and run comman
@@ -278,7 +280,7 @@ which should output `nvm` if the installation was successful. Please note that `
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 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:
**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:
@@ -319,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.4`
1.`cd ~/.nvm` and check out the latest version with `git checkout v0.40.6`
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:
@@ -428,6 +430,7 @@ In place of a version pointer like "14.7" or "16.3" or "12.22.1", you can use th
-`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).
-`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
@@ -481,6 +484,33 @@ 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.
### Migrating Global Packages Between Installed Versions
`--reinstall-packages-from` is tied to `nvm install`. To migrate global npm packages between versions you _already_ have installed, without (re)installing anything, `nvm use` the destination and run `nvm reinstall-packages` as a standalone command, pointing at the version you want to copy _from_:
```sh
nvm use 22.22.2
nvm reinstall-packages 22.20.0
```
This reinstalls all global packages from `22.20.0` into the currently-active version (`22.22.2`). As with `--reinstall-packages-from`, the npm version itself is not changed.
### 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
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).
Afterwards, `nvm use`, `nvm install`,`nvm exec`, `nvm run`, and `nvm which` will use the version specified in the `.nvmrc` file if no version is supplied on the command line.
Afterwards, `nvm use`, `nvm install`, and `nvm which` will use the version specified in the `.nvmrc` file if no version is supplied on the command line; if no `.nvmrc` is found either, they exit with status `127`. (`nvm exec` and `nvm run` follow the same `.nvmrc` lookup, but currently fall back to the active node if neither resolves — treat that fallback as undefined behavior; pass an explicit version if you need predictable scripting.) If you want the currently active version, pass `current` explicitly (e.g. `nvm which current`) — `current` is not affected by `.nvmrc`.
For example, to make nvm default to the latest 5.9 release, the latest LTS version, or the latest node version for the current directory:
@@ -923,18 +953,18 @@ Alpine Linux, unlike mainstream/traditional Linux distributions, is based on [Bu
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, depending on which version you are using:
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._
@@ -968,13 +998,13 @@ export NVM_DIR="$HOME/.nvm"
## Docker For Development Environment
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
@@ -983,7 +1013,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:
@@ -1097,7 +1124,7 @@ Here's what you will need to do:
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)
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.676)
- Exit back to your native shell.
@@ -1124,7 +1151,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
@@ -1159,7 +1186,7 @@ Currently, the sole maintainer is [@ljharb](https://github.com/ljharb) - more ma
## Project Support
Only the latest version (v0.40.4 at this time) is supported.
Only the latest version (v0.40.6 at this time) is supported.
## Enterprise Support
@@ -1175,3 +1202,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.
EXPECTED_OUTPUT="Aliases with a comment delimiter (#) are not supported."
[ "$OUTPUT" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias with a hash should fail with '$EXPECTED_OUTPUT', got '$OUTPUT'"
[ "$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'"
EXIT_CODE="$(nvm alias foo#bar baz >/dev/null 2>&1 ; echo $?)"
[ "$EXIT_CODE" = "1" ] || die "trying to create an alias with a hash should fail with code 1, got '$EXIT_CODE'"
OUTPUT="$(nvm alias foo# baz 2>&1)"
try_err nvm alias foo# baz
EXPECTED_OUTPUT="Aliases with a comment delimiter (#) are not supported."
[ "$OUTPUT" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias ending with a hash should fail with '$EXPECTED_OUTPUT', got '$OUTPUT'"
[ "$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'"
EXIT_CODE="$(nvm alias foo# baz >/dev/null 2>&1 ; echo $?)"
[ "$EXIT_CODE" = "1" ] || die "trying to create an alias ending with a hash should fail with code 1, got '$EXIT_CODE'"
OUTPUT="$(nvm alias \#bar baz 2>&1)"
try_err nvm alias \#bar baz
EXPECTED_OUTPUT="Aliases with a comment delimiter (#) are not supported."
[ "$OUTPUT" = "$EXPECTED_OUTPUT" ] || die "trying to create an alias starting with a hash 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 hash should fail with code 1, got '$EXIT_CODE'"
[ "$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'"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'PREFIX=bar nvm_die_on_prefix 0 foo' did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_3" ] || die "'PREFIX=bar nvm_die_on_prefix 0 foo' did not exit with 3; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'PREFIX=bar nvm_die_on_prefix 0 foo' did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_3" ] || die "'PREFIX=bar nvm_die_on_prefix 0 foo' did not exit with 3; got '$CAPTURED_EXIT_CODE'"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'NPM_CONFIG_PREFIX=bar nvm_die_on_prefix 0 foo' did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_4" ] || die "'NPM_CONFIG_PREFIX=bar nvm_die_on_prefix 0 foo' did not exit with 4; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'NPM_CONFIG_PREFIX=bar nvm_die_on_prefix 0 foo' did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_4" ] || die "'NPM_CONFIG_PREFIX=bar nvm_die_on_prefix 0 foo' did not exit with 4; got '$CAPTURED_EXIT_CODE'"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'npm_CONFIG_PREFIX=bar nvm_die_on_prefix 0 foo' did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_4" ] || die "'npm_CONFIG_PREFIX=bar nvm_die_on_prefix 0 foo' did not exit with 4; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'npm_CONFIG_PREFIX=bar nvm_die_on_prefix 0 foo' did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_4" ] || die "'npm_CONFIG_PREFIX=bar nvm_die_on_prefix 0 foo' did not exit with 4; got '$CAPTURED_EXIT_CODE'"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with project .npmrc that has prefix did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with project .npmrc that has prefix did not exit with 10; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with project .npmrc that has prefix did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with project .npmrc that has prefix did not exit with 10; got '$CAPTURED_EXIT_CODE'"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with project .npmrc that has globalconfig did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with project .npmrc that has globalconfig did not exit with 10; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with project .npmrc that has globalconfig did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with project .npmrc that has globalconfig did not exit with 10; got '$CAPTURED_EXIT_CODE'"
rm "${TEST_DIR}/.npmrc" || die '.npmrc could not be removed'
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with global npmrc that has prefix did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with global npmrc that has prefix did not exit with 10; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with global npmrc that has prefix did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with global npmrc that has prefix did not exit with 10; got '$CAPTURED_EXIT_CODE'"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with global npmrc that has globalconfig did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with global npmrc that has globalconfig did not exit with 10; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with global npmrc that has globalconfig did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with global npmrc that has globalconfig did not exit with 10; got '$CAPTURED_EXIT_CODE'"
rm "${GLOBAL_NPMRC}" || die "${GLOBAL_NPMRC} could not be removed"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with builtin npmrc that has prefix did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with builtin npmrc that has prefix did not exit with 10; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with builtin npmrc that has prefix did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with builtin npmrc that has prefix did not exit with 10; got '$CAPTURED_EXIT_CODE'"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with builtin npmrc that has globalconfig did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with builtin npmrc that has globalconfig did not exit with 10; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with builtin npmrc that has globalconfig did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with builtin npmrc that has globalconfig did not exit with 10; got '$CAPTURED_EXIT_CODE'"
rm "${BUILTIN_NPMRC}" || die "${BUILTIN_NPMRC} could not be removed"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with user .npmrc that has prefix did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with user .npmrc that has prefix did not exit with 10; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with user .npmrc that has prefix did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with user .npmrc that has prefix did not exit with 10; got '$CAPTURED_EXIT_CODE'"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with user .npmrc that has globalconfig did not error with '$EXPECTED_OUTPUT'; got '$OUTPUT'"
[ "_$EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with user .npmrc that has globalconfig did not exit with 10; got '$EXIT_CODE'"
[ "_$CAPTURED_STDERR" = "_$EXPECTED_OUTPUT" ] || die "'nvm_die_on_prefix 0 foo' with user .npmrc that has globalconfig did not error with '$EXPECTED_OUTPUT'; got '$CAPTURED_STDERR'"
[ "_$CAPTURED_EXIT_CODE" = "_10" ] || die "'nvm_die_on_prefix 0 foo' with user .npmrc that has globalconfig did not exit with 10; got '$CAPTURED_EXIT_CODE'"
# nvm_download should fail to download wrong_install.sh
! nvm_download "https://raw.githubusercontent.com/nvm-sh/nvm/HEAD/wrong_install.sh" >/dev/null || die "nvm_download should fail to download no existing file"
# nvm_download should pass when calling with auth header
[ "_$EXIT_CODE" = "_$EXPECTED_CODE" ] || die "nvm_get_minor_version "$INPUT" did not fail with code "$EXPECTED_CODE"; got $EXIT_CODE"
try nvm_get_minor_version "$INPUT"
[ "_$CAPTURED_EXIT_CODE" = "_$EXPECTED_CODE" ] || die "nvm_get_minor_version "$INPUT" did not fail with code "$EXPECTED_CODE"; got $CAPTURED_EXIT_CODE"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_print_alias_path \"\$NVM_ALIAS_DIR\" foo' should produce no output when nvm_alias does not; got '$OUTPUT'"
[ "$EXIT_CODE" = '0' ] || die "'nvm_print_alias_path \"\$NVM_ALIAS_DIR\" foo' should exit zero when nvm_alias produces no output; got $EXIT_CODE"
[ "$CAPTURED_EXIT_CODE" = '0' ] || die "'nvm_print_alias_path \"\$NVM_ALIAS_DIR\" foo' should exit zero when nvm_alias produces no output; got $CAPTURED_EXIT_CODE"
[ "_$OUTPUT" = "_$EXPECTED_OUTPUT" ] || die "'nvm_print_default_alias foo' should produce no output when nvm_print_implicit_alias does not; got '$OUTPUT'"
[ "$EXIT_CODE" = '0' ] || die "'nvm_print_default_alias foo' should exit zero when nvm_print_implicit_alias produces no output; got $EXIT_CODE"
[ "$CAPTURED_EXIT_CODE" = '0' ] || die "'nvm_print_default_alias foo' should exit zero when nvm_print_implicit_alias produces no output; got $CAPTURED_EXIT_CODE"
[ "_$OUTPUT" = "_v4.9.1" ] || die "nvm_remote_version 4 should return v4.9.1, got $OUTPUT"
[ "_$EXIT_CODE" = "_0" ] || die "nvm_remote_version 4 should exit with code 0, got $EXIT_CODE"
try nvm_remote_version 4
[ "_$CAPTURED_STDOUT" = "_v4.9.1" ] || die "nvm_remote_version 4 should return v4.9.1, got $CAPTURED_STDOUT"
[ "_$CAPTURED_EXIT_CODE" = "_0" ] || die "nvm_remote_version 4 should exit with code 0, got $CAPTURED_EXIT_CODE"
cleanup
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.
Jordan Harband
Jesse ZhuandJordan Harband
Mathew DodgsonandJordan Harband
Jake LodwickandJordan Harband
jinhyuk9714andJordan Harband
Yinan QinandJordan Harband
ryenusandJordan Harband
Rahul BeniwalandJordan Harband
Curt J. SampsonandJordan Harband
Teodoro P.andJordan Harband
Teodoro P.andJordan Harband
Elan RuusamäeandJordan Harband
Dick MarinusandJordan Harband
MoziandJordan Harband
Андрій ШовкошитнийandJordan Harband
Peter Dave HelloandJordan Harband
Salman Muin Kayser ChishtiandJordan Harband
rohan436andJordan Harband
Hemant MannandJordan Harband