"npm install" installs nothing if same dep is listed in both devDependencies and dependencies (v3.3.9)

[mkoryak]

my package json contains this:

  "devDependencies": {
    "hn-core": "1.0.3"
  },
  "dependencies": {
    "hn-core": "1.0.1"
  },

when I npm install, nothing is installed, unless I remove the package from dependencies.

I would expect it to install something!

Command output:

└─▪ npm i --verbose
npm info it worked if it ends with ok
npm verb cli [ 'node', '/usr/local/bin/npm', 'i', '--verbose' ]
npm info using npm@3.3.9
npm info using node@v0.12.7
npm verb lock using /Users/misha/.npm/_locks/staging-6bf179bebecf7566.lock for /Users/misha/Work/hn-enterprise-portal/node_modules/.staging
npm verb unlock done using /Users/misha/.npm/_locks/staging-6bf179bebecf7566.lock for /Users/misha/Work/hn-enterprise-portal/node_modules/.staging
npm info lifecycle hn-enterprise-portal@0.0.2~preinstall: hn-enterprise-portal@0.0.2
npm info linkStuff hn-enterprise-portal@0.0.2
npm verb linkBins hn-enterprise-portal@0.0.2
npm verb linkMans hn-enterprise-portal@0.0.2
npm info lifecycle hn-enterprise-portal@0.0.2~install: hn-enterprise-portal@0.0.2
npm info lifecycle hn-enterprise-portal@0.0.2~postinstall: hn-enterprise-portal@0.0.2
npm info lifecycle hn-enterprise-portal@0.0.2~prepublish: hn-enterprise-portal@0.0.2
npm WARN EPACKAGEJSON hn-enterprise-portal@0.0.2 No license field.
npm verb exit [ 0, true ]
npm info ok
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 14:08:05
┌─[misha@Mishas-MacBook-Pro-2][± develop✗] ~/Work/hn-enterprise-portal
└─▪ npm ls
npm info it worked if it ends with ok
npm info using npm@3.3.9
npm info using node@v0.12.7
hn-enterprise-portal@0.0.2 /Users/misha/Work/hn-enterprise-portal
└── UNMET DEPENDENCY hn-core@1.0.3

npm ERR! missing: hn-core@1.0.3, required by hn-enterprise-portal@0.0.2

[othiym23]

At the very least this should warn, so agreed that this is a bug. However, the bug's is that the dependency in both places is pinned, and it's pinned to different versions. I haven't looked at the relevant code to confirm, but my guess is that the dependency resolution algorithm is adding both versions to the list of things to install, and then another phase of the installer is removing extraneous versions and decides that that particular version of the dependency isn't what it's expecting to see, and removes it. A fix for this is verifying that only one version of a dependency is ever queued to be installed at a given level of the tree, and that that version is known across phases.

Good find! Thanks for the report!

[lxe]

cc @ganemone @mlmorg

This probably describes the same issue, but with one extra layer of nesting:

...
  "dependencies": {
    "request": "^2.65.0"
  },
  "devDependencies": {
    "bl": "^0.9.4"
  }
...

Running npm install results in this tree:

devdependency-err-missing-npm@1.0.0 /Users/aleksey/devdependency-err-missing-npm
├─┬ bl@0.9.4
│ └...
└─┬ request@2.65.0
  ...
  ├── UNMET DEPENDENCY bl@~1.0.0
  ...

npm ERR! missing: bl@~1.0.0, required by request@2.65.0

It installs only one version of bl:

devdependency-err-missing-npm@1.0.0 /Users/aleksey/devdependency-err-missing-npm
└── bl@0.9.4

(which doesn't resolve the semver of the required bl@~1.0.0).

Interestingly enough, if both are in dependencies:

"dependencies": {
    "request": "^2.65.0",
    "bl": "^0.9.4"
  }

Both versions of bl are correctly installed:

$ npm ls bl
devdependency-err-missing-npm@1.0.0 /Users/aleksey/devdependency-err-missing-npm
├── bl@0.9.4
└─┬ request@2.65.0
  └── bl@1.0.0

[mlmorg]

This is a pretty big bug. npm install often doesn't install everything because of this and you have to run it multiple times until it actually works.

[lxe]

Essentially, the workaround seems to run npm install twice.

[twolfson]

I was running into the same issue in spritesmith. I have decided to stick to using npm@2.x.x until this is patched =/

https://travis-ci.org/Ensighten/spritesmith/jobs/89172295#fold-start-before_install

https://travis-ci.org/Ensighten/spritesmith/jobs/89174714#fold-start-before_install

[lukevenn]

I've also seen this when the version is the same in both dependency lists but installing with --only=dev. It fails to install it and doing an npm ls --depth=0 doesn't list the dependency or mark it as unmet.

npm version is 3.3.12

[schmod]

With NPM 3.9.3, running npm install on a package with a conflicting dependency/devDependency, npm appears to install the version specified in devDependencies (which is what the test case says it's supposed to do).

However, npm ls still lists the package as being invalid.

The issue that @lxe describes with transitive dependencies appears to be a separate issue (most likely #10727).