nvm-global-installs

[dylang]

Problem

When using a node installer like nvm, every time you upgrade node you need to re-install your global modules.

nvm includes nvm reinstall-packages <version>, but this is a manual process, and if you're jumping between versions frequently, you probably don't even remember which node version has the global modules you recently discovered and installed.

Solution

Module

nvm-global-installs will loop through all of the installed versions of node and return an array of installed packages and versions for each version.

{
  "2.3.0": {
    "npm": "2.11.1",
    "trash": "1.4.1"
  },
  "2.1.0": {
    "nodemon": "1.3.7",
    "npm": "2.10.1",
    "npm-check": "3.2.10"
  }
}

CLI

As a command line it might look like using npm ls --depth=0 for a bunch of node versions like such:

/Users/dylang/.nvm/versions/io.js/v2.3.0/lib
├── npm@2.11.1
└── trash@1.4.1
/Users/dylang/.nvm/versions/io.js/v2.1.0/lib
├── nodemon@1.3.7
├── npm@2.10.1
├── npm-check@3.2.10
└── trash@1.4.1
/Users/dylang/.nvm/versions/io.js/v1.0.3/lib
├── npm@2.2.0
├── pkgcount@1.2.0
└── trash@1.2.0
/Users/dylang/.nvm/v0.11.14/lib
├── barkeep@0.3.0
├── clif@0.0.1
├── depcheck@0.4.4 -> /Users/dylang/projects/pr/depcheck
├── npm@2.10.1
├── npm-check@3.2.10
├── npm-install-pr@1.4.3
├── npmrc@1.1.1
├── pkgcount@2.0.3
├── retire@0.4.0
├── tick@0.1.1
├── trash@1.4.1
└── v8-profiler@5.2.4

• Order is from newest node version to oldest.
• The active version of node is highlighted.
• Packages not installed are in the active version of node are highlighted.
• If the package is installed but the version is different only the version is highlighted.

Example highlighting

/Users/dylang/.nvm/versions/io.js/v2.3.0/lib //white, active version
├── npm@2.11.1  //white
└── trash@1.4.1 //white
/Users/dylang/.nvm/versions/io.js/v2.1.0/lib //gray
├── nodemon@1.3.7  //yellow, not in active version
├── npm@2.10.1 //gray
├── npm-check@3.2.10 //yellow
└── trash@1.4.1 //gray
/Users/dylang/.nvm/versions/io.js/v1.0.3/lib //gray
├── npm@2.2.0 //gray
├── pkgcount@1.2.0 //yellow
└── trash@1.2.0 //gray

[arthurvr]

If you set your prefix to a custom directory, ~/.npm-packages, that directory just stays when updating. Or am I wrong?

[sindresorhus]

I just use n and it works perfectly. It preserves the global packages between node versions and even comes with a nice interactive node picker. I've only had and seen problems with nvm.

[hemanth]

//cc @ljharb

[dylang]

Sharing the same global directory across versions of node/iojs doesn't work when packages have binary dependencies.

You can get strange errors like

dyld: lazy symbol binding failed: Symbol not found: __ZN2v86Object3SetENS_6HandleINS_5ValueEEES3_
  Referenced from: /..snip../node_modules/bunyan/node_modules/dtrace-provider/build/Release/DTraceProviderBindings.node
  Expected in: dynamic lookup

dyld: Symbol not found: __ZN2v86Object3SetENS_6HandleINS_5ValueEEES3_
  Referenced from: /..snip../node_modules/bunyan/node_modules/dtrace-provider/build/Release/DTraceProviderBindings.node
  Expected in: dynamic lookup

Trace/BPT trap: 5

Is this no longer an issue with newer versions of dependencies like nan?

This is the reason why we switched from n to nvm.

[ljharb]

Global packages (especially binary ones, but not just binary ones) shouldn't be used across versions of node - if it's worked great for you (with n or otherwise), great! You've been lucky. Reinstalling a package in the new version (to rerun its install scripts etc) is the only safe way to reuse global modules.

@dylang nvm-sh/nvm#668 (comment) is an example of a feature I'd be willing to add to nvm that would make it much easier for you to set up this kind of automated behavior for yourself. Would nvm find-global X help with this problem?

@sindresorhus I'd love to hear about any problems you've had with nvm in the last couple years (if it's been longer than that, I'd recommend trying it again! I've updated it a lot since I became the maintainer) so I can fix them.

[dylang]

@ljharb Thanks for joining the conversation. I appreciate your interest in improving nvm.

@sindresorhus If you feel that this is too off topic for the purpose of this repo I'm fine closing this issue.

@ljharb I would just run nvm reinstall-packages <previous-version> every time, but:

• When one module install fails, npm doesn't try to install any other global modules.
• npm link'ed dependencies re-install from npm, not npm link-style symlink.
• Some of my linked modules are not in npm yet, or they are only on my company private repo which requires being on the vpn, so those installs will fail.

Super ideal world:
An inquirer-like console UI where I can choose what to install, similar to what I created for npm-check. This is what I hope to build if the module I proposed in this ticket existed.

[ljharb]

@dylang npm linked deps do re-link now, update to the latest nvm ;-) But you are right about the limitations. There's an issue already for the third point, if you could file one for the first point I'll see what I can do.

[wilmoore]

I've only had and seen problems with nvm.

Not to disparage the hard work of the nvm authors, but to be honest, this has also been my experience.

if it's worked great for you (with n or otherwise), great! You've been lucky.

I suppose I've also been lucky. I've had way less problems using prefix vs. the workarounds necessary to use nvm effectively.

[CanRau]

Not sure when it's been introduced, now nvm supports default-packages https://github.com/nvm-sh/nvm/blob/master/README.md#default-global-packages-from-file-while-installing

It's working pretty good for me nothing to complain so far yet most probably a lot has changed 🌝

Should this issue be closable then?

[Richienb]

@dylang Your idea has been brought to life! https://github.com/Richienb/nvm-global-installs

@sindresorhus You can close this issue now.