Since markdown-link-check hasn't support relative links, to make the
test passed, move this link to use absolute URL so that we can introduce
the new test. cc tcort/markdown-link-check#10
The instructions seemed to encourage the misconception that `arch -x86_64 zsh` somehow modifies the default architecture for `zsh`, an operation which would need to be "reverted".
In fact, `arch -x86_64 …` merely spawns a new process under the selected architecture.
Fixes#2420. When using `nvm install` with an already installed
version, Bash (and potentially other shells) may emit an unbound
variable error when `set -u` is set. The presence of the error depends
on specific shell versions, but appears to happen in MacOS 11.1 (Big
Sur) using a recent Bash version installed via Homebrew (as of this
writing).
The fix accesses `ALIAS` correctly for the case where it is not set by
an `alias` option to `nvm install`.
When the `nvm` function is called by a script which itself uses a variable
named `i`, `nvm` clobbers the caller's variable. This happens even if the
caller has declared its variable as local.
See note 1 on https://tldp.org/LDP/abs/html/localvar.html#FTN.AEN18568
This command allows users to replace default colors with their own custom colors.
- top-level commands modified: alias, ls, ls-remote
- helper functions added: nvm_echo_with_colors, nvm_err_with_colors,
nvm_set_colors, nvm_get_colors, nvm_print_color_code
- functions modified: nvm_print_formatted_alias, nvm_print_versions, nvm_print_alias_path (implicitly), nvm_print_default_alias (implicitly), nvm_list_aliases (implicitly)
We added tests and info on using this command to the README!
Co-authored-by: Dena Burd <29719099+gitburd@users.noreply.github.com>
Co-authored-by: Naomi Quinones <52065567+naomiquinones@users.noreply.github.com>
locale-gen command seems missing since uncertain point for a while:
```
Step 15/33 : RUN locale-gen en_US.UTF-8
---> Running in fae073c89c01
/bin/bash: locale-gen: command not found
The command '/bin/bash -o pipefail -c locale-gen en_US.UTF-8' returned
a non-zero code: 127
```
This patch should fix the Docker image build
The workaround came from this GitHub issue comment:
https://github.com/koalaman/shellcheck/issues/1053#issuecomment-357816927
Looks like the problem doesn't exist any more:
```
.
.
.
Step 14/33 : RUN shellcheck -V
---> Running in 4b7a718c1cbf
ShellCheck - shell script analysis tool
version: 0.7.0
license: GNU General Public License, version 3
website: https://www.shellcheck.net
.
.
.
```
The workaround should be removed so that the Dockerfile will be easier
to be understand and read.
Fixed a bug where --silent mode was failing for nvm use I ran a test
that just ran ```nvm use node --silent``` that I wrote by myself.
Unfortunately I noticed a bug where it still prints out some messages in
different cases. This pull request is to fix that bug. * Added in an argument
called ***quiet*** to the nvm_rc_version() function at *line 339* * Printed
anything inside the nvm_rc_version() only in the scenario where quiet mode is
off * Ran the nvm_rc_version() function in quiet mode only if silent mode is
on in the "use" command of nvm at *line 2990* * Ran *nvm_echo* and *nvm_err*
inside the "use" command of nvm only in the scenario where silent mode is off
(There were 4 scenarios where this was forgotten) * Edited the ```nvm
deactivate``` command to include a silent mode * Changed the help page to
include the --silent option for ```nvm deactivate``` * Added in aliases for
the --silent flag in ```nvm deactivate``` and ```nvm use``` * Used silent
mode inside the ```nvm use``` when running ```nvm deactivate``` inside it and
silent mode is on A test was attached in the 'test/slow/nvm use' directory.
It is named *Running "nvm use node --silent" doesn't print anything*. It runs
```nvm use node --silent and checks``` and succeeds if the OUTPUT matches the
EXPECTED_OUTPUT which is *null* or *''*. When the test was run locally, it
still ouputed results if someone deleted some contents of the *.nvm/* folder.
This output was given from the ```nvm deactivate command```. This was the
reason that the ```nvm deactivate``` was edited to include silent mode.
For: `nvm install 8.12.0` after install:
--alias=8 is equivalent to `nvm alias 8 8.12.0`
--default is equivalent to `nvm alias default 8.12.0`
Co-authored-by: Kayla Altepeter <kayla@kaylaaltepeter.com>
Co-authored-by: Dena Burd <me@Denas-MacBook-Air.local>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
Added an example for LTS updates that also reinstall the existing packages.
This is useful for individuals who run the latest LTS version along with global packages and need to update when the LTS version gets bumped
macOS only supports extracting xz tarballs with `tar` in 10.9 and up.
GNU tar needs an `xz` executable on the `PATH` to extract xz tarballs.
(These are the most common variants of tar, so until further testing
is done, conservatively assume all variants of tar (other than the one
shipped with macOS) need an xz executable on the PATH in order to
decompress xz tarballs.)
Fixes#2155.
Renames node_version_has_solaris_binary and nvm_iojs_version_has_solaris_binary
to be prefixed with nvm_ so they do not show up in tab completion following the
word "node".
Clean up readme structure a bit to help with readability. fix
instructions which could lead to a sourcing loop if misinterpreted.
guidance should direct macos users to simply copy the source snippet
manually into their desired profile file.
Resolve#2123
Adds the following information to the "Migrating global packages while installing" section:
- notification that the npm package is explicitly not updated when using the --reinstall-packages-from flag
- information about the --latest-npm flag
- recovery instructions if a user has already updated node with an incompatible npm version
- Operating system and version: Mac OS X Mojave
- What happened? $NVM_DIR was set to nvm
- What did you expect to happen? $NVM_DIR should be set to .nvm
I added the following line from the README to my .zshrc:
```
export NVM_DIR="${XDG_CONFIG_HOME/:-$HOME/.}nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
```
I couldn't figure out why nvm wasn't loading, until I realized that
`echo NVM_DIR="${XDG_CONFIG_HOME/:-$HOME/.}nvm"` outputs `NVM_DIR=nvm`.
Changing the line to `export NVM_DIR="${XDG_CONFIG_HOME/:-$HOME/}.nvm"` fixed the problem. This outputs `NVM_DIR=.nvm` as expected. I tested this and the same behavior holds true in Bash as well.
It was trying to read ./.nvmrc if you cd'ed into a subdirectory of the directory that has .nvmrc, which would give print `-bash: ./.nvmrc: No such file or directory` to stderr and potentially not doing the `nvm install`.
With the environment variable XDG_CONFIG_HOME set, the installation
script uses the directory $XDG_CONFIG_HOME/nvm now. Before the change
the variable's value with "/nvm" cut off was used, which usually results
in an installation without any subdirectory.
- fix test 'Running "nvm ls" should display all installed versions.': only expect versions created by this test, but no versions created by other tests
Add Ansible task example to show how to install nvm and update it.
Ansible is a systems administration tool.
See https://github.com/ansible/ansible
My personal experience of `nvm` is that installing via Ansible is good, and that a good example can help. This example took me about an hour to learn, so I'm hoping to save other people some time. This example is somewhat different than any others that I found on the web. There may be a better way to write it, and if so, please improve it.
- Lists should be surrounded by blank lines
- Use only `1.` for ordered list item prefix
- Starting bulleted lists at the beginning of the line
- Fenced code blocks should be surrounded by blank lines
this is done by checking if the user supplies `PROFILE=/dev/null` when running `install.sh`, the `nvm_detect_profile` function will not output any strings, causing `nvm_do_install` to skip adding `SOURCE_STR`.
curl output is turned off by `-s` in the same place, we should unify the
behavior on wget, also, this help removes those wget outputs that can't
fit our coding style tests. cc #1739
Use pre-built static release binary instead of building ShellCheck from
the source code, this change would save disk space, time, and much
computing resources.
Fixes
- fix unassigned variable (#1665, #1664)
- Fix for $path used by zsh (#1669)
- `set -u`: ensure `NVM_USE_OUTPUT` is always set (#1671)
- `install.sh`: Fix a bug that block that installation of node in install.sh (#1676)
- `nvm install-latest-npm`: fix node 4-4.6
Documentation
- Make `nvm cache clear` message less ambiguous (#1644)
- Added missing piece (#1658)
curl < 7.21.0 will output redirection reponse body to the output when compressed, which will cause tarball is prepended with redirection reponse body and leads to checksum mismatch.
- add `nvm_curl_use_compression` and `nvm_curl_version`
If installation is prompted to be successful, yet `which nvm` command returns `not found` then you might need to restart your terminal instance. Try opening a new tab/window in your terminal and retry.
- added git as the last method before full manual install.
- added the directory on `git clone` command
- added the `git checkout v0.33.1` as the -v gets updated automatically
Enable `--compressed` parameter on curl to automatically enable
compression on request content by sending coressponding header, if the
server side supports compression format like deflate or gzip, curl will
also decompress the content automatically, so there is no additional
works need to done manually on client side, but just enjoy the benifits
of bandwidth and time saving!
Take https://nodejs.org/dist/index.tab as an example which is last
modified on Tue, 14 Mar 2017 22:41:05 GMT, the compressed transmission
only take 4829 bytes howevet the not compressed on taks 48000 bytes,
which is about 10 times larger!
This feature can be traced back to Sep 3 2002, in curl commit:
- 64bbe9dfaf
So should be supported on various versions widely.
1. If we are not going to install nodejs or io.js from source, we may
not need to have c++ compiler or libssl-dev package
2. the `build-essential` and `libssl-dev` packages should work on all
the Debian and Ubuntu based GNU/Linux distros
3. Remove useless blank lines
By manpath's man page in Ubuntu 16.04:
> If $MANPATH is set, manpath will simply display its contents and issue
> a warning.
By fa22d712ff for #1413, `nvm` now will
declare the "MANPATH" variable, no matter if it's set or not, so in the
situation that $MANPATH is set, you'll get the warning:
> manpath: warning: $MANPATH set, ignoring /etc/manpath.config
Note: I believe this does not fix the underlying issue in zsh, which is
that it does not split up `$ADDITIONAL_PARAMETERS` and instead passes
the contents as one single argument.
This was an "oops" on my part when I was testing changes for my work
that was later adapted & merged in f1bca106a8.
LibreSSL is never installed as a `libressl` as it is intended to be a
replacement for `openssl` as much as possible, and consequently the
executable is called `openssl`.
1. This can help speed up the apt process since we decrease the
complexity of apt sources and package dependencies resolving by dropping
an additional ppa source.
2. Stack doesn't update ShellCheck to v0.4.5 after it has been released
more than one month, Cabal can provide ShellCheck v0.4.5
- Use Travis CI apt addon source whitelist to load apt source
- Use Travis CI apt addon to install additional packages
This can prevent duplicating apt package list update and dependencies
calculation which means it can speed up the CI build.
This will help speed up the installation time for the non-first time
installation, especially can speed up the build time and test time on
Travis-CI as we'll cache .cache dir.
Currently AIX isn't supported in nvm so I have made a few small changes
to make this work:
change tar to gtar for AIX
change make to gmake for AIX
Set ARCH as ppc64 for AIX
If you go to the [fin repo](https://github.com/fisherman/fin) you'll see that it isn't a node version manager, but simply a plugin manager for Fish. Seems out of scope for the readme, and there are other plugin solutions for fish as well. I suggest removing the reference.
Line 302/301 `printf "$SOURCE_STR"` is missing a trailing newline char,
while line 281/282 and 285/286 have their own new line char, so I just
remove the manually added newline char, and add it to the end of the
variable "$SOURCE_STR", so no more manually newline char needed there.
On SmartOS setups using 64 bits pkgsrc repositories, `nvm_get_arch`
would not handle pkg_info's output properly.
This would result in nvm not being to install any node binary when
running on SmartOS setups using a 64 bits pkgsrc repository.
This change fixes this problem, and fixes the tests suite on similar
setups.
git-describe was taught `--abbrev=0` in 1.5.0:
https://github.com/git/git/blob/master/Documentation/RelNotes/1.5.0.txt
git-describe was taught `--match` in 1.5.5:
https://github.com/git/git/blob/master/Documentation/RelNotes/1.5.5.txt
I don't see anything else potentially weird in here, so I think it is
safe to proclaim that the minimum git version required to run these
commands is 1.5.5.
Documenting this minimum version required here should help people debug
possible issues and help maintainers of this project understand the
impacts of modifying these commands in the future.
As suggested by @ljharb, this might be a little cleaner. I'm not
entirely sure, but in any case, it is consistent with the upgrade
instructions, so that is nice.
I recently upgraded my copy of nvm and I was disappointed to be dropped
in the .nvm directory at the end of it. I also didn't like having to
copy and paste two separate blocks of code into my terminal, because I
missed the second one the first time around and was left in a slightly
confusing state. So, I decided to make this easier by utilizing
subshells and moving all of the instructions into one code block in this
document. I think this will improve people's experience maintaining this
tool.
`git describe` will match the latest tags, regardless of what it looks
like. We can make this a little safer by adding a `--match` flag to
match tags that look like version tags. This allows the maintainers of
this repo to more safely add other types of tags if they so wish,
without causing people to install or upgrade to those versions.
I recently ran the upgrade instructions and I ended up with the version
I was already on. This happened because `git describe` describes a
commit using the most recent tag reachable from it. Since I already had
a tag checked out, it was describing the tag I had already checked out.
Thankfully, `git describe` accepts an optional commit-ish, which it will
use instead of what we have currently checked out. Testing this in my
terminal now gives me the latest tag on origin, which is what I am
interested in when updating to the latest version.
~/.nvm ❯❯❯ git describe --abbrev=0 --tags
v0.30.1
~/.nvm ❯❯❯ git describe --abbrev=0 --tags origin
v0.31.3
I also added it to the manual install instructions for consistency and
extra safety.
Fixes#1146 by grouping the commands that handle the error.
I also removed a subshell wrapper from a similar set of lines right
above. It looks to me like that is no longer necessary.
`nvm use`, `nvm run` and others check if the version is installed before executing Node, but the error message could be clearer on what steps the user has to take to achieve what they want, this makes that clearer.
When sourcing a script without parameters in zsh the sourced scripts
gets the same parameters as the sourcing file and is able to modify
these parameters. Prevent nvm from removing all parameters of sourcing
script by processing a copy of the parameters in a function.
This commit adds (optional) support for additional sha256 checksum utilities
for newer versions of node.js and io.js that use sha256 checksums rather than
sha1.
If nothing is found to do a sha256 checksum on the client machine, a warning is
printed and things continue on as normal.
Following comments from @ljharb on incorporating some of @DomT4's PR
creationix/nvm#664, and making this checksum optional. If I could I would
gladly include this as an addon to the now closed PR creationix/nvm#664. I am
choosing not to file it onto that PR because it's closed and (currently)
significantly behind the master branch.
@DomT4 did the hard work of actually finding all the different ways in which
one could verify a sha256 checksum, I've just included those here in an effort
to move forward with sha256 checksum support.
Add prompt when there is no binary for node version greater than v1.0.0
Currently, on FreeBSD, if we try `nvm install 4.2`, we will only get:
> Installing node v1.0 and greater from source is not currently supported
In fact I had no idea what's wrong because I didn't use `-s` parameter for it,
and then I found that there are two reasons:
1. There was no pre-built nodejs binary from official for FreeBSD, which means we need to build from source.
2. nvm doesn't support build for v1.0 and greater version from source yet.
So I think there should be a prompt message to tell the user about the reason why nvm will go to build from source,
no matter it will succeed or fail.
Includes references to `nvm` plugin for Oh My Fish framework,
which implements not only a fish wrapper to official `nvm` script,
but also provides completions.
Saves us ~25% bandwidth while downloading the payload. This only applies
to hosts that has the `xz` binary and attempts to use iojs 2.3.2 or newer
(this includes nodejs 4.0+ as well). Older targets are unaffected.
<!-- Thank you for being interested in nvm! Please help us by filling out the following form if you‘re having trouble. If you have a feature request, or some other question, please feel free to clear out the form. Thanks! -->
#### Operating system and version:
#### `nvm debug` output:
<details>
<!-- do not delete the following blank line -->
```sh
```
</details>
#### `nvm ls` output:
<details>
<!-- do not delete the following blank line -->
```sh
```
</details>
#### How did you install `nvm`?
<!-- (e.g. install script in readme, Homebrew) -->
#### What steps did you perform?
#### What happened?
#### What did you expect to happen?
#### Is there anything in any of your profile files that modifies the `PATH`?
- NVM_DIR=$TRAVIS_BUILD_DIR make TEST_SUITE=$TEST_SUITE URCHIN=/tmp/urchin/package/urchin test-$SHELL
- if [ -n "${SHELL-}" ] && [ -n "${TEST_SUITE}" ]; then if [ "${TEST_SUITE}" = 'installation_iojs' ]; then travis_retry make TEST_SUITE=$TEST_SUITE URCHIN="$(npm bin)/urchin" test-$SHELL ; else make TEST_SUITE=$TEST_SUITE URCHIN="$(npm bin)/urchin" test-$SHELL; fi; fi
before_cache:
- if [ -n "$WITHOUT_CURL" ]; then sudo apt-get install curl -y ; fi
`nvm`, as a member project of the OpenJS Foundation, uses [Contributor Covenant v1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct) as their code of conduct. The full text is included [below](#contributor-covenant-code-of-conduct) in English, and translations are available from the Contributor Covenant organisation:
Refer to the sections on reporting and escalation in this document for the specific emails that can be used to report and escalate issues.
## Reporting
### Project Spaces
For reporting issues in spaces related to `nvm` please use the email `ljharb@gmail.com`. `nvm` handles CoC issues related to the spaces that it maintains. Projects maintainers commit to:
- maintain the confidentiality with regard to the reporter of an incident
- to participate in the path for escalation as outlined in
the section on Escalation when required.
### Foundation Spaces
For reporting issues in spaces managed by the OpenJS Foundation, for example, repositories within the OpenJS organization, use the email `report@lists.openjsf.org`. The Cross Project Council (CPC) is responsible for managing these reports and commits to:
- maintain the confidentiality with regard to the reporter of an incident
- to participate in the path for escalation as outlined in
the section on Escalation when required.
## Escalation
The OpenJS Foundation maintains a Code of Conduct Panel (CoCP). This is a foundation-wide team established to manage escalation when a reporter believes that a report to a member project or the CPC has not been properly handled. In order to escalate to the CoCP send an email to `coc-escalation@lists.openjsf.org`.
For more information, refer to the full [Code of Conduct governance document](https://github.com/openjs-foundation/cross-project-council/blob/master/CODE_OF_CONDUCT.md).
---
## Contributor Covenant Code of Conduct
### Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
orientation.
### Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
### Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
### Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
### Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at the email addresses listed above in
the [Reporting](#reporting) and [Escalation](#escalation) sections. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an
incident. Further details of specific enforcement policies may be posted
separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct/](https://www.contributor-covenant.org/version/1/4/code-of-conduct/)
We love pull requests and issues, they're our favorite.
However, before submitting, please review the following:
- Please include tests. Changes with tests will be merged very quickly.
- Please manually confirm that your changes work in `bash`, `sh`/`dash`, `ksh`, and `zsh`. Fast tests do run in these shells, but it's nice to manually verify also.
- Please maintain consistent whitespace - 2-space indentation, trailing newlines in all files, etc.
- Any time you make a change to your PR, please rebase freshly on top of master. Nobody likes merge commits.
For bug reports:
Even if you don't have all of these items covered, please still feel free to submit a PR! Someone else may be inspired and volunteer to complete it for you.
- Please make sure the bug is reproducible, and give us the steps to reproduce it, so that we can dig into the problem.
- Please give us as much detail as possible about your environment, so we can more easily confirm the problem.
For pull requests:
- Please include tests. Changes with tests will be merged very quickly.
- Please manually confirm that your changes work in `bash`, `sh`/`dash`, `ksh`, and `zsh`. Fast tests do run in these shells, but it's nice to manually verify also.
- Please maintain consistent whitespace - 2-space indentation, trailing newlines in all files, etc.
- Any time you make a change to your PR, please rebase freshly on top of master. Nobody likes merge commits.
Even if you don't have all of these items covered, please still feel free to submit a PR/issue! Someone else may be inspired and volunteer to complete it for you.
Maintainers are responsible for issue/PR triage, feature additions, maintenance, bugfixes, security fixes, releases, promoting existing contributors to maintainers, managing repo and CI configuration, etc.
## Contributors
Anyone who contributes code or content or time, via issues or pull requests or otherwise. Contributors do not have any additional permissions on the project.
@@ -15,7 +15,7 @@ ifeq ($(findstring /,$(URCHIN)),) # urchin path was NOT passed in.
UTIL_CHECK :=$(or $(shell PATH="$(PATH)" which $(UTILS) >/dev/null &&echo'ok'),$(error Did you forget to run `npm install` after cloning the repo? At least one of the required supporting utilities not found: $(UTILS)))
endif
# The files that need updating when incrementing the version number.
# Define all shells to test with. Can be overridden with `make SHELLS=... <target>`.
SHELLS:= sh bash dash zsh # ksh (#574)
# Generate 'test-<shell>' target names from specified shells.
@@ -41,9 +41,9 @@ list:
.PHONY:$(SHELL_TARGETS)
$(SHELL_TARGETS):
@shell='$@';shell=$${shell##*-}; which "$$shell" >/dev/null ||{printf'\033[0;31m%s\033[0m\n'"WARNING: Cannot test with shell '$$shell': not found." >&2;exit 0;}&&\
printf'\n\033[0;34m%s\033[0m\n'"Running tests in $$shell";\
[ -z "$$TRAVIS_BUILD_DIR"]&&for v in $$(set| awk -F'=''$$1 ~ "^NVM_" { print $$1 }');dounset$$v;done&&unset v;\
for suite in $(TEST_SUITE);do$(URCHIN) -f -s $$shell test/$$suite || exit;done
printf'\n\033[0;34m%s\033[0m\n'"Running tests in $$shell";\
[ -z "$$TRAVIS_BUILD_DIR"]&&for v in $$(set| awk -F'=''$$1 ~ "^NVM_" { print $$1 }');dounset$$v;done&&unset v;\
for suite in $(TEST_SUITE);do$(URCHIN) -f -s $$shell test/$$suite || exit;done
# All-tests target: invokes the specified test suites for ALL shells defined in $(SHELLS).
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;};\
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;};\
nvm is a version manager for Node.js, 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.
## Section 0: Guiding Principles
The `nvm` project is part of the [OpenJS Foundation][openjs foundation], which operates transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.
## Section 1: Scope
`nvm` is a node version manager, focused on making it easy to install and manage multiple Node.js versions. Any features related to managing the installation and removal of Node.js on any node-supported platform are potentially in scope.
## Section 2: Relationship with OpenJS Foundation CPC.
Technical leadership for the projects within the [OpenJS Foundation][openjs foundation] is delegated to the projects through their project charters by the [OpenJS Foundation Cross-Project Council](https://openjsf.org/about/governance/) (CPC). In the case of the `nvm` project, it is delegated to the [`nvm` Maintainers](README.md#maintainers) (the “Maintainers”). The OpenJS Foundation's business leadership is the Board of Directors (the “Board”).
This `nvm` Charter reflects a carefully constructed balanced role for the Maintainers and the CPC in the governance of the OpenJS Foundation. The charter amendment process is for the Maintainers to propose changes using simple majority of the full Maintainers, the proposed changes being subject to review and approval by the CPC. The CPC may additionally make amendments to the project charter at any time, though the CPC will not interfere with day-to-day discussions, votes or meetings of the Maintainers.
### 2.1 Other Formal Project Relationships
Section Intentionally Left Blank
## Section 3: `nvm`'s Maintainers Governing Body
`nvm` is governed by its [maintainers](README.md#maintainers).
## Section 4: Roles & Responsibilities
The roles and responsibilities of `nvm`'s Maintainers are described in [GOVERNANCE.md](./GOVERNANCE.md).
- *Contributors*: contribute code or other artifacts, but do not have the right to commit to the codebase. Contributors work with the project’s maintainers to have code committed to the code base. A Contributor may be promoted to a Maintainer by the Maintainers. Contributors should rarely be encumbered by the Maintainers and never by the CPC or OpenJS Foundation Board.
- *Maintainers*: Contributors with any kind of decision-making authority in the project.
# Node Version Manager [][3]
## Installation
First you'll need to make sure your system has a c++ compiler. For OSX, XCode will work, for Ubuntu, the build-essential and libssl-dev packages work.
Note: `nvm` does not support Windows (see [#284](https://github.com/creationix/nvm/issues/284)). Two alternatives exist, which are neither supported nor developed by us:
Note: `nvm` does not support [Fish] either (see [#303](https://github.com/creationix/nvm/issues/303)). An alternative exists, which is neither supported nor developed by us:
- [bass](https://github.com/edc/bass) allows to use utilities written for Bash in fish shell
### Install script
To install you could use the [install script][2] using cURL:
To activate nvm, you need to source it from your shell:
. ~/.nvm/nvm.sh
I always add this line to my `~/.bashrc`, `~/.profile`, or `~/.zshrc` file to have it automatically sourced upon login.
Often I also put in a line to use a specific version of node.
## Usage
You can create an `.nvmrc` file containing version number in the project root directory (or any parent directory).
`nvm use`, `nvm install`, `nvm exec`, `nvm run`, and `nvm which` will all respect an `.nvmrc` file when a version is not supplied.
To download, compile, and install the latest v0.10.x release of node, do this:
nvm install 0.10
And then in any new shell just use the installed version:
nvm use 0.10
Or you can just run it:
nvm run 0.10 --version
Or, you can run any arbitrary command in a subshell with the desired version of node:
nvm exec 0.10 node --version
You can also get the path to the executable to where it was installed:
nvm which 0.10
In place of a version pointer like "0.10", you can use the special default aliases "stable" and "unstable":
nvm install stable
nvm install unstable
nvm use stable
nvm run unstable --version
If you want to install a new version of Node.js and migrate npm packages from a previous version:
nvm install node --reinstall-packages-from=node
This will first use "nvm version node" to identify the current version you're migrating packages from. Then it resolves the new version to install from the remote server and installs it. Lastly, it runs "nvm reinstall-packages" to reinstall the npm packages from your prior version of Node to the new one.
You can also install and migrate npm packages from specific versions of Node like this:
`nvm use` will not, by default, create a "current" symlink. Set `$NVM_SYMLINK_CURRENT` to "true" to enable this behavior, which is sometimes useful for IDEs.
## License
nvm is released under the MIT license.
Copyright (C) 2010-2014 Tim Caswell
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
## Running tests
Tests are written in [Urchin]. Install Urchin (and other dependencies) like so:
npm install
There are slow tests and fast tests. The slow tests do things like install node
and check that the right versions are used. The fast tests fake this to test
things like aliases and uninstalling. From the root of the nvm git repository,
run the fast tests like this.
npm run test/fast
Run the slow tests like this.
npm run test/slow
Run all of the tests like this
npm test
Nota bene: Avoid running nvm while the tests are running.
## Bash completion
To activate, you need to source `bash_completion`:
Put the above sourcing line just below the sourcing line for NVM in your profile (`.bashrc`, `.bash_profile`).
### Usage
nvm
$ nvm [tab][tab]
alias deactivate install ls run unload
clear-cache exec list ls-remote unalias use
current help list-remote reinstall-packages uninstall version
nvm alias
$ nvm alias [tab][tab]
default
$ nvm alias my_alias [tab][tab]
v0.6.21 v0.8.26 v0.10.28
nvm use
$ nvm use [tab][tab]
my_alias default v0.6.21 v0.8.26 v0.10.28
nvm uninstall
$ nvm uninstall [tab][tab]
my_alias default v0.6.21 v0.8.26 v0.10.28
## Compatibility Issues
`nvm` will encounter some issues if you have some non-default settings set. (see [#606](/../../issues/606))
The following are known to cause issues:
Inside `~/.npmrc`
```
prefix='some/path'
```
Environment Variables:
```
$NPM_CONFIG_PREFIX
$PREFIX
```
## Problems
If you try to install a node version and the installation fails, be sure to delete the node downloads from src (~/.nvm/src/) or you might get an error when trying to reinstall them again or you might get an error like the following:
curl: (33) HTTP server doesn't seem to support byte ranges. Cannot resume.
Where's my 'sudo node'? Check out this link:
https://github.com/creationix/nvm/issues/43
On Arch Linux and other systems using python3 by default, before running *install* you need to
export PYTHON=python2
After the v0.8.6 release of node, nvm tries to install from binary packages. But in some systems, the official binary packages don't work due to incompatibility of shared libs. In such cases, use `-s` option to force install from source:
- [Docker For Development Environment](#docker-for-development-environment)
- [Problems](#problems)
- [macOS Troubleshooting](#macos-troubleshooting)
- [Maintainers](#maintainers)
- [License](#license)
- [Copyright notice](#copyright-notice)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Intro
`nvm` allows you to quickly install and use different versions of node via the command line.
**Example:**
```sh
$ nvm use 16
Now using node v16.9.1 (npm v7.21.1)
$ node -v
v16.9.1
$ nvm use 14
Now using node v14.18.0 (npm v6.14.15)
$ node -v
v14.18.0
$ nvm install 12
Now using node v12.22.6 (npm v6.14.5)
$ node -v
v12.22.6
```
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).
<aid="installation-and-update"></a>
<aid="install-script"></a>
## Installing and Updating
### 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:
Running either of the above commands downloads a script and runs it. The script clones the nvm repository to `~/.nvm`, and attempts to add the source lines from the snippet below to the correct profile file (`~/.bash_profile`, `~/.zshrc`, `~/.profile`, or `~/.bashrc`).
[ -s "$NVM_DIR/nvm.sh"]&&\."$NVM_DIR/nvm.sh"# This loads nvm
```
#### Additional Notes
- If the environment variable `$XDG_CONFIG_HOME` is present, it will place the `nvm` files there.</sub>
- You can add `--no-use` to the end of the above script (...`nvm.sh --no-use`) to postpone using `nvm` until you manually [`use`](#usage) it.
- 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.
#### Troubleshooting on Linux
On Linux, after running the install script, if you get `nvm: command not found` or see no feedback from your terminal after you type `command -v nvm`, simply close your current terminal, open a new terminal, and try verifying again.
Alternatively, you can run the following commands for the different shells on the command line:
*bash*: `source ~/.bashrc`
*zsh*: `source ~/.zshrc`
*ksh*: `. ~/.profile`
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))
If you get `nvm: command not found` after running the install script, one of the following might be the reason:
- Since macOS 10.15, the default shell is `zsh` and nvm will look for `.zshrc` to update, none is installed by default. Create one with `touch ~/.zshrc` and run the install script again.
- If you use bash, the previous default shell, your system may not have a `.bash_profile` file where the command is set up. Create one with `touch ~/.bash_profile` and run the install script again. Then, run `source ~/.bash_profile` to pick up the `nvm` command.
- You have previously used `bash`, but you have `zsh` installed. You need to manually add [these lines](#manual-install) to `~/.zshrc` and run `. ~/.zshrc`.
- You might need to restart your terminal instance or run `. ~/.nvm/nvm.sh`. Restarting your terminal/opening a new tab/window, or running the source command will load the command and the new configuration.
- If the above didn't help, you might need to restart your terminal instance. Try opening a new tab/window in your terminal and retry.
If the above doesn't fix the problem, you may try the following:
- If you use bash, it may be that your `.bash_profile` (or `~/.profile`) does not source your `~/.bashrc` properly. You could fix this by adding `source ~/<your_profile_file>` to it or follow the next step below.
- Try adding [the snippet from the install section](#profile_snippet), that finds the correct nvm directory and loads nvm, to your usual profile (`~/.bash_profile`, `~/.zshrc`, `~/.profile`, or `~/.bashrc`).
- For more information about this issue and possible workarounds, please [refer here](https://github.com/nvm-sh/nvm/issues/576)
which should output `nvm` if the installation was successful. Please note that `which nvm` will not work, since `nvm` is a sourced shell function, not an executable binary.
**Note:** 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.
### Important Notes
If you're running a system without prepackaged binary available, which means you're going to install nodejs or io.js from its source code, you need to make sure your system has a C++ compiler. For OS X, Xcode will work, for Debian/Ubuntu based GNU/Linux, the `build-essential` and `libssl-dev` packages work.
**Note:**`nvm` also support Windows in some cases. It should work through WSL (Windows Subsystem for Linux) depending on the version of WSL. It should also work with [GitBash](https://gitforwindows.org/) (MSYS) or [Cygwin](https://cygwin.com). Otherwise, for Windows, a few alternatives exist, which are neither supported nor developed by us:
**Note:**`nvm` does not support [Fish] either (see [#303](https://github.com/nvm-sh/nvm/issues/303)). Alternatives exist, which are neither supported nor developed by us:
- [bass](https://github.com/edc/bass) allows you to use utilities written for Bash in fish shell
- [fast-nvm-fish](https://github.com/brigand/fast-nvm-fish) only works with version numbers (not aliases) but doesn't significantly slow your shell startup
- [plugin-nvm](https://github.com/derekstavis/plugin-nvm) plugin for [Oh My Fish](https://github.com/oh-my-fish/oh-my-fish), which makes nvm and its completions available in fish shell
- [fnm](https://github.com/fisherman/fnm) - [fisherman](https://github.com/fisherman/fisherman)-based version manager for fish
- [fish-nvm](https://github.com/FabioAntunes/fish-nvm) - Wrapper around nvm for fish, delays sourcing nvm until it's actually used.
**Note:** We still have some problems with FreeBSD, because there is no official pre-built binary for FreeBSD, and building from source may need [patches](https://www.freshports.org/www/node/files/patch-deps_v8_src_base_platform_platform-posix.cc); see the issue ticket:
- [[#900] [Bug] nodejs on FreeBSD may need to be patched](https://github.com/nvm-sh/nvm/issues/900)
**Note:** On OS X, if you do not have Xcode installed and you do not wish to download the ~4.3GB file, you can install the `Command Line Tools`. You can check out this blog post on how to just that:
- [How to Install Command Line Tools in OS X Mavericks & Yosemite (Without Xcode)](http://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/)
**Note:** On OS X, if you have/had a "system" node installed and want to install modules globally, keep in mind that:
- When using `nvm` you do not need `sudo` to globally install a module with `npm -g`, so instead of doing `sudo npm install -g grunt`, do instead `npm install -g grunt`
- 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.
**Note:** If you're using `zsh` you can easily install `nvm` as a zsh plugin. Install [`zsh-nvm`](https://github.com/lukechilds/zsh-nvm) and run `nvm upgrade` to upgrade.
**Note:** 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.
### Git Install
If you have `git` installed (requires git v1.7.10+):
1. clone this repo in the root of your user profile
-`cd ~/` from anywhere then `git clone https://github.com/nvm-sh/nvm.git .nvm`
1.`cd ~/.nvm` and check out the latest version with `git checkout v0.39.0`
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:
(you may have to add to more than one of the above files)
```sh
exportNVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh"]&&\."$NVM_DIR/nvm.sh"# This loads nvm
[ -s "$NVM_DIR/bash_completion"]&&\."$NVM_DIR/bash_completion"# This loads nvm bash_completion
```
### Manual Install
For a fully manual install, execute the following lines to first clone the `nvm` repository into `$HOME/.nvm`, and then load `nvm`:
To download, compile, and install the latest release of node, do this:
```sh
nvm install node # "node" is an alias for the latest version
```
To install a specific version of node:
```sh
nvm install 14.7.0 # or 16.3.0, 12.22.1, etc
```
The first version installed becomes the default. New shells will start with the default version of node (e.g., `nvm alias default`).
You can list available versions using `ls-remote`:
```sh
nvm ls-remote
```
And then in any new shell just use the installed version:
```sh
nvm use node
```
Or you can just run it:
```sh
nvm run node --version
```
Or, you can run any arbitrary command in a subshell with the desired version of node:
```sh
nvm exec 4.2 node --version
```
You can also get the path to the executable to where it was installed:
```sh
nvm which 12.22
```
In place of a version pointer like "14.7" or "16.3" or "12.22.1", you can use the following special default aliases with `nvm install`, `nvm use`, `nvm run`, `nvm exec`, `nvm which`, etc:
-`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).
### Long-term Support
Node has a [schedule](https://github.com/nodejs/Release#release-schedule) for long-term support (LTS) You can reference LTS versions in aliases and `.nvmrc` files with the notation `lts/*` for the latest LTS, and `lts/argon` for LTS releases from the "argon" line, for example. In addition, the following commands support LTS arguments:
Any time your local copy of `nvm` connects to https://nodejs.org, it will re-create the appropriate local aliases for all available LTS lines. These aliases (stored under `$NVM_DIR/alias/lts`), are managed by `nvm`, and you should not modify, remove, or create these files - expect your changes to be undone, and expect meddling with these files to cause bugs that will likely not be supported.
To get the latest LTS version of node and migrate your existing installed packages, use
If you want to install a new version of Node.js and migrate npm packages from a previous version:
```sh
nvm install node --reinstall-packages-from=node
```
This will first use "nvm version node" to identify the current version you're migrating packages from. Then it resolves the new version to install from the remote server and installs it. Lastly, it runs "nvm reinstall-packages" to reinstall the npm packages from your prior version of Node to the new one.
You can also install and migrate npm packages from specific versions of Node like this:
```sh
nvm install 6 --reinstall-packages-from=5
nvm install v4.2 --reinstall-packages-from=iojs
```
Note that reinstalling packages _explicitly does not update the npm version_ — this is to ensure that npm isn't accidentally upgraded to a broken version for the new node version.
To update npm at the same time add the `--latest-npm` flag, like this:
or, you can at any time run the following command to get the latest supported npm version on the current node version:
```sh
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.
### Default Global Packages From File While Installing
If you have a list of default packages you want installed every time you install a new version, we support that too -- just add the package names, one per line, to the file `$NVM_DIR/default-packages`. You can add anything npm would accept as a package argument on the command line.
```sh
# $NVM_DIR/default-packages
rimraf
object-inspect@1.0.2
stevemao/left-pad
```
### io.js
If you want to install [io.js](https://github.com/iojs/io.js/):
```sh
nvm install iojs
```
If you want to install a new version of io.js and migrate npm packages from a previous version:
```sh
nvm install iojs --reinstall-packages-from=iojs
```
The same guidelines mentioned for migrating npm packages in node are applicable to io.js.
### System Version of Node
If you want to use the system-installed version of node, you can use the special default alias "system":
```sh
nvm use system
nvm run system --version
```
### Listing Versions
If you want to see what versions are installed:
```sh
nvm ls
```
If you want to see what versions are available to install:
```sh
nvm ls-remote
```
### Setting Custom Colors
You can set five colors that will be used to display version and alias information. These colors replace the default colors.
Initial colors are: g b y r e
Color codes:
r/R = red / bold red
g/G = green / bold green
b/B = blue / bold blue
c/C = cyan / bold cyan
m/M = magenta / bold magenta
y/Y = yellow / bold yellow
k/K = black / bold black
e/W = light grey / white
```sh
nvm set-colors rgBcm
```
#### Persisting custom colors
If you want the custom colors to persist after terminating the shell, export the NVM_COLORS variable in your shell profile. For example, if you want to use cyan, magenta, green, bold red and bold yellow, add the following line:
```sh
exportNVM_COLORS='cmgRY'
```
#### Suppressing colorized output
`nvm help (or -h or --help)`, `nvm ls`, `nvm ls-remote` and `nvm alias` usually produce colorized output. You can disable colors with the `--no-colors` option (or by setting the environment variable `TERM=dumb`):
```sh
nvm ls --no-colors
nvm help --no-colors
TERM=dumb nvm ls
```
#### Restoring PATH
To restore your PATH, you can deactivate it:
```sh
nvm deactivate
```
#### Set default node version
To set a default Node version to be used in any new shell, use the alias 'default':
```sh
nvm alias default node
```
#### Use a mirror of node binaries
To use a mirror of the node binaries, set `$NVM_NODEJS_ORG_MIRROR`:
`nvm use` will not, by default, create a "current" symlink. Set `$NVM_SYMLINK_CURRENT` to "true" to enable this behavior, which is sometimes useful for IDEs. Note that using `nvm` in multiple shell tabs with this environment variable enabled can cause race conditions.
### .nvmrc
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.
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:
```sh
$ echo"5.9" > .nvmrc
$ echo"lts/*" > .nvmrc # to default to the latest LTS version
$ echo"node" > .nvmrc # to default to the latest version
```
[NB these examples assume a POSIX-compliant shell version of `echo`. If you use a Windows `cmd` development environment, eg the `.nvmrc` file is used to configure a remote Linux deployment, then keep in mind the `"`s will be copied leading to an invalid file. Remove them.]
Then when you run nvm:
```sh
$ nvm use
Found '/path/to/project/.nvmrc' with version <5.9>
Now using node v5.9.1 (npm v3.7.3)
```
`nvm use` et. al. will traverse directory structure upwards from the current directory looking for the `.nvmrc` file. In other words, running `nvm use` et. al. in any subdirectory of a directory with an `.nvmrc` will result in that `.nvmrc` being utilized.
The contents of a `.nvmrc` file **must** be the `<version>` (as described by `nvm --help`) followed by a newline. No trailing spaces are allowed, and the trailing newline is required.
### Deeper Shell Integration
You can use [`avn`](https://github.com/wbyoung/avn) to deeply integrate into your shell and automatically invoke `nvm` when changing directories. `avn` is **not** supported by the `nvm` maintainers. Please [report issues to the `avn` team](https://github.com/wbyoung/avn/issues/new).
If you prefer a lighter-weight solution, the recipes below have been contributed by `nvm` users. They are **not** supported by the `nvm` maintainers. We are, however, accepting pull requests for more examples.
#### bash
##### Automatically call `nvm use`
Put the following at the end of your `$HOME/.bashrc`:
```bash
cdnvm(){
commandcd"$@";
nvm_path=$(nvm_find_up .nvmrc | tr -d '\n')
# If there are no .nvmrc file, use the default nvm version
if[[ ! $nvm_path= *[^[:space:]]* ]];then
declare default_version;
default_version=$(nvm version default);
# If there is no default version, set it to `node`
# This will use the latest version on your machine
if[[$default_version=="N/A"]];then
nvm alias default node;
default_version=$(nvm version default);
fi
# If the current version is not the default version, set it to use the default version
This alias would search 'up' from your current directory in order to detect a `.nvmrc` file. If it finds it, it will switch to that version; if not, it will use the default version.
#### zsh
##### Calling `nvm use` automatically in a directory with a `.nvmrc` file
Put this into your `$HOME/.zshrc` to call `nvm use` automatically whenever you enter a directory that contains an
`.nvmrc` file with a string telling nvm which node to `use`:
```zsh
# place this after nvm initialization!
autoload -U add-zsh-hook
load-nvmrc(){
localnode_version="$(nvm version)"
localnvmrc_path="$(nvm_find_nvmrc)"
if[ -n "$nvmrc_path"];then
localnvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")
`nvm` will encounter some issues if you have some non-default settings set. (see [#606](https://github.com/creationix/nvm/issues/606))
The following are known to cause issues:
Inside `~/.npmrc`:
```sh
prefix='some/path'
```
Environment Variables:
```sh
$NPM_CONFIG_PREFIX
$PREFIX
```
Shell settings:
```sh
set -e
```
## Installing nvm on Alpine Linux
In order to provide the best performance (and other optimisations), nvm will download and install pre-compiled binaries for Node (and npm) when you run `nvm install X`. The Node project compiles, tests and hosts/provides these pre-compiled binaries which are built for mainstream/traditional Linux distributions (such as Debian, Ubuntu, CentOS, RedHat et al).
Alpine Linux, unlike mainstream/traditional Linux distributions, is based on [BusyBox](https://www.busybox.net/), a very compact (~5MB) Linux distribution. BusyBox (and thus Alpine Linux) uses a different C/C++ stack to most mainstream/traditional Linux distributions - [musl](https://www.musl-libc.org/). This makes binary programs built for such mainstream/traditional incompatible with Alpine Linux, thus we cannot simply `nvm install X` on Alpine Linux and expect the downloaded binary to run correctly - you'll likely see "...does not exist" errors if you try that.
There is a `-s` flag for `nvm install` which requests nvm download Node source and compile it locally.
If installing nvm on Alpine Linux *is* still what you want or need to do, you should be able to achieve this by running the following from you Alpine Linux shell:
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).
<aid="removal"></a>
## Uninstalling / Removal
### Manual Uninstall
To remove `nvm` manually, execute the following:
```sh
$ rm -rf "$NVM_DIR"
```
Edit `~/.bashrc` (or other shell resource config) and remove the lines below:
```sh
exportNVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh"]&&\."$NVM_DIR/nvm.sh"# This loads nvm
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:
```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`:
```sh
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nvm-dev latest 9ca4c57a97d8 7 days ago 650 MB
```
If you got no error message, now you can easily involve in:
```sh
$ docker run -h nvm-dev -it nvm-dev
nvm@nvm-dev:~/.nvm$
```
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.
For more information and documentation about docker, please refer to its official website:
- https://www.docker.com/
- https://docs.docker.com/
## Problems
- If you try to install a node version and the installation fails, be sure to run `nvm cache clear` to delete cached node downloads, or you might get an error like the following:
curl: (33) HTTP server doesn't seem to support byte ranges. Cannot resume.
- Where's my `sudo node`? Check out [#43](https://github.com/nvm-sh/nvm/issues/43)
- After the v0.8.6 release of node, nvm tries to install from binary packages. But in some systems, the official binary packages don't work due to incompatibility of shared libs. In such cases, use `-s` option to force install from source:
```sh
nvm install -s 0.8.6
```
- If setting the `default` alias does not establish the node version in new shells (i.e. `nvm current` yields `system`), ensure that the system's node `PATH` is set before the `nvm.sh` source line in your shell profile (see [#658](https://github.com/nvm-sh/nvm/issues/658))
## macOS Troubleshooting
**nvm node version not found in vim 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:
```shell
sudo chmod ugo-x /usr/libexec/path_helper
```
More on this issue in [dotphiles/dotzsh](https://github.com/dotphiles/dotzsh#mac-os-x).
**nvm is not compatible with the npm config "prefix" option**
Some solutions for this issue can be found [here](https://github.com/nvm-sh/nvm/issues/1245)
There is one more edge case causing this issue, and that's a **mismatch between the `$HOME` path and the user's home directory's actual name**.
You have to make sure that the user directory name in `$HOME` and the user directory name you'd see from running `ls /Users/`**are capitalized the same way** ([See this issue](https://github.com/nvm-sh/nvm/issues/2261)).
To change the user directory and/or account name follow the instructions [here](https://support.apple.com/en-us/HT201548)
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue[y] or abort compinit [n]? y
```
Homebrew causes insecure directories like `/usr/local/share/zsh/site-functions` and `/usr/local/share/zsh`. This is **not** an `nvm` problem - it is a homebrew problem. Refer [here](https://github.com/zsh-users/zsh-completions/issues/680) for some solutions related to the issue.
**Macs with M1 chip**
_January 2021:_ there are no pre-compiled NodeJS binaries for versions prior to 15.x for Apple's new M1 chip (arm64 architecture).
Some issues you may encounter:
- using `nvm` to install, say, `v14.15.4`:
- the C code compiles successfully
- but crashes with an out of memory error when used
- increasing the memory available to node still produces the out of memory errors:
- when using `nvm` to install some versions, the compilation fails
One solution to this issue is to change the architecture of your shell from arm64 to x86.
Let's assume that:
- you already have versions `12.20.1` and `14.15.4` installed using `nvm`
- the current version in use is `14.15.4`
- you are using the `zsh` shell
- you have Rosetta 2 installed (macOS prompts you to install Rosetta 2 the first time you open a Intel-only non-command-line application, or you may install Rosetta 2 from the command line with `softwareupdate --install-rosetta`)
```sh
# Check what version you're running:
$ node --version
v14.15.4
# Check architecture of the `node` binary:
$ node -p process.arch
arm64
# This confirms that the arch is for the M1 chip, which is causing the problems.
# So we need to uninstall it.
# We can't uninstall the version we are currently using, so switch to another version:
$ nvm install v12.20.1
# Now uninstall the version we want to replace:
$ nvm uninstall v14.15.4
# Launch a new zsh process under the 64-bit X86 architecture:
$ arch -x86_64 zsh
# Install node using nvm. This should download the precompiled x64 binary:
$ nvm install v14.15.4
# Now check that the architecture is correct:
$ node -p process.arch
x64
# It is now safe to return to the arm64 zsh process:
$ exit
# We're back to a native shell:
$ arch
arm64
# And the new version is now available to use:
$ nvm use v14.15.4
Now using node v14.15.4 (npm v6.14.10)
```
## Maintainers
Currently, the sole maintainer is [@ljharb](https://github.com/ljharb) - more maintainers are quite welcome, and we hope to add folks to the team over time. [Governance](./GOVERNANCE.md) will be re-evaluated as the project evolves.
## License
See [LICENSE.md](./LICENSE.md).
## Copyright notice
Copyright [OpenJS Foundation](https://openjsf.org) and `nvm` contributors. All rights reserved. The [OpenJS Foundation](https://openjsf.org) has registered trademarks and uses trademarks. For a list of trademarks of the [OpenJS Foundation](https://openjsf.org), please see our [Trademark Policy](https://trademark-policy.openjsf.org/) and [Trademark List](https://trademark-list.openjsf.org/). Node.js is a trademark of Joyent, Inc. and is used with its permission. Trademarks and logos not indicated on the [list of OpenJS Foundation trademarks](https://trademark-list.openjsf.org) are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
This is a list of the primary features planned for `nvm`:
- [x] Rewriting installation code paths to support installing `io.js` and `node``v4+` [from source](https://github.com/nvm-sh/nvm/issues/1188).
- This will include [reusing previously downloaded tarballs](https://github.com/nvm-sh/nvm/issues/1193) that match checksums, which is a nice performance and bandwidth bonus.
- [ ] Adding opt-in environment variable support to list, download, and install `node` [release candidates](https://github.com/nvm-sh/nvm/issues/779), and [nightly builds](https://github.com/nvm-sh/nvm/issues/1053).
- [ ] [`nvm update`](https://github.com/nvm-sh/nvm/issues/400): the ability to autoupdate `nvm` itself
- [ ] [v1.0.0](https://github.com/nvm-sh/nvm/milestone/1), including updating the [nvm on npm](https://github.com/nvm-sh/nvm/issues/304) to auto-install nvm properly
|| die ""nvm install --reinstall-packages-from" should fail when given an uninstalled version: expected '$EXPECTED_ERROR_MSG', got '$INSTALL_ERROR_MSG'"
[ "$(nvm install invalid.invalid 2>&1)" = "Version 'invalid.invalid' not found - try \`nvm ls-remote\` to browse available versions." ] || die "nvm installing an invalid version did not print a nice error message"
echo "Expected 'current' to point to v0.10.29 but was $oldLink"
exit 1
fi
rm -rf ../../v0.11.13
mkdir ../../v0.11.13
nvm use 0.11.13
rmdir ../../v0.11.13
newLink="$(readlink ../../current)"
if [ "$(basename $newLink)" != 'v0.11.13' ];then
echo "Expected 'current' to point to v0.11.13 but was $newLink"
exit 1
fi
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.