Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nvm-global-installs #6

Open
dylang opened this issue Jun 24, 2015 · 10 comments
Open

nvm-global-installs #6

dylang opened this issue Jun 24, 2015 · 10 comments

Comments

@dylang
Copy link

dylang commented Jun 24, 2015

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
├── [email protected]
└── [email protected]
/Users/dylang/.nvm/versions/io.js/v2.1.0/lib
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]
/Users/dylang/.nvm/versions/io.js/v1.0.3/lib
├── [email protected]
├── [email protected]
└── [email protected]
/Users/dylang/.nvm/v0.11.14/lib
├── [email protected]
├── [email protected]
├── [email protected] -> /Users/dylang/projects/pr/depcheck
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]
  • 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
├── [email protected]  //white
└── [email protected] //white
/Users/dylang/.nvm/versions/io.js/v2.1.0/lib //gray
├── [email protected]  //yellow, not in active version
├── [email protected] //gray
├── [email protected] //yellow
└── [email protected] //gray
/Users/dylang/.nvm/versions/io.js/v1.0.3/lib //gray
├── [email protected] //gray
├── [email protected] //yellow
└── [email protected] //gray
@arthurvr
Copy link

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

@sindresorhus
Copy link
Owner

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
Copy link

hemanth commented Jun 25, 2015

//cc @ljharb

@dylang
Copy link
Author

dylang commented Jun 25, 2015

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
Copy link

ljharb commented Jun 25, 2015

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
Copy link
Author

dylang commented Jun 25, 2015

@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.

npm-check

@ljharb
Copy link

ljharb commented Jun 25, 2015

@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
Copy link

wilmoore commented Mar 6, 2016

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
Copy link

CanRau commented Jan 4, 2020

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
Copy link

Richienb commented Jan 5, 2020

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

@sindresorhus You can close this issue now.

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

No branches or pull requests

8 participants