nvm: nvm very slow to start

A lazy loading approach can be used as a work around if you’re seeing lag before the prompt becomes usable. The following can be added to your .zshrc (or .*rc):

lazy_load_nvm() {
  unset -f node nvm
  export NVM_DIR=~/.nvm
  [[ -s "$NVM_DIR/nvm.sh" ]] && source "$NVM_DIR/nvm.sh"
}

node() {
  lazy_load_nvm
  node $@
}

nvm() {
  lazy_load_nvm
  node $@
}

For anyone else finding this after reading the blog posts lately about measuring ZHS startup times:

My shell took just over 300ms to start, as measured by hyperfine. I commented out the nvm part and it dropped down to around 45ms.

I googled around and found fnm, which seems to be a port of nvm to Rust. After adding fnm to my .zshrc, and installing the same Node.js version I already before via nvm, I measured my shell startup time as 51ms.

My conclusion: for now I will replace nvm with fnm which seems to be a drop in replacement but with a 40x speedup 🐎

If anyone’s still having performance issues with the latest version of nvm, please file a new issue.

I’m not sure if this is a “performance issue”, so I’m a bit hesitant to open a new issue. ~300ms shell startup is probably fine for a lot of people, and I’m not sure that this could be fixed in nvm without switching to a complied language. But if you think that this can be improved and want any more measurements or insight I’m happy to help!

A lazy loading approach can be used as a work around if you’re seeing lag before the prompt becomes usable. The following can be added to your .zshrc (or .*rc):

lazy_load_nvm() {
  unset -f node nvm
  export NVM_DIR=~/.nvm
  [[ -s "$NVM_DIR/nvm.sh" ]] && source "$NVM_DIR/nvm.sh"
}

node() {
  lazy_load_nvm
  node $@
}

nvm() {
  lazy_load_nvm
  node $@
}

Thanks for linking this! I ended up needing to make a few changes, if anyone else runs into hiccups:

lazy_load_nvm() {
-  unset -f node nvm
+  unset -f npm node nvm
  export NVM_DIR=~/.nvm
  [[ -s "$NVM_DIR/nvm.sh" ]] && source "$NVM_DIR/nvm.sh"
+  [ -s "$NVM_DIR/bash_completion" ] && source "$NVM_DIR/bash_completion"
}

+ npm() {
+  lazy_load_nvm
+  npm $@
+ }

node() {
  lazy_load_nvm
  node $@
}

nvm() {
  lazy_load_nvm
-  node $@
+  nvm $@
}

yes, advertising other projects in any repo is quite unwelcome, and isn’t a workaround for those who wish to keep using the same project.

PRs to improve specific slow places are appreciated. This kind of profiling output is also very helpful, since it helps highlight what needs work.

Note that any lazy loading approach has some caveats; namely that any global packages you have installed won’t be available until the first time you run nvm, npm, or node.

this plugin makes loading of nvm zsh functions lazy https://github.com/lukechilds/zsh-nvm (on my machine >800ms -> ~40ms)

works great and has some interesting options; … however it has not seen the update for nearly 2 years

it would be a good course of action to incorporate the logic from that script into this one

@LinusU @abejfehr - this is what I had suggested but it was marked as spam

If anyone is interested, I have made it so it lazy loads on cmd run. I haven’t found a solution like this one yet but I know it is a combination of the solutions from above.

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

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

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use 
    fi
  elif [ "$node_version" != "$(nvm version default)" ]; then
    nvm use default
  fi
}

if [ -s "$HOME/.nvm/nvm.sh" ]; then
  export NVM_DIR="$HOME/.nvm"
  nvm_cmds=(nvm node npm yarn)
  for cmd in $nvm_cmds ; do
    alias $cmd="unalias $nvm_cmds && unset nvm_cmds && . $NVM_DIR/nvm.sh --no-use && load-nvmrc && $cmd"
  done
fi

I’ve done a bit of digging and there seems to be a lot of custom logic (and therefore additional complexity) to support “iojs”.

I might be being naive, but does anyone even use iojs? Their website looks like it was updated semi-recently, but they seem to mention that nvm doesn’t support it yet (when it has for 7 years!):

If you are used to nvm, then we have good news for you: an io.js compatible version is coming soon!

I’ve deleted anything pertaining to “iojs” from my nvm.sh file and it seems to be running a bit faster too.

Would this project be interested in a PR to remove iojs support?

Edit: I just noticed that the link to io.js’ repo from nvm’s README file just redirects to node’s repo now

I think for those who still want to use nvm-proper then it is important that a lazy loading option be integrated into the trunk. I personally am hesitant to use Rust-based tools when I can avoid them as I personally like neither the ecosystem nor the language.

And yes, advertising other projects is bad form in these places. Definitely a catch 22 since I can understand the desire to share your success and options, which is appreciated, but it can easily be seen as a slap to this project by those who invest such efforts and sacrifices to make it and keep it going… Humans are funny things.

Anyway, thanks to the developers of this project for your passion and sacrifice for such a tool.

This is my hack in the .zshrc.

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" --no-use
NODE_DEFAULT_PATH="${NVM_DIR}/versions/default/bin"
PATH="${NODE_DEFAULT_PATH}:${PATH}"
switchNode() {
  local NODE_PATH TARGET_NODE_VERSION
  if [ -f '.nvmrc' ]; then
    TARGET_NODE_VERSION="$(nvm version $(cat .nvmrc))"
    NODE_PATH="${NVM_DIR}/versions/node/${TARGET_NODE_VERSION}/bin"
  else
    TARGET_NODE_VERSION="$(nvm version default)"
    NODE_PATH="${NODE_DEFAULT_PATH}"
  fi
  if [ "${TARGET_NODE_VERSION}" != "$(nvm current)" ]; then
    PATH="${NODE_PATH}:${PATH}"
  fi
}
switchNode
add-zsh-hook chpwd switchNode

yes, advertising other projects in any repo is quite unwelcome, and isn’t a workaround for those who wish to keep using the same project.

i want to disagree here too, i don’t consider it as advertisement, it literally solved my problem because it’s incredibly fast.

I just wanted to share that since this issue I’ve long since switched to mise and it’s very performant, and is essentially a drop-in replacement for nvm (for my purposes anyway)

Take into account that the lazy load approach breaks the LSP servers with nvim if nvm is not loaded previously. I have that problem, and running NVM at least one time before opening nvim solve it.

The plumbing for that is also needed to support node RCs and nightlies, so even if i wanted to remove it (i don’t - i have 300+ repos that test on it, which constitutes over 10% of npm’s download traffic that benefits from the support) i don’t think it’d end up making things faster since we still want to add RC support in particular.

I’d love a PR that made the existing feature set faster, of course 😃

Thank you @linorabolini for your suggestion. Given that node etc. and nvm get very infrequent use from me since I mostly work with V and Ruby, having this to lighten up my load for shell load time is a wonderful help. Wish it would get mainline integration.

I’ve since switched node version managers (fnm). Offering this as a workaround for folks seeking help and finding this issue.

@lucasjohnston i’m the maintainer, and sure, either one is a great idea. PRs are welcome.

No, I don’t have any way to avoid fully loading nvm that avoids that caveat, which is the sole reason there’s no official mechanism to do that (or better, the sole reason it’s not just The Way nvm works)

The main culprit for me was the load-nvmrc function which runs every time a folder is opened. I did two things to simplify the steps taken:

1. Only run nvm if a .nvmrc file exists in the current directory, its parent (to a depth of 3), or in its immediate child. This is super quick so doesn’t slow down opening new directories, and means cd’ing into and out of directories will trigger an nvm change as expected.
2. Lazily load nvm when running a command without using internal nvm components which haven’t loaded yet

It’s not perfect, but it retains the majority of nvm’s primary features and stops me waiting forever for my shell to resolve.

Here’s my implementation:

# these lazily load nvm before your node commands
nvm_lazy_load() {
    unset -f nvm node npm npx
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"
    load-nvmrc
}
nvm() {
    nvm_lazy_load
    nvm $@
}
node() {
    nvm_lazy_load
    node $@
}
npm() {
    nvm_lazy_load
    npm $@
}
npx() {
    nvm_lazy_load
    npx $@
}
autoload -U add-zsh-hook

# this loads nvmrc when a file exists, and finds the path of the nvmrc file itself
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path=""
  local dir="$PWD"

  # Look for .nvmrc file in current directory and parent directories
  while [[ "$dir" != "" && ! -e "$dir/.nvmrc" ]]; do
    dir="${dir%/*}"
  done

  # If .nvmrc file was found, set nvmrc_path
  if [[ -e "$dir/.nvmrc" ]]; then
    nvmrc_path="$dir/.nvmrc"
  fi

  if [ -n "$nvmrc_path" ]; then
    echo "Found $nvmrc_path, switching to node $(cat "${nvmrc_path}")"
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi
  elif [ "$node_version" != "$(nvm version default)" ]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}

# this is ran on every directory, and checks if an nvmrc file exists (parent or child) first
trigger-nvm() {
  if [[ -n $(find . -maxdepth 2 -name '*.nvmrc' -type f -print -quit) || -f ../.nvmrc || -f ../../.nvmrc || -f ../../../.nvmrc ]]; then 
    nvm_lazy_load
    load-nvmrc
  fi
}
add-zsh-hook chpwd trigger-nvm

The lazy loading approaches don’t work for me since I’m using the zsh hook that automatically runs nvm use on each directory change. I want my node version to be correct when I switch between directories because I have many projects that use many node versions.

Edit: I just realized this also includes functions for node/npm/etc and that looks like it’d work, so maybe I’ll try that.