Nested git dependency not being installed.

[aleclarson]

I have three Github repos (A, B, and C).

A depends on B a la git://github.com/aleclarson/B.git#1.0.2.

A and B depend on C a la git://github.com/aleclarson/C.git#1.0.0.

B v1.0.1 is published on NPM, but v1.0.2 isn't because it's unfinished.

C is not published on NPM, as it is a work-in-progress as well.

Now, let's install A's dependencies a la npm install.

When I look at A's dependencies, the C dependency is installed just fine.

But, when I look at B's dependencies, the C dependency is not installed.

C should be installed in B's node_modules because it's in the dependencies object inside B's package.json.

No npm-debug.log is made after npm install in A's directory. So NPM thinks nothing went wrong.

Could this be my own fault? Or is NPM not prepared for a situation like this?

Thanks for any help!

[smikes]

This is something that will be changing soon with npm@3, the multi-stage-install branch, but at the moment, if npm sees that a dependency (in this case, B's dependency on C) can be satisfied by another existing install of the same module (in this case, A's dependency on C), then npm automatically dedupes it.

If you need to have a version of C under B's node_modules, you can always run

cd node_modules/B
npm install git://github.com/aleclarson/C.git#1.0.0

This should force C to be installed, even if it can be satisfied by a C higher up the tree.

[aleclarson]

Thanks for your reply! I'm already doing the workaround, but thanks for that too.

What's weird is that the current behavior makes B throw:

Error: Cannot find module 'C'

I must be doing something wrong, because surely NPM doesn't mean to break my dependencies just to save space.

[othiym23]

This is a bug, and is related to #7202, if not the same exact bug. Thanks for filing this! Git is a giant forest of edge cases.

[iarna]

I actually think there was an early misunderstanding in this issue, and I think the behavior, as described, is correct.

Given:

• A depends on B a la git://github.com/aleclarson/B.git#1.0.2.
• A and B depend on C a la git://github.com/aleclarson/C.git#1.0.0.

I would expect a tree like:

A@1.0.0 /path/to/A
├── B@1.0.2
└── C@1.0.0

B doesn't install its own copy of C because it can already see and use the copy A got. This is normal behavior. There is a race here in what your tree looks like, because if B's-C gets installed first then A will also get a copy, since A can't use B's-C. But this race won't change the behavior of A nor B.

[othiym23]

Error: Cannot find module 'C'

Under which circumstances are you getting this error? I don't think it's coming from Node or npm.

@iarna is right – and I somehow overlooked this in my earlier response, sorry – that if both A and B depend on C@1.0.0, npm is right to not install C under B, because there's already a copy of C that B can use under A – that's how the Node module resolution algorithm works.

[aleclarson]

This may have been a freak issue. Not sure how to reproduce.

But after using the "workaround" once, this issue never appeared again.

Sorry for all the confusion!

I'll be sure to report back here if it happens again.