NVM starting too slow -- can I just add the bin folder to PATH?

[octref]

Hey. I use a minimal zsh config to make sure my shell starts fast.
However after adding

. ~/.nvm/nvm.sh

The shell starts much slower.

So I changed it to

PATH=~/.nvm/versions/io.js/v2.3.3/bin:$PATH

I know I can't utilize nvm full this way, but I'm OK with just using one version. When I want to use another version I'll load ~/.nvm/nvm.sh to use nvm and then change the node bin PATH.
But will this setting break anything? Any ENV var I should set up manually?

[creationix]

As far as I know, that will work fine. You seem to understand that the nvm command won't be usable without first sourcing it.

[octref]

TY 🍻

[creationix]

FWIW, I do have a few machines where I rarely use node. I have nvm installed, but don't load it automatically. The few times I need node, I just first do . ~/nvm/nvm.sh before using nvm or node for that session.

[ljharb]

@octref By chance are you using oh-my-zsh? I've noticed that the majority of performance complaints are omz users, and past investigation makes me strongly suspect some of the options it sets causing slowness.

[octref]

@ljharb
I once tried to eliminate oh-my-zsh's slowness but failed. It's too bloated.

So I just grokked through the zsh doc and enabled the features I need.

# -------------------------------- #
# Zsh
# -------------------------------- #

fpath=(/usr/local/share/zsh-completions /usr/local/share/zsh/site-functions $fpath)

autoload -Uz compinit colors add-zsh-hook
colors
compinit

# Colored auto completion
zstyle ':completion:*' list-colors "di=34"
# Case insensitive completion
zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}'

# Stop zsh eating space before my pipe chars
export ZLE_REMOVE_SUFFIX_CHARS=''

# Allow extended glob like ^file, *~file (everything except file)
setopt extended_glob

# -------------------------------- #
# Setup prompt
# -------------------------------- #

set_prompt() {
  local ICON=''
  # Check if in a git folder
  if [ -d '.git' ] || [[ $(command git rev-parse --is-inside-work-tree 2>/dev/null) == "true" ]]; then
    # Check for uncommited changes, ignore untracked files
    if [[ -n $(command git status --porcelain --untracked-files=no | tail -1) ]]; then
      ICON="%{$fg[red]%}>"
    else
      ICON="%{$fg[green]%}>"
    fi
  else
    ICON='>'
  fi
  PROMPT=" %{$fg[blue]%}%1~ $ICON%{$reset_color%} "
}

add-zsh-hook precmd set_prompt

I feel the amount of delay omz causes is much more than the delay nvm causes.
I think you can direct those omz users to https://github.com/sindresorhus/pure . Simple and fast zsh configuration.

[ljharb]

Thanks for the tip. I'd still like to know which zsh option is causing the problem, since sourcing nvm.sh is lightning fast in stock zsh as well as every other shell I've tested. If the code you posted is all you're including beyond stock zsh then thanks, that's awesome, and I'll take a deeper look once I'm back in my country in a week and a half :-)

[benirose]

I have the issue and I'm using bash.

[ljharb]

@benirose what's nvm debug output?

[jamesvl]

I'm experiencing the nvm slowdown in bash as well.

Background: I don't really notice the slowness for a single login SSH session, but tools like vagrant rsync will do about 12 SSH sessions in quick succession, and when each takes ~1s vs. being nearly instant, it slows down file syncing by an order of magnitude.

My nvm debug output:

nvm --version: v0.31.0
$SHELL: /bin/bash
$HOME: /home/vagrant
$NVM_DIR: '$HOME/.nvm'
$PREFIX: ''
$NPM_CONFIG_PREFIX: ''
nvm current: v5.10.1
which node: $NVM_DIR/versions/node/v5.10.1/bin/node
which iojs:
which npm: $NVM_DIR/versions/node/v5.10.1/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v5.10.1
npm root -g: $NVM_DIR/versions/node/v5.10.1/lib/node_modules

This is on Ubuntu 16.04 (beta 2) server.

[ghost]

Bash user here, its slow enough to be annoying when starting a new window in tmux:

time /usr/local/opt/nvm/nvm.sh

real    0m0.617s
user    0m0.442s
sys 0m0.204s

[benirose]

@ljharb sorry I never saw the question you asked. Here's my output for nvm debug.

$ nvm debug
nvm --version: v0.30.1
$SHELL: /bin/bash
$HOME: /Users/benrose
$NVM_DIR: '$HOME/.nvm'
$PREFIX: ''
$NPM_CONFIG_PREFIX: ''
nvm current: v6.3.1
which node: $NVM_DIR/versions/node/v6.3.1/bin/node
which iojs: 
which npm: $NVM_DIR/versions/node/v6.3.1/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v6.3.1
npm root -g: $NVM_DIR/versions/node/v6.3.1/lib/node_modules
-bash: [: : integer expression expected

I installed using Homebrew and have this in my .bash_profile

export NVM_DIR=~/.nvm
. $(brew --prefix nvm)/nvm.sh

I have fairly large dotfiles, but when I do time source ~/.bash_profile with the line I get:

real    0m1.663s
user    0m0.972s
sys 0m0.596s

Versus without calling nvm.sh

real    0m0.359s
user    0m0.228s
sys 0m0.133s

I do have a default alias set, which I heard slows things down, but I'm not sure how else to configure it:

$ nvm list
       v0.10.41
         v4.4.6
         v4.4.7
->       v6.3.1
default -> 6 (-> v6.3.1)
node -> stable (-> v6.3.1) (default)
stable -> 6.3 (-> v6.3.1) (default)
iojs -> N/A (default)

I hope this helps!

[ljharb]

@benirose Thanks! I've definitely seen both bugs and performance problems when nvm is installed with homebrew (which is unsupported, and the brew formula explicitly says this when installing). Can you try brew uninstalling it, and installing the latest version with the curl command in the readme, and see if you get similar results?

[benirose]

I just did some other digging and saw the homebrew thing. That's a total bummer, and while I can understand the need to limit support scopes, the most popular package manager for mac shouldn't be excluded.

I'll give it a try to uninstall and install the old fashioned way and let you know if this helps speed things up at all.

[Tsuki]

For my case, it try to minimal the components init when starting terminal.
I have add alias nvminit='. "$(brew --prefix nvm)/nvm.sh"' as my workaround.

[ljharb]

@Tsuki there's no need to do that. just add --no-use to the line that does the sourcing, and there's no need to defer it.

[Tsuki]

@ljharb not really know what you mean. Where to add --no-use?

[ljharb]

@Tsuki . "$(brew --prefix nvm)/nvm.sh" --no-use - although I highly discourage using brew at all, as it's completely unsupported.

[Tsuki]

@ljharb Thank you, but it still cost around 0.35s. Can it pre-config node like jenv or rbenv with shims.
So that need not to load nvm.sh every time.

[msafi]

nvm is also causing my shell start-up time to be slow. Yes, I'm using oh-my-zsh. Happy to provide any additional information.

For now I'm using @Tsuki's nvminit solution like this:

alias nvminit='export NVM_DIR="/Users/mk/.nvm" && [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"'

Pretty good as a workaround...

[ljharb]

@msafi if you add --no-use after . "$NVM_DIR/nvm.sh"', is it still slow?

[msafi]

@ljharb for some reason that didn't work for me when I tried it earlier. Now it works, and it makes it faster but unfortunately it's still slower than deferring nvm initialization with nvminit

[msafi]

Can nvm initialization be run in a background process without interrupting the user? (just a thought, I don't know much about shells)

[ljharb]

Not that I know of - it needs to be sourced in the current shell session.

[msafi]

Oh, turns out if I defer nvm initialization, my global Node CLI commands don't work until I nvminit, so I guess --no-use is the best solution for now.

EDIT: looks like with --no-use I don't have access to npm and node at start-up. I have to do something like nvm use stable before I can begin using them. So, that's a no-go for me either...back to square one...

[QinMing]

I made my zsh load 0.8 seconds faster by loading nvm when "nvm", "npm" or "node" is used for the first time. Check out my Gist
https://gist.github.com/QinMing/364774610afc0e06cc223b467abe83c0#file-zshrc-L15-L37

[ljharb]

@QinMing as has been stated previously, that won't work for all the other commands you might have in the default version of node (under npm ls -g --depth=0).

[ljharb]

@zanona no, it's not a great solution, and I don't think it should be added to the docs (and there's no need to ping anybody by name, thanks).

See #782 (comment) for why it's a bad idea.

[creationix]

Someone summoned me? J/K @ljharb is doing a great job with this project, he's pretty much in charge of all decisions.

[nikhilw]

I had wrapped the nvm's startup into a function which I would just invoke manually.

function loadNVM() {
    export NVM_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
}

Solution from @netvisao 's and @giggio 's modification, does the same but better, no manual load required. But it still didnt work when I just say nvm list for example, without first running node/npm. So here is their solution combined, with one line added:

export PATH=$PATH:~/.npm/node_modules/.bin # Global modules
export NVM_DIR=$HOME/.nvm
nvm_load () { . $NVM_DIR/nvm.sh && . $NVM_DIR/bash_completion; }
alias node='unalias nvm; unalias node; unalias npm; nvm_load; node $@'
alias npm='unalias nvm; unalias node; unalias npm; nvm_load; npm $@'
alias nvm='unalias nvm; unalias node; unalias npm; nvm_load; nvm $@'

[gimenete]

Another oh-my-zsh user here. I finally have chosen this solution:

export PATH=~/.nvm/versions/node/v10.10.0/bin:$PATH
export NVM_DIR="$HOME/.nvm"
. $NVM_DIR/nvm.sh --no-use
. $NVM_DIR/bash_completion

It is fast and supports globally installed npm modules. I just need to change the Node version from time to time and make sure it's installed via nvm.

[craftey]

My solution after reading and testing several ideas and snippets: #1277 (comment)

[reduardo7]

A good solution from @pauldraper:

Replace nvm stuff in ~/.bashrc with:

export NVM_DIR="$HOME/.nvm"
nvm_load () {
  . $NVM_DIR/nvm.sh
  . $NVM_DIR/bash_completion
}
alias node='unalias nvm; unalias node; unalias npm; nvm_load; node $@'
alias npm='unalias nvm; unalias node; unalias npm; nvm_load; npm $@'
alias nvm='unalias nvm; unalias node; unalias npm; nvm_load; nvm $@'

[ljharb]

Again, note that this has the caveat of not allowing globally installed modules in the default node to work prior to invoking node/npm/nvm.

[audacioustux]

https://gist.github.com/audacioustux/4967b2c6d25a004c394455a95f676508#file-nvm-zsh

$HOME/.zsh/nvm.zsh

\. "$NVM_DIR/nvm.sh" --no-use

load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path="$(nvm_find_nvmrc)"
  local nvm_default="$(nvm version default)"

  if [ -n "$nvmrc_path" ]; then
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    unset NPM_CONFIG_PREFIX
    if [ $nvmrc_node_version = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi
  elif [ $node_version != $nvm_default ]; then
    nvm use default
    if [ $nvm_default = "system" ]; then
      export NPM_CONFIG_PREFIX=~/.npm-global
    else
      unset NPM_CONFIG_PREFIX
    fi
  else
    export NPM_CONFIG_PREFIX=~/.npm-global
  fi
}

autoload -U add-zsh-hook
add-zsh-hook chpwd load-nvmrc
load-nvmrc

.zshrc

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && source $HOME/.zsh/nvm.zsh

well... it kinda works...

• system should be default nvm alias default system
• globally installed modules are accessible, in or out nvm, but nvm version gets more precedence; @ljharb
• no need for alias
• only triggerd by .nvmrc file

[ljharb]

@audacioustux what if you have two different versions of the same module, globally installed in two nvm-managed node versions?

(also you can . $NVM_DIR/nvm.sh --no-use without incurring any speed penalty, and then you don't need to copy-paste any of nvm's functions)

[audacioustux]

@audacioustux what if you have two different versions of the same module, globally installed in two nvm-managed node versions?

(also you can . $NVM_DIR/nvm.sh --no-use without incurring any speed penalty, and then you don't need to copy-paste any of nvm's functions)

Thanks for reminding me the no-use part... i've updated the gist for my use case and happy with it 😃

[ljharb]

Setting NPM_CONFIG_PREFIX is a very bad idea; global modules must never be shared across node versions.

[audacioustux]

modified again. added the global module path at the end of $PATH, so the nvm version if installed gets higher precedence. removing the path on every switch kinda feels not good to me.

must never be shared across node versions

global node is installed and gets updated by the system package manager (e.g. Pacman, apt) ... so the globally installed modules are shared across node (stable) versions anyway on every update.
I primarily need nvm for development purposes. so .nvmrc & devDependencies is there to save me most of the time. and.. well... not the best solution but it works 😩

[Hubro]

So hey, why is this issue closed?

Also, after reading through all the comments here, I don't really see anybody discussing why nvm is so slow to initialize in the first place. Other version managers (like pyenv and rvm) are vastly faster than nvm to initialize.

Quick comparison with pyenv:

~ 
➜ time zsh -c 'eval "$(pyenv init -)"; exit'
zsh -c 'eval "$(pyenv init -)"'  0.05s user 0.02s system 101% cpu 0.062 total

~ 
➜ time zsh -c "source /usr/share/nvm/init-nvm.sh; exit"           
zsh -c "source /usr/share/nvm/init-nvm.sh; exit"  0.23s user 0.03s system 112% cpu 0.230 total
 
~ 
➜ time zsh -c "source /usr/share/nvm/init-nvm.sh; nvm use 7; exit"
Now using node v7.10.1 (npm v4.2.0)
zsh -c "source /usr/share/nvm/init-nvm.sh; nvm use 7; exit"  0.69s user 0.07s system 112% cpu 0.673 total

The NVM equivalent of doing eval "$(pyenv init -)" takes over 34 times longer to execute.

Is there nothing that can be done to speed up nvm, rather than devising workarounds like lazy loading?

Personally I find the delay when starting my terminal unacceptable, so I've switched to manually enabling nvm when I need it. I wish that wasn't necessary.

[ljharb]

@Hubro the only reason it's slow is because nvm use invokes npm config get prefix, which is slow.

The only way this can be sped up is to either a) make npm faster, or b) replicate npm's logic inside nvm, which is both complex, and a brittle approach.

If you nvm unalias default, or source nvm with --no-use, then there will be no performance impact (but you'll have to nvm use when you need node/npm).

[dpryden]

This is (a cleaned up version of) what I use (for bash) and it works for me:

export NVM_DIR="$HOME/.nvm"
# These are the Node versions installed by nvm. Add the latest one to the PATH by default.
node_versions=("$NVM_DIR"/versions/node/*)
if (( "${#node_versions[@]}" > 0 )); then
    PATH="$PATH:${node_versions[$(("${#node_versions[@]}" - 1))]}/bin"
fi
if [[ -s "$NVM_DIR/nvm.sh" ]]; then
    # Shim out `nvm` with a function that loads the real `nvm` on first use.
    # Since we already updated our PATH earlier, we don't need to actually load nvm
    # to get "node" and related binaries to work.
    nvm() {
        # shellcheck disable=SC1090
        source "$NVM_DIR/nvm.sh"
        nvm "$@"
    }
fi
if [[ -s "$NVM_DIR/bash_completion" ]]; then
    # shellcheck disable=SC1090
    source "$NVM_DIR/bash_completion"
fi

Basically, this just uses some Bash path manipulation to put the latest node version's bin directory on the path, and then adds a Bash function to lazy-load nvm for when I want to switch versions.

This reduced the startup time for a new shell by more than one second on average on my machine.

[giggio]

I changed to n, now I don't need to load anything on startup.

[craftey]

I changed to n, now I don't need to load anything on startup.

I prefer nvm over n for 4 reasons:

1. With n you cannot have different node versions in two shell sessions at the same time, AFAIK.
   This is a common situation if your work on multiple projects in parallel.
2. With n one cannot load a specific node version depending on a file .nvmrc in current folder, which is very useful if you have multiple projects with different node versions.
3. Switching node version with n took ages when I tested last time.
4. n is a shitty name for a tool.

[giggio]

It makes sense to optimize for your demands. I don't change Node.js versions that often, maybe once every few days. But I open several terminals a day, so the startup time impacts me more.
Switching could be faster, but I can easily live with it.
And I don't remember the last time I needed 2 node versions on different shell sessions, but this is clearly the main difference: nvm touches your session, not your system, and that takes time. N, on the other hand, changes the system, and the session loads faster.
And yes, N sucks as a name. You can't search for it.

[audacioustux]

https://gist.github.com/audacioustux/4967b2c6d25a004c394455a95f676508#file-nvm-zsh
with this, it takes less than one second,
and version change is only triggered by .nvmrc,
and use the system node version by default

[GRFreire]

only works with a user wi

@ljharb I was wondering if there really wasn't something I could do so nvm would load faster (and check for .nvmrc files in different projects) and I finally got a solution. I guess. If you could try it out and see if it is a viable option it would be awesome - it worked here in my machine, but you never know.

all you have to do is source fast-nvm.sh in you .zshrc

note: it uses locate to find all the .nvmrc files. Because locate is kinda slow (and defeats the purpose of this) i'm using plocate instead of mlocate (the default locate in many linux systems). All I did was install plocate and aliased to locate.

fast-nvm.sh

locate_nvmrc() {
    locate -w .nvmrc | xargs -I'{}' realpath --relative-to=. '{}' | awk '/^(\.\.\/)*\.nvmrc$/ {print $0}' | sort | xargs -I'{}' realpath '{}'
}

export PATH="$HOME/.nvm/versions/node/$(/bin/cat $HOME/.nvm/alias/default)/bin:$PATH"
nvm() {
    . $HOME/.nvm/nvm.sh; nvm "$@"
}

DEFAULT=$(locate_nvmrc)
cd() {
    if builtin cd "$@" 2>/dev/null; then
        FOUND="$(locate_nvmrc)"
        if [ "$DEFAULT" != "$FOUND" ]; then
            DEFAULT=$FOUND
            nvm use
        fi
    else
        if test -f "$@"; then echo "cd: not a directory: $*"
        elif test -d "$@"; then echo "cd: can not change to $*"
        else echo "cd: no such file or directory: $*"
        fi
        return 1
    fi
}

[ljharb]

If your locate_nvmrc function is POSIX-compliant (or, can gracefully fall back to the current one) and faster than the current one, I'd love a PR for that :-)

[GRFreire]

If your locate_nvmrc function is POSIX-compliant (or, can gracefully fall back to the current one) and faster than the current one, I'd love a PR for that :-)

Ok, not familiar with nvm codebase, but i'll try to see if I can create a pr. Also trying to do some optimizations, see how fast can this goes.

Like I said before, this is using locate, which implies that the user runs updatedb quite often (on a cron job or something). I think that to this thing to work out of the box a rewrite of this function (locate_nvmrc) need to be done. But like I said, i'll see what i can do.

edit: in the project readme there is a section about "Calling nvm use automatically in a directory with a .nvmrc file" and this is intended to run after nvm initialization. My way of doing this is to specifically avoid initializing nvm unless needed. That's why I'm checking every time I change directory. My concern here is whether you might want this alternative way without initializing nvm, or change the way nvm initializes using some of my script to in order to load faster, but still load every time. I'm not sure if I made myself clear here, feel free to ask me anything.