- Combined multiple scripts and stylesheets into single bundles
- Optimized load times and reduced HTTP requests
- Implemented code minification and compression
- Updated dependencies to latest versions
- Fixed security vulnerabilities in bundled code
This update enhances the overall performance and security of the application by reducing load times and minimizing potential security risks.
New Stuff
- `install.sh`: add `$ZDOTDIR` to zsh search (#3458)
Fixes
- `reinstall-packages`: do not reinstall corepack (#3544)
- avoid bash-specific syntax (#3499)
- `install-latest-npm`: npm v11 is out
- `nvm_install_latest_npm`: avoid unbound variable (#3447)
- give a more helpful message when `lts` alias is mistakenly used (#3441)
- `nvm ls`, `nvm alias`, `nvm install`: error when an LTS name is invalid
- `nvm_normalize_lts`: error when an LTS name is not lowercase (#3417)
Documentation
- [readme] update link
- [readme] fix `--no-use` example (#3479)
- [readme] update copyright notice (#3507)
- [readme] note zsh-nvm's AUTO_USE option (#2670)
- [readme] add note about reloading zshrc after editing (#3052)
- [readme] Update shell profile file install notes (#2241)
- [readme] add docker tips (#2318)
- [readme] remove `avn` from readme (#3469)
- [readme] fnm -> nvm.fish (#2541)
Refactors
- prefer `case` over if/else chains
- combine `sed -e` invocations/arguments
Tests
- `nvm exec`/`nvm run`: add `--silent` tests (#1259)
- [actions] release test needs git tags
- migrate `installation_iojs` test suite to GitHub Actions (#3476)
- Migrate slow test suite from Travis CI (#3470)
- temporarily skip this failing travis test to unblock progress
- [actions] TOC: use latest LTS node
- `install.sh`: clean up `nvm_detect_profile` tests
- `nvm_detect_profile`: refactor (#3467)
- run urchin tests on pull requests (#3466)
- update mocks
- ensure that unit tests use only mocked LTS names
- [actions] use `node/install` instead of `node/run`
Meta
- disable blank issues
- update issue template
- add DCO (#3456)
- Rename .github/ISSUE_TEMPLATE.md to .github/ISSUE_TEMPLATE/ISSUE_TEMPLATE.md (#3454)
In theory, `npx nvmrc` can now be used to validate an `.nvmrc` file that `nvm` will support. Allowances have been made for future extensibility, and aliases may no longer contain a `#`.
Fixes#3336. Closes#2288.
Co-authored-by: Jordan Harband <ljharb@gmail.com>
Co-authored-by: Yash Singh <saiansh2525@gmail.com>
Path lists in environmental variables often give special meaning to
empty entries (e.g. in PATH or MANPATH). These are represented by
leading or trailing colons, or by doubled colons in the middle of the
list.
Adjust the awk invocation to correctly deal with trailing colons by
printing the separator before every field except the first, and then
printing the final separator that is read from the input - this will
either be a colon or the null string. This preserves leading and
trailing colons in all cases while not adding extra colons in the wrong
place.
Add test to confirm the correct behaviour.
Fixes#3144
I had to dig into #2410 to learn about the `PROFILE=/dev/null` technique to install without appending to my shell config. Figured this note would be good to add in the main installation docs.
Also added a note on how to do this as a one-liner which was not obvious for me.
the `nvm.sh` file assigns and exports an `NVM_CD_FLAGS` variable if it
was sourced from a zsh shell. the fact that it's exported means that
it'll be assigned in all child processes, including the `nvm-exec`
script, which uses bash as the interpreter.
Bash's `cd` command doesn't have a `-q` flag, so if the `NVM_CD_FLAGS`
is assigned `-q`, the script will error out and incorrectly claim that
the node version isn't installed.
this also manifests itself in the `nvm exec` command.
Example:
```console
$ nvm exec 16.14.0 npm --version
Running node v16.14.0 (npm v8.3.1)
/Users/<ME>/.nvm/nvm.sh: line 28: cd: -q: invalid option
cd: usage: cd [-L|[-P [-e]] [-@]] [dir]
both the tree and the node path are required
N/A: version "v16.14.0 -> N/A" is not yet installed.
You need to run "nvm install v16.14.0" to install it before using it.
```
To address this, we unset the `NVM_CD_FLAGS` at the start of the
`nvm-exec` script, before loading `nvm.sh`.
Remove the call to `ls` that was used to determine the symlink
destination
Reasoning :
* `od` resolves symlink itself due to the use of `fopen`
* Prevent the behaviour of `od` which will hang if the filename is
empty (i.e. `/sbin/init` missing) as it will be waiting for `stdin`
compared to quitting with error if the file just doesn't exist
Fixes#3006
Incorporates old Contributing.md with more thorough details on how to contribute, create bug reports, set up the dev environment, and creating PR's itself.
No need to escape the `/` char in a grep pattern.
This is to fix the below error when using newer grep with `nvm_command_info`
> $ nvm_command_info curl
> grep: warning: stray \ before /
> /usr/bin/curl
This happens with at least GNU grep 3.8 version.
Fixes#2860.
This fixes these two linting errors:
- fqcn-builtins: Use FQCN for builtin actions.
- name: All names should start with an uppercase letter. (name[casing])
`nvm install` fails with "Binary download failed, trying source" when
- running on Bash;
- errtrace (`set -E`) is enabled;
- an ERR trap uses `exit` to return a non-zero status; and
- /sbin/init doesn't exist.
Resolved by moving `ls -dl /sbin/init` to the following `if` statement.
In this context, returning non-zero isn't an error and the ERR trap
isn't executed.
Nesting the `elif` at the same level as the `if` and `fi` makes it clear which code applies to which branch (no .nvmrc file / found .nvmrc file).
I wasted a while looking at it trying to work out how it did anything if there was a .nvmrc file, because obviously the `if` didn't match and I couldn't see the `elif` branch.
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`.
<!-- 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 (`.bashrc`, `.bash_profile`, `.zshrc`, etc) that modifies the `PATH`?
<!-- if this does not apply, please delete this section -->
- If you are having installation issues, or getting "N/A", what does `curl -v nodejs.org/dist/` print out?
<!-- 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`?
# required to fetch internal or private CodeQL packs
packages:read
# only required for workflows in private repositories
actions:read
contents:read
strategy:
fail-fast:false
matrix:
include:
- language:actions
build-mode:none
- language:javascript-typescript
build-mode:none
# CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'swift'
# Use `c-cpp` to analyze code written in C, C++ or both
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
steps:
- name:Checkout repository
uses:actions/checkout@v4
# Add any setup steps before running the `github/codeql-action/init` action.
# This includes steps like installing compilers or runtimes (`actions/setup-node`
# or others). This is typically only required for manual builds.
# - name: Setup runtime (example)
# uses: actions/setup-example@v1
# Initializes the CodeQL tools for scanning.
- name:Initialize CodeQL
uses:github/codeql-action/init@v3
with:
languages:${{ matrix.language }}
build-mode:${{ matrix.build-mode }}
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# If the analyze step fails for one of the languages you are analyzing with
# "We were unable to automatically build your code", modify the matrix above
# to set the build mode to "manual" for that language. Then modify this step
# to build your code.
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
- if:matrix.build-mode == 'manual'
shell:bash
run:|
echo 'If you are using a "manual" build mode for one or more of the' \
'languages you are analyzing, replace this with the commands to build' \
# required to fetch internal or private CodeQL packs
packages:read
# only required for workflows in private repositories
actions:read
contents:read
strategy:
fail-fast:false
matrix:
include:
- language:actions
build-mode:none
- language:javascript-typescript
build-mode:none
# CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'swift'
# Use `c-cpp` to analyze code written in C, C++ or both
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
steps:
- name:Checkout repository
uses:actions/checkout@v4
# Add any setup steps before running the `github/codeql-action/init` action.
# This includes steps like installing compilers or runtimes (`actions/setup-node`
# or others). This is typically only required for manual builds.
# - name: Setup runtime (example)
# uses: actions/setup-example@v1
# Initializes the CodeQL tools for scanning.
- name:Initialize CodeQL
uses:github/codeql-action/init@v3
with:
languages:${{ matrix.language }}
build-mode:${{ matrix.build-mode }}
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# If the analyze step fails for one of the languages you are analyzing with
# "We were unable to automatically build your code", modify the matrix above
# to set the build mode to "manual" for that language. Then modify this step
# to build your code.
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
- if:matrix.build-mode == 'manual'
shell:bash
run:|
echo 'If you are using a "manual" build mode for one or more of the' \
'languages you are analyzing, replace this with the commands to build' \
TAGS="$((echo "HEAD" && git tag --sort=-v:refname --merged HEAD --format='%(refname:strip=2) %(creatordate:short)' | grep '^v' | while read tag date; do
if [ "$(uname)" == "Darwin" ]; then
timestamp=$(date -j -f "%Y-%m-%d" "$date" +%s)
threshold=$(date -j -v-4y +%s)
else
timestamp=$(date -d "$date" +%s)
threshold=$(date -d "4 years ago" +%s)
fi
if [ $timestamp -ge $threshold ]; then echo "$tag"; fi
`nvm`, as a member project of the OpenJS Foundation, uses [Contributor Covenant v2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct/) as their code of conduct. The full text is included [below](#contributor-covenant-code-of-conduct) in English, and translations are available from the Contributor Covenant organisation:
Refer to the sections on reporting and escalation in this document for the specific emails that can be used to report and escalate issues.
## 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/HEAD/CODE_OF_CONDUCT.md).
---
# Contributor Covenant Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [@ljharb](ljharb@gmail.com).
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of actions.
**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at
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.
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.
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.
@@ -40,10 +40,14 @@ list:
# Note that preexisting NVM_* variables are unset to avoid interfering with tests, except when running the Travis tests (where NVM_DIR must be passed in and the env. is assumed to be pristine).
.PHONY:$(SHELL_TARGETS)
$(SHELL_TARGETS):
@shell='$@';shell=$${shell##*-}; which "$$shell" >/dev/null ||{printf'\033[0;31m%s\033[0m\n'"WARNING: Cannot test with shell '$$shell': not found." >&2;exit 0;}&&\
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
@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"]&&[ -z "$$GITHUB_ACTIONS"]&&for v in $$(set| awk -F'=''$$1 ~ "^NVM_" { print $$1 }');dounset$$v;done&&unset v;\
for suite in $(TEST_SUITE);do\
echo"Running test suite: $$suite";\
$(URCHIN) -f -s $$shell test/$$suite || exit;\
done
# All-tests target: invokes the specified test suites for ALL shells defined in $(SHELLS).
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;};\
- [Installing nvm on Alpine Linux](#installing-nvm-on-alpine-linux)
- [Problems](#problems)
## Installation
First you'll need to make sure your system has a c++ compiler. For OS X, 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)). 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
**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 need to be patched ](https://github.com/creationix/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, so the minimum required git version is v1.7.0 and we recommend v1.7.9.5 as it's the default version of the wildly used Ubuntu 12.04 LTS. 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.
### Install script
To install or update nvm, you can use the [install script][2] using cURL:
<sub>The script clones the nvm repository to `~/.nvm` and adds the source line to your profile (`~/.bash_profile`, `~/.zshrc`, `~/.profile`, or `~/.bashrc`).</sub>
```sh
exportNVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh"]&& . "$NVM_DIR/nvm.sh"# This loads nvm
```
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=/usr/local/nvm bash` for a global install.
<sub>*NB. The installer can use `git`, `curl`, or `wget` to download `nvm`, whatever is available.*</sub>
**Note:** On OS X, if you get `nvm: command not found` after running the install script, your system may not have a [.bash_profile file] where the command is set up. Simply create one with `touch ~/.bash_profile` and run the install script again.
If the above doesn't fix the problem, open your `.bash_profile` and add the following line of code:
`source ~/.bashrc`
- For more information about this issue and possible workarounds, please [refer here](https://github.com/creationix/nvm/issues/576)
### Verify installation
To verify that nvm has been installed, do:
```sh
command -v nvm
```
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.
### Manual install
For manual install create a folder somewhere in your filesystem with the `nvm.sh` file inside it. I put mine in `~/.nvm`.
Or if you have `git` installed (requires git v1.7+):
To download, compile, and install the latest release of node, do this:
```sh
nvm install node
```
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 5.0
```
In place of a version pointer like "0.10" or "5.0" or "4.2.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/LTS#lts_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.
### Migrating global packages while installing
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
```
### 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.js 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
```
To restore your PATH, you can deactivate it:
```sh
nvm deactivate
```
To set a default Node version to be used in any new shell, use the alias 'default':
```sh
nvm alias default node
```
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 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.
For example, to make nvm default to the latest 5.9 release for the current directory:
```sh
$ echo"5.9" > .nvmrc
$ echo"lts/*" > .nvmrc # to default to the latest LTS version
```
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)
```
### 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` development team. 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` development team. We are, however, accepting pull requests for more examples.
#### 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}")")
elif["$node_version" !="$(nvm version default)"];then
echo"Reverting to nvm default version"
nvm use default
fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc
```
## License
nvm is released under the MIT license.
Copyright (C) 2010-2016 Tim Caswell and Jordan Harband
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`:
```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 pre-these 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).
## 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:
```sh
exportPYTHON=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:
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/creationix/nvm/issues/658))
nvm is a POSIX-compliant bash script that allows you to manage multiple active Node.js versions. It provides a seamless way to switch between different versions of Node.js and manage global npm packages for each version.
## Features
- **Install**: Install any Node.js version from the command line.
- **Use**: Easily switch between multiple Node.js versions.
- **Uninstall**: Remove any Node.js version that you no longer need.
- **List**: View all installed and available Node.js versions.
- **Global Packages**: Manage global npm packages for each Node.js version.
## Installation
To install nvm, you can use the following command:
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/creationix/nvm/issues/1188).
- This will include [reusing previously downloaded tarballs](https://github.com/creationix/nvm/issues/1193) that match checksums, which is a nice performance and bandwith bonus.
- [ ] Adding opt-in environment variable support to list, download, and install `node` [release candidates](https://github.com/creationix/nvm/issues/779), and [nightly builds](https://github.com/creationix/nvm/issues/1053).
- [ ] [`nvm update`](https://github.com/creationix/nvm/issues/400): the ability to autoupdate `nvm` itself
- [ ] [v1.0.0](https://github.com/creationix/nvm/milestone/1), including updating the [nvm on npm](https://github.com/creationix/nvm/issues/304) to auto-install nvm properly
- [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'"
|| die ""nvm install --reinstall-packages-from" should fail when given an uninstalled version: expected '$EXPECTED_ERROR_MSG', got '$INSTALL_ERROR_MSG'"
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.