Nvm: 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 :beers:

[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).

[msafi]

@yjerem I just tried that. I put the nvm init script at the very top. Still slow, unfortunately.

[akz92]

The zsh-nvm plugin supports lazy load and solved this issue for me. My load time dropped from 2.2s to 0.8s.

[krokofant]

It's a bit hacky but this is what I use

export NVM_DIR=~/.nvm
function nvm {
    . "$(brew --prefix nvm)/nvm.sh" --no-use
    nvm use system
    nvm $@
}

[ljharb]

@krokofant please note that installing nvm with brew is unsupported, and is often the cause of many bugs, including some slowness.

[gatspy]

when add the --no-use ,how activate node in shell?

[ljharb]

@gatspy you'd then have to manually run nvm use when you were ready to use node.

[gatspy]

@ljharb tks. now i usezsh-nvm ,this is a great plugin.

[zeroby0]

@octref
Install autoenv https://github.com/kennethreitz/autoenv
and place your nvm activation command in a .env file in your node working directory

[octref]

@zeroby0
This is what I currently have and it's working fine for me.

# -------------------------------- #
# Node
# -------------------------------- #

# NVM
# . ~/.nvm/nvm.sh
# PATH=~/.nvm/versions/node/v6.10.0/bin:$PATH
export PATH=~/.nvm/versions/node/v7.7.1/bin:$PATH

I just run source ~/.nvm/nvm.sh when I actually need nvm.

[zeroby0]

@octref
Thanks a lot for the snippet :D .
This is a lot faster than nvm.

[lxe]

The two things that are slowing down the nvm.sh invocation (which automatically runs nvm use):

• running npm config get prefix which invokes, node/npm delaying things up to 2 seconds
• resolving the default alias, which takes about 1 second
• the rest of 'nvm use' is slow, which invokes awk to do a version comparison, installation verification, iojs/0.12 tricks, etc...

I'm going to take a crack at these perf issues one by one

[octref]

@lxe Looking forward to that so I can add nvm back to my .zshrc.
Same sort of things is delaying npm completion with source <(npm completion).

[ljharb]

@lxe thanks, any PRs that speed things up without sacrificing correctness are very appreciated.

[TheNotary]

Thanks for working on this @lxe! this has been slowing me down for at least the last 9 months and I didn't even realize what was causing the 1.5s delay in spinning up another terminal.

I came to this workaround after reading what @krokofant put:

# This loads nvm
export NVM_DIR=~/.nvm
function nvm {
  if [ -s "$NVM_DIR/nvm.sh" ]; then 
    . "$NVM_DIR/nvm.sh"
    nvm use system
    nvm $@
  fi
}

The brilliant part is that you can get by even if you totally forget about the workaround, node will just start working after the first time you type nvm and you think "huh, that's odd" and move on with life :)

[ljharb]

@TheNotary however, that means that both node and npm, as well as any globally installed binaries you have in the default node version, will be unavailable until the first time you've typed an nvm command.

[TheNotary]

That's the sad irony, I'm not even really much of a node developer and do not rely on any binaries, just 2 personal projects infrequently touched use node, so this delay has been for virtually nothing :/

[benirose]

@ljharb I finally got around to uninstalling NVM from homebrew and reinstalling the proper way. I'm still having the slowness issues in Bash. Again here are some stats:

$ nvm debug
nvm --version: v0.33.2
$SHELL: /bin/bash
$HOME: /Users/benrose
$NVM_DIR: '$HOME/.nvm'
$PREFIX: ''
$NPM_CONFIG_PREFIX: ''
$NVM_NODEJS_ORG_MIRROR: ''
$NVM_IOJS_ORG_MIRROR: ''
shell version: 'GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)'
uname -a: 'Darwin 15.6.0 Darwin Kernel Version 15.6.0: Mon Jan 9 23:07:29 PST 2017; root:xnu-3248.60.11.2.1~1/RELEASE_X86_64 x86_64'
OS version: Mac 10.11.6 15G1217
curl: /usr/bin/curl, curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
wget: /usr/local/bin/wget, GNU Wget 1.17.1 built on darwin15.2.0.
git: /usr/local/bin/git, git version 2.7.0
nvm current: v8.2.1
which node: $NVM_DIR/versions/node/v8.2.1/bin/node
which iojs: 
which npm: $NVM_DIR/versions/node/v8.2.1/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v8.2.1
npm root -g: $NVM_DIR/versions/node/v8.2.1/lib/node_modules

My bash profile now has the standard stuff:

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

Calling time source ~/.bash_profile with above lines in my profile:

real    0m1.276s
user    0m0.807s
sys 0m0.476s

Without them:

real    0m0.357s
user    0m0.222s
sys 0m0.137s

I do still have a default set:

$ nvm list
       v0.10.48
->       v8.2.1
default -> node (-> v8.2.1)
node -> stable (-> v8.2.1) (default)
stable -> 8.2 (-> v8.2.1) (default)
iojs -> N/A (default)
lts/* -> lts/boron (-> N/A)
lts/argon -> v4.8.4 (-> N/A)
lts/boron -> v6.11.2 (-> N/A)

Now that I have taken Homebrew out of the equation, is there anything else I can try?

[benirose]

Also, I tried doing what the original commenter mentioned, taking it out of my profile and just calling sh ~/.nvm/nvm.sh on shell sessions I want to load NVM in. After running nvm.sh I still am not able to run nvm.

[ljharb]

@benirose not sh blah, . blah - it has to be sourced, not executed.

[Tyriar]

I just put together a solution to that defers initialization of nvm until it's needed that works pretty well:

# Defer initialization of nvm until nvm, node or a node-dependent command is
# run. Ensure this block is only run once if .bashrc gets sourced multiple times
# by checking whether __init_nvm is a function.
if [ -s "$HOME/.nvm/nvm.sh" ] && [ ! "$(type -t __init_nvm)" = function ]; then
  export NVM_DIR="$HOME/.nvm"
  [ -s "$NVM_DIR/bash_completion" ] && . "$NVM_DIR/bash_completion"
  declare -a __node_commands=('nvm' 'node' 'npm' 'yarn' 'gulp' 'grunt' 'webpack')
  function __init_nvm() {
    for i in "${__node_commands[@]}"; do unalias $i; done
    . "$NVM_DIR"/nvm.sh
    unset __node_commands
    unset -f __init_nvm
  }
  for i in "${__node_commands[@]}"; do alias $i='__init_nvm && '$i; done
fi

I go into more detail in this blog post: http://www.growingwiththeweb.com/2018/01/slow-nvm-init.html

[netvisao]

W/o going too much into introspecting the nvm script, I looked into lazy loading
Here is how my ~/.bash_profile looks like

# NPM
 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 node; nvm_load; node $@'
 alias npm=' unalias npm;  nvm_load; npm  $@'

The slowdown will only be noticed when node or npm is executed the first time during the current terminal session

[ljharb]

@netvisao see https://github.com/creationix/nvm/issues/782#issuecomment-299677531 for why that's undesirable.

[netvisao]

@ljharb the first time node or npm runs, nvm is guaranteed to run, and before nvm is running, the node and npm binaries are unaliased to their system defaults. The aliases should be taking care of that.

[ljharb]

@netvisao right, but say you have eslint installed as a global binary in your nvm-managed node; eslint won't work until after node is ran, which is not desirable.

[giggio]

Great solution from @netvisao. I just changed it to unalias both npm and node:

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

[zanona]

@netvisao solution is great and should be added to the docs! It just feels like it's the right thing to do :)
@creationix what do you reckon?

[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 https://github.com/creationix/nvm/issues/782#issuecomment-246207492 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.

[rpeshkov]

I wrote small plugin for zsh (bash supported too) that just adds node version you provided in your shell config to PATH variable. This allows you to use this node version without loading nvm. If later you want full nvm, then just type nvm in your terminal. It will load nvm and nvm will take control for PATH in its own hands. Here's the link: https://github.com/rpeshkov/zsh-snv

[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: https://github.com/creationix/nvm/issues/1277#issuecomment-460013648

[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