Skip to content
This repository has been archived by the owner on May 15, 2020. It is now read-only.

lazy loading node with homebrew installed nvm issues. #24

Open
ahmedelgabri opened this issue Jan 28, 2017 · 10 comments
Open

lazy loading node with homebrew installed nvm issues. #24

ahmedelgabri opened this issue Jan 28, 2017 · 10 comments

Comments

@ahmedelgabri
Copy link

It doesn't work properly, doesn't load node from nvm & doesn't load globally installed modules too. Some issues I found:

if [[ -s "$HOME/.nvm/nvm.sh" ]]; then # 1
  lazy_load_nvm "$HOME/.nvm"

# Load package manager installed NVM into the shell session.
elif (( $+commands[brew] )) && [[ -d "$(brew --prefix nvm 2>/dev/null)" ]]; then
  lazy_load_nvm "$(brew --prefix nvm)" #2

# Return if requirements are not found.
elif (( ! $+commands[node] )); then
  return 1
fi
NODE_GLOBALS=(`find $NVM_DIR/versions/node -maxdepth 3 \( -type l -o -type f \) -wholename '*/bin/*' | xargs -n1 basename | sort | uniq`) #3
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" #4
  1. nvm.sh is not inside ~/.nvm it's inside $(brew --prefix nvm)
  2. When lazy_load_nvm gets passed $(brew --prefix nvm) as $1
  3. $NODE_GLOBALS doesn't work because the versions are inside ~/.nvm/versions not inside $(brew --prefix nvm)/versions
  4. Which loads the nvm but without $NODE_GLOBALS

Maybe this was an old behaviour that's why this script was created like this, I dunno.

For example this works for me

lazy_load_nvm() {
  NVM_DIR=$1
+ VERSIONS_DIR=$2
  # Skip adding binaries if there is no node version installed yet
  if [ -d $2/versions/node ]; then
+   NODE_GLOBALS=(`find $VERSIONS_DIR/versions/node -maxdepth 3 \( -type l -o -type f \) -wholename '*/bin/*' | xargs -n1 basename | sort | uniq`)
  fi
  NODE_GLOBALS+=("nvm")

  load_nvm () {
    # Unset placeholder functions
    for cmd in "${NODE_GLOBALS[@]}"; do unset -f ${cmd} &>/dev/null; done

    # Load NVM
+   [ -s "$(brew --prefix nvm)/nvm.sh" ] && source "$(brew --prefix nvm)/nvm.sh"
-  # [ -s "$NVM_DIR/nvm.sh" ] && source "$NVM_DIR/nvm.sh" # No clue why this doesn't work although they are identical

    # (Optional) Set the version of node to use from ~/.nvmrc if available
    nvm use 2> /dev/null 1>&2 || true

    # Do not reload nvm again
    export NVM_LOADED=1
  }

  for cmd in "${NODE_GLOBALS[@]}"; do
    # Skip defining the function if the binary is already in the PATH
    if ! which ${cmd} &>/dev/null; then
      eval "${cmd}() { unset -f ${cmd} &>/dev/null; [ -z \${NVM_LOADED+x} ] && load_nvm; ${cmd} \$@; }"
    fi
  done
}

...

+  lazy_load_nvm "$(brew --prefix nvm)" "$HOME/.nvm"

I'm by no means a shell expert though :)

@sodiumjoe
Copy link

maybe prezto should incorporate https://github.com/lukechilds/zsh-nvm, which has a lazy-load mode that seems to work at least as well as prezto's built-in version

@paulmelnikow
Copy link

paulmelnikow commented Mar 3, 2017

Thanks for this issue.

Would either you like to work up a pull request?

@lukechilds, would you be interested in replacing what we've got with your module?

I'm having trouble with nvm lazy-loading on Mac OS and would be happy to review and test.

Added: The problem I'm having is #15.

@ahmedelgabri
Copy link
Author

@paulmelnikow I think you can use zsh-nvm with prezto normally if it's not a module not 100% sure but it should work check the manual install https://github.com/lukechilds/zsh-nvm#manually

I don't use prezto anymore, I switched to zim with zplug & installed zsh-nvm too & that fixed all my issues.

@paulmelnikow
Copy link

Ah cool, maybe someone can give that a shot. Would be great to have it integrated as an external module, especially given our nvm support is buggy.

I've been following Zim, which started off as an endeavor to maintain a Prezto fork, before Matt, the author decided to rewrite it instead. It looks really promising. Technically in great shape, and also takes a smart approach of a small core. I'm curious if Matt would be interested in transitioning it to a community-managed project. There are some big advantages in what you can do when you empower and engage a community.

I've also been playing around with the plugin managers. There are a lot of them! There's zplug, Antigen, and two projects (1, 2) called zpm. Why did you decide on zplug?

@ahmedelgabri
Copy link
Author

zim now has it's own organization BTW.

Regarding zplug, honestly, it just looked simple, fast & familiar. Since it's similar to vim-plugwhich I use to manage my vim plugins — they even mention that it was inspired by it

@paulmelnikow
Copy link

Re zim, that's good to know! I hadn't seen the new organization yet. I'll have to catch up on those discussions.

Interesting, a bunch of the zsh plugin managers seem to be inspired by vim plugin managers. Seems like the vim community is ahead of the game.

@sodiumjoe
Copy link

I just recently tried to switch off of prezto to a zsh plugin manager, but they all had slower zsh startup times for my setup than prezto. I'll have to try zim.

@lukechilds
Copy link

@paulmelnikow Sorry, I'm pretty busy with other projects at the moment.

I'd probably recommend using a plugin manager and just using zsh-nvm. It gets updated fairly frequently.

If you really want to embed it in prezto it shouldn't be a big job. You should just be able to just copy/paste the lazy load function.

@lukechilds
Copy link

@sodiumjoe Yeah the tradeoff for the extra modularity is increased complexity in the loaders and therefore slower startup. However most modern plugin managers have some sort of caching functionality to make the difference pretty small.

@sodiumjoe
Copy link

@lukechilds yeah that makes sense, though I each with all available caching and prezto was still faster. For my own personal use, I don't mess with my zsh setup that often, while I open new shells all the time, so the tradeoff doesn't really make sense. This makes me hopeful about zim, though!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants