global installations fail with EPEERINVALID when completely unrelated modules have peer problems

[sam-github]

Example output below. Note that node-inspector does not depend on or use loopback in any way. I'm still tracking down what the loopback problem is, but I'm sure its unrelated to node-inspector.

Also, node-inspector, despite the dire error, installed fine, and works fine.

$ npm install -g node-inspector
[...]
npm http 304 https://registry.npmjs.org/string_decoder
/usr/local/bin/node-inspector -> /usr/local/lib/node_modules/node-inspector/bin/inspector.js
/usr/local/bin/node-debug -> /usr/local/lib/node_modules/node-inspector/bin/node-debug.js
npm ERR! peerinvalid The package loopback-datasource-juggler does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer loopback@1.6.2 wants loopback-datasource-juggler@~1.3.0
npm ERR! peerinvalid Peer loopback-connector-rest@1.1.3 wants loopback-datasource-juggler@1.x.x
npm ERR! peerinvalid Peer loopback-connector-oracle@1.1.5 wants loopback-datasource-juggler@1.x.x
npm ERR! peerinvalid Peer loopback-connector-mongodb@1.1.5 wants loopback-datasource-juggler@1.x.x

npm ERR! System Linux 3.11.0-15-generic
npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "node-inspector"
npm ERR! cwd /home/sam/p/wiki
npm ERR! node -v v0.10.25
npm ERR! npm -v 1.3.24
npm ERR! code EPEERINVALID
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/sam/p/wiki/npm-debug.log
npm ERR! not ok code 0

[sam-github]

I semi-traced down the cause of this. I had an old app I haven't worked on in a while. It had peer conflicts inside it.

That app was "npm linked".

It appears that "npm install -g X" might, after installing X, recurse down through /usr/local/lib/node_modules/* and reporting on peer dep problems in any linked modules. This seems like a side-effect, not an intended/desireable behaviour, am I missing something? Is this really a feature?

[domenic]

I'm a little unclear on the sequence of steps here. Can you tell us a set of commands we can run on a fresh install of node/npm that reproduce the problem you're describing?

[sam-github]

Thanks for commenting.

Sketch is this:

One. create an invalid app

mkdir some_app;

Set this app up so that when you do "npm ls", it complains because this application depends on modules that state peerDependencies, and those peerDependencies are not satisfied

Two. npm link that invalid app

Three. npm install -g node-inspector

(I installed node-inspector, could probably be anything)

I know step 1 isn't a series of commands. If you believe this to be a bug that would be fixed if reproduceable as opposed to a feature, or an unfixable architectural side-effect, I will find a way to npm install a set of versions that will conflict. I did this by accident, of course, with a larger app.

[domenic]

If you believe this to be a bug that would be fixed if reproduceable as opposed to a feature, or an unfixable architectural side-effect, I will find a way to npm install a set of versions that will conflict

I think it's probably a bug. It might be an annoying-to-fix architectural side effect, but nothing is unfixable, and mainly I am concerned that linking should not impact your global dependencies setup---that's a bad situation for npm to be in.

[sam-github]

ok. I will figure out cmd sequence as soon as I can.

[bajtos]

The peerinvalid error is caused by strongloop/loopback#182. Here is package.json for reproducing the problem:

{
  "dependencies": {
    "loopback-datasource-juggler": "~1.2.13",
    "loopback": "~1.6.0"
  }
}

[sam-github]

@domenic

Reproduction is easy, install two modules globally, that fail their peer dependency (in this case, of yo on grunt-cli@~0.1.7):

npm install -g yo
npm install -g grunt-cli@0.1.6

Second install will have warnings (well, it will have npm ERR!), but will install.

Now install something globally, anything, like semver, which has no relationship of any kind on yeoman or grunt:

% npm install -g semver
npm http GET https://registry.npmjs.org/semver
npm http 304 https://registry.npmjs.org/semver
/usr/local/bin/semver -> /usr/local/lib/node_modules/semver/bin/semver
npm ERR! peerinvalid The package grunt-cli does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer yo@1.1.2 wants grunt-cli@~0.1.7

npm ERR! System Linux 3.11.0-17-generic
npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "semver"
npm ERR! cwd /home/sam/w/sn/strong-cli
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.3
npm ERR! code EPEERINVALID
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/sam/w/sn/strong-cli/npm-debug.log
npm ERR! not ok code 0

In this case, semver did install correctly, and has no dependency issues.

This sucks quite badly. It makes return code and stderr of npm install -g unuseable for determing success.

Btw, you said

I am concerned that linking should not impact your global dependencies setup

I'm not sure what this means. npm link is pretty much just a way of doing a global install, but a symlin is placed in '/usr/local/lib/node_modules/'. As such, npm link instead of npm install -g could be used to produce the above.

So, yes, npm link impacts your global dependencies... because it basically is a global install.

The npm link functionality itself probably should not put symlinks in the same place as global installs, not unless called specifically as 'npm link -g' (which does not exist). Its use of the global node_modules folder as a staging between 'cd foo; npm link; cd ..../user-of-foo; npm link foo' looks like a side-effectful hack to me.

[domenic]

Second install will have warnings (well, it will have npm ERR!), but will install.

It sounds like this is the bug. At least at some point, peer conflicts would stop installation, not proceed and install despite errors.

[sam-github]

Maybe that would be desireable, maybe not. And npm certainly does NOT now, under any conditions I know of, point-blank refuse to install specific versions of packages that it has been told to install on the command line. npm refusing to follow directions would make testing quite hard. And npm link using the staging area would still kill you.

IMO, the heart of this is that npm treats the entire collection of modules installed at /usr/local/lib/node_modules as somehow related... even when they are not (semver and yeoman/grunt, for example).

[pvdz]

This is currently my state. Not sure how I got there, but I'm at a point where npm flat out refuses to install anything and the descriptions above seem to match my case. Is there any way to fix this?

[sam-github]

npm ls -g, work through to find where the problem is. Quite painful, though.

Easier might be to uninstall everything, and re npm link and npm install -g only what is necessary.

[pvdz]

I tried that but it didn't work. I fixed it by explicitly installing the package version it said was missing. Probably some kind of dependency mixup. Possibly not related to this ticket.

[lkrubner]

I've run into the same problem:

> ws@0.4.32 install /Users/lkrubner/projects/maternityneighborhood/repos/sterling/src/javascript/node_modules/karma/node_modules/socket.io/node_modules/socket.io-client/node_modules/ws
> (node-gyp rebuild 2> builderror.log) || (exit 0)

npm ERR! Darwin 11.4.2
npm ERR! argv "node" "/usr/local/bin/npm" "install"
npm ERR! node v0.10.33
npm ERR! npm  v2.1.10
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package mocha does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer karma-mocha@0.1.9 wants mocha@*
npm ERR! peerinvalid Peer mocha-as-promised@2.0.0 wants mocha@>= 1.8.0 <2

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/lkrubner/projects/maternityneighborhood/repos/sterling/src/javascript/npm-debug.log

The npm gets called from a Make file, so I'm not sure how to access it directly. If I try to do:

 npm ls -g

I get:

npm ERR! Darwin 11.4.2
npm ERR! argv "node" "/usr/local/bin/npm" "ls" "-g"
npm ERR! node v0.10.33
npm ERR! npm  v2.1.10

npm ERR! Object.keys called on non-object
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <http://github.com/npm/npm/issues>

[othiym23]

@lkrubner Do you have an npm-debug.log to go with that last error? That much, at least, is a simple bug, and one that can get fixed very soon, if you give us a gist or something similar to work from. Thanks!

[kulicuu]

I am encountering this issue. I have a repository with a submodule : framework and associated app. The app/submodule invokes repository/framework via link. I have a reflector set up in another folder universe which is a clone of same framework -- idea to point to different branches-- and again clone the submodule app. But we have an npm link issue here, because we want these distinct reflected apps to require distinct corresponding dependencies. Guessing an npm link solution not close at hand, figured to just make the reflector app invoke its framework dependency by relative path in package.json and npm install normally. But before adding that line to package.json running npm install and getting OP's error.

[...]

After adding the dependency declaration for the framework, ran npm install and got:

npm ERR! Linux 3.13.0-45-generic
npm ERR! argv "node" "/home/wylie/.nvm/v0.10.32/bin/npm" "install"
npm ERR! node v0.10.32
npm ERR! npm  v2.0.2
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package chai does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer chai-as-promised@4.1.1 wants chai@>= 1.7.0 < 2

npm ERR! Please include the following file with any support request:
npm ERR!     /home/wylie/southernOcean/Terebinth/socketstreamDevs/reflector_0/socketstream/e2e_accept/appLib/laTrappe/npm-debug.log

I should make explicit that everything works fine on the original clone, it's the reflector where the only problem arises.

Oddly, after I remove all the dependencies related to the error message (e.g. chai-as-promised)from the package.json file, I still get the same error message. And in this situation was from a separate sandboxed clone of the app by itself. And the original now no longer npm installs without error either.

Something sent npm into a kind of global cf. Nope just forgot should manually erase the node_modules folder before trying again. update it's all good probably was just a dependency issue with new version of something as I'm on version "latest" for everything, not prudent but fast.

[busches]

Is this still an issue in the latest npm? @KenanY

[bagadim]

Yes. Just got it.

Reinstall helped me in that case.

[npm-robot]

We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.

If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.

For more information about our new issue aging policies and why we've instituted them please see our blog post.