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.
uname on SmartOS cannot be used to guess if 32 and/or 64 bits binaries
are supported, and its output is different than other uname commands on
other operating systems.
This change uses pkg_info to determine what types of binaries pkgsrc
would install. If pkg_info fails to run or is not present, this change
falls back to using isainfo -n, which determines what the kernel
supports.
It allows users to install node binaries on Solaris derivatives. io.js
can also be installed on Solaris derivatives starting with version
v3.3.1.
* Update test string that checks printed node version to pass with additional npm version display
* Remove echo -n for compatibility with shells that do not support it
When running nvm use, successful changing of versions lists the new node version. The npm version may also be switched, but this is not listed.
This commit updates nvm to display the npm version that was switched to alongside the node version
Some patterns contained a no-op `*`; the `*` would match the empty string
because # or % replacement (unlike ## or %%) tries to find the shortest match.
Also fix `nvm uninstall v1.0.3` so it won't uninstall it if it's the current version.
node versions will still take priority if there's ever a version overlap.
As mentioned in #615 it is possible to configure `>` to not override
existing files by default. `tee` is a standard tool that can be used
shell independent.
Add `io.js` support.
This branch adds support for https://github.com/iojs/io.js / https://iojs.org/
The following features should now work:
- `nvm install iojs` will install the latest `io.js` version. `nvm ls iojs` and `nvm use iojs` will function as you'd expect.
- `nvm install node` will install the latest stable `node` version. `nvm ls node` and `nvm use node` will function as you'd expect.
- In general, a specific `io.js` version can be referenced with the "iojs-" prefix. If `node` were to ever release a `v1.0.0`, `v1.0.0` would refer to `node`, and `iojs-v1.0.0` would refer to `io.js`. In the near future, `node-v1.0.0` will also refer to `node` unambiguously. This applies to all `nvm` commands, including working with aliases and `.nvmrc` files.
- `io.js`, unlike `node`, does not have a SunOS binary. Please open an issue on https://github.com/iojs/io.js if this is actually a problem for anyone, as currently it seems like this won't be for anybody.
**Note**: checksum support upon installation is currently disabled. Relates to https://github.com/iojs/io.js/issues/368.
**Note**: installation of `io.js` directly from source (via the `-s` option) is not yet enabled. This will be added soon.
Relates to https://github.com/iojs/io.js/issues/40https://github.com/iojs/io.js/issues/420Fixes#590
Conversely, a warning is issued if it is missing, because that implies that no actual cross-shell testing will take place.
Also, the shell command that determines the set of available test suites is now POSIX-compliant.
- Using `npm test` and `npm run …` scripts defined in package.json now invokes the makefile and runs the test with the same shell that npm was invoked from.
- The makefile can now be invoked directly - supporting utilities from locally installed npm packages are automatically discovered.
- Invoking the makefile without a target errors out with a hint.
- Shell-specific test targets are now named 'test-<shell>'.
- Both 'test-<shell>' targets and the all-shells 'test' target now run all test suites by default.
- On `make TAG=<new-version> release` there must be no uncommitted changes. '<new-version>' can now also be one of the following increment specifiers: 'patch', 'minor', 'major'.
- It is ensure that <new-version>, if not an increment specifier, is a valid semver version number that is higher than the previous release's.
- The previous release tag is now located with a pattern so as to exclude tags that aren't version numbers.
- Switched from lightweight to annotated tags for releases.
Add stable & unstable aliases.
Fixes#336.
With these changes, the following `nvm` commands will now support "stable" and "unstable" default/implicit aliases:
- `ls`/`list`
- `use`
- `alias`
- `run`
- `exec`
- `uninstall`
- `copy-packages`
For these, "stable" will be the latest even minor version that's locally installed; "unstable" will be the latest odd minor version that's locally installed.
In addition, `nvm ls-remote` and `nvm install` will accept the same implicit aliases, however, these will actually call nodejs.org and output the latest even and odd minor versions available for installation.
`nvm alias stable foo` and `nvm alias unstable foo` will *override* the default/implicit aliases. `nvm alias` output will reflect this by showing "(default)" when the alias is not user-defined.
After a fresh install I was unable to run the installer again. It was breaking with the error
error: branch 'master' not found.
my fix makes sure that the installer continues after that.
Install scripts don't work in pure sh; they may work on some systems where
the /bin/sh binary actually implements more than the pure Bourne Shell but
fail on other ones (e.g. Ubuntu).
Just using bash works.
Compile with CXX=c++ on FreeBSD, as FreeBSD >= 10.0 no longer has
GCC in the base system (c++ is hardlinked to clang++ on FreeBSD 10.0
and g++ on FreeBSD < 10).
FreeBSD's regular expression library does not like the pattern used
for matching explicit version strings in `nvm_ls`. Change the
pattern to something more specific that works on FreeBSD.
The `==` operator is not defined by POSIX and many test(1) (also
spelled `[`) implementations do not support it. Replace uses of
`==` with the POSIX-conformant `=` equality operator.
Add double-quotes around all expr(1) left-hand-sides where the
argument is just a variable, to prevent syntax errors when the
variable is empty.
Also avoid the `expr match ...` variant as this is not defined in
POSIX and causes errors in some implementations, including
FreeBSD's.
The `colorize_version` command fails in dash (default /bin/sh on
Ubuntu) with an error like:
local: v0.2.3: bad variable name
Instead of using a local variable, interpolate the function argument
directly to avoid the error.
Some shells do not have a nullglob feature, including dash (default
/bin/sh on Ubuntu) and the Almquist shell (default /bin/sh on
FreeBSD). An mv(1) command in setup_dir is failing due to a glob
not matching anything, so use a more widely supported construction.
In the absense of shasum(1) (which on FreeBSD is provided by Perl,
from ports) nvm falls back to sha1sum(1) which does not exist on
FreeBSD. But FreeBSD does have sha1(1) so look for sha1(1) and use
it if present.
As part of this change, refactor the execution of the checksum
program down into nvm_checksum and also clean up some special-casing
of empty dist checksums, which is already handled by nvm_checksum.
Much of the discussion in the README pertains to zsh as much as
bash, so include a specific reference to ~/.zshrc and remove one
explicit reference to bash.
On FreeBSD, if MANPATH is set it is used verbatim; configuration
files are completely ignored. Therefore, setting MANPATH to (only)
the nvm man dir makes system man pages unreachable.
To get around this, before doing anything else to MANPATH, if it is
empty set it to the output of manpath(1).
One further complication: FreeBSD automatically adds a path to the
man pages path for each path in PATH that ends in "/bin", which
causes "~/.nvm/$VERSION/man" to be added. This interferes with the
subsequent substitution so strip this from MANPATH before the
substitution.
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.
# - the path to urchin is passed via the command line.
# - the other utilities are NOT needed, so we skip the test for their existence.
URCHIN:= urchin
ifeq($(findstring /,$(URCHIN)),)# urchin path was NOT passed in.
# Add the local npm packages' bin folder to the PATH, so that `make` can find them, when invoked directly.
# Note that rather than using `$(npm bin)` the 'node_modules/.bin' path component is hard-coded, so that invocation works even from an environment
# where npm is (temporarily) unavailable due to having deactivated an nvm instance loaded into the calling shell in order to avoid interference with tests.
# The list of all supporting utilities, installed with `npm install`.
UTILS :=$(URCHIN) replace semver
# Make sure that all required utilities can be located.
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.
# The embedded shell names are extracted on demand inside the recipes.
SHELL_TARGETS:=$(addprefix test-,$(SHELLS))
# Define the default test suite(s). This can be overridden with `make TEST_SUITE=<...> <target>`.
# Test suites are the names of subfolders of './test'.
TEST_SUITE:=$(shell find ./test/* -type d -prune -exec basename {}\;)
# Default target (by virtue of being the first non '.'-prefixed in the file).
.PHONY:_no-target-specified
_no-target-specified:
$(error Please specify the target to make - `make list` shows targets. Alternatively, use `npm test` to run the default tests;`npm run` shows all tests)
# Set of test-<shell> targets; each runs the specified test suites for a single shell.
# 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
# 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;};\
# 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.
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)). 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
- [fin](https://github.com/fisherman/fin) is a pure fish node version manager for fish shell
- [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 pre-built binary from official 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.
### Install script
To install you could use the [install script](https://github.com/creationix/nvm/blob/master/install.sh) (requires Git) using cURL:
To install or update nvm, you can use the [install script][2] using cURL:
curl https://raw.github.com/creationix/nvm/master/install.sh | sh
<sub>The script clones the nvm repository to `~/.nvm` and adds the source line to your profile (`~/.bash_profile` or `~/.profile`).</sub>
<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 a folder called `nvm`.
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, then just clone it:
Or if you have `git` installed (requires git v1.5.5+):
To download, compile, and install the latest v0.10.x release of node, do this:
To download, compile, and install the latest release of node, do this:
nvm install 0.10
```sh
nvm install node
```
And then in any new shell just use the installed version:
nvm use 0.10
You can create an `.nvmrc` file containing version number in the project root folder; run the following command to switch versions:
nvm use
```sh
nvm use node
```
Or you can just run it:
nvm run 0.10
```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.
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':
nvm alias default 0.10
```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(){
if[[ -f .nvmrc && -r .nvmrc ]];then
nvm use
elif[[$(nvm 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-2013 Tim Caswell
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:
@@ -80,27 +317,24 @@ The above copyright notice and this permission notice shall be included in all c
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](https://github.com/scraperwiki/urchin). Install Urchin like so.
Tests are written in [Urchin]. Install Urchin (and other dependencies) like so:
Put the above sourcing line just below the sourcing line for NVM in your profile (`.bashrc`, `.bash_profile`).
Put the above sourcing line just below the sourcing line for nvm in your profile (`.bashrc`, `.bash_profile`).
### Usage
nvm
nvm:
$ nvm [tab][tab]
alias copy-packages help list run uninstall version
clear-cache deactivate install ls unalias use
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:
$ nvm alias [tab][tab]
default
$ nvm alias my_alias [tab][tab]
v0.4.11 v0.4.12 v0.6.14
v0.6.21 v0.8.26 v0.10.28
nvm use
nvm use:
$ nvm use [tab][tab]
my_alias default v0.4.11 v0.4.12 v0.6.14
my_alias default v0.6.21 v0.8.26 v0.10.28
nvm uninstall
nvm uninstall:
$ nvm uninstall [tab][tab]
my_alias default v0.4.11 v0.4.12 v0.6.14
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 but currently (May 2016), this is not available for Node versions newer than v0.10 so unless you need an older Node version, this won't help you. Work is in progress on source-builds for newer Node versions but is not yet complete.
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
@@ -148,11 +422,20 @@ Where's my 'sudo node'? Checkout 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
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))
This is a list of the primary features planned for `nvm`:
1. 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.
1. 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).
1. [`nvm update`](https://github.com/creationix/nvm/issues/400): the ability to autoupdate `nvm` itself
1. [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
|| die ""nvm install --reinstall-packages-from" should fail when given an uninstalled version: expected '$EXPECTED_ERROR_MSG', got '$INSTALL_ERROR_MSG'"
nvm_checksum tmp/emptyfile "da39a3ee5e6b4b0d3255bfef95601890afd80709" || die "nvm_checksum on an empty file did not match the SHA1 digest of the empty string"
nvm_checksum tmp/testfile "da39a3ee5e6b4b0d3255bfef95601890afd80709" && die "nvm_checksum allowed a bad checksum"
[ "~$(PWD=$TEST_DIR/tmp_nvm_find_up/a nvm_find_up 'test')" = "~$TEST_DIR/tmp_nvm_find_up" ] || die "failed to find 1 dir up"
[ "~$(PWD=$TEST_DIR/tmp_nvm_find_up/a/b nvm_find_up 'test')" = "~$TEST_DIR/tmp_nvm_find_up" ] || die "failed to find 2 dirs up"
[ "~$(PWD=$TEST_DIR/tmp_nvm_find_up/a/b/c nvm_find_up 'test')" = "~$TEST_DIR/tmp_nvm_find_up/a/b/c" ] || die "failed to find in current dir"
[ "~$(PWD=$TEST_DIR/tmp_nvm_find_up/a/b/c/d nvm_find_up 'test')" = "~$TEST_DIR/tmp_nvm_find_up/a/b/c" ] || die "failed to find 1 level up from current dir"
nvm_has cat && type cat > /dev/null || die 'nvm_has locates "cat" properly'
[ "~$(nvm_has foobarbaz 2>&1)" = "~" ] || die "nvm_has does not suppress error output"
! nvm_has foobarbaz && ! type foobarbaz >/dev/null 2>&1 || die "nvm_has does not return a nonzero exit code when not found"
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.