npm prune doesn't remove peer deps that wouldn't be installed from fresh

[glenjamin]

Example which reproduces included below. I'd have expected prune to remove the extraneous dependency.

~/Development/Misc/peer-prune glen ○ retina
> npm install --save transit-immutable-js
npm http request GET https://registry.npmjs.org/transit-immutable-js
npm http 200 https://registry.npmjs.org/transit-immutable-js
peer-prune@1.0.0 /Users/glen/Development/Misc/peer-prune
├── UNMET PEER DEPENDENCY immutable@>= 3
├── transit-immutable-js@0.5.2
└── UNMET PEER DEPENDENCY transit-js@>= 0.8

npm WARN EPEERINVALID transit-immutable-js@0.5.2 requires a peer of immutable@>= 3 but none was installed.
npm WARN EPEERINVALID transit-immutable-js@0.5.2 requires a peer of transit-js@>= 0.8 but none was installed.
npm WARN EPACKAGEJSON peer-prune@1.0.0 No description
npm WARN EPACKAGEJSON peer-prune@1.0.0 No repository field.

Fri 15 Jan 22:46:47
~/Development/Misc/peer-prune glen ○ retina
> npm install --save immutable
npm http request GET https://registry.npmjs.org/immutable
npm http 304 https://registry.npmjs.org/immutable
peer-prune@1.0.0 /Users/glen/Development/Misc/peer-prune
├── immutable@3.7.6
└── UNMET PEER DEPENDENCY transit-js@>= 0.8

npm WARN EPEERINVALID transit-immutable-js@0.5.2 requires a peer of transit-js@>= 0.8 but none was installed.
npm WARN EPACKAGEJSON peer-prune@1.0.0 No description
npm WARN EPACKAGEJSON peer-prune@1.0.0 No repository field.

Fri 15 Jan 22:46:54
~/Development/Misc/peer-prune glen ○ retina
> npm install transit-js
npm http request GET https://registry.npmjs.org/transit-js
npm http 200 https://registry.npmjs.org/transit-js
npm http fetch GET https://registry.npmjs.org/transit-js/-/transit-js-0.8.846.tgz
npm http fetch 200 https://registry.npmjs.org/transit-js/-/transit-js-0.8.846.tgz
peer-prune@1.0.0 /Users/glen/Development/Misc/peer-prune
└── transit-js@0.8.846  extraneous

npm WARN EPACKAGEJSON peer-prune@1.0.0 No description
npm WARN EPACKAGEJSON peer-prune@1.0.0 No repository field.

Fri 15 Jan 22:47:00
~/Development/Misc/peer-prune glen ○ retina
> npm ls
peer-prune@1.0.0 /Users/glen/Development/Misc/peer-prune
├── immutable@3.7.6
├── transit-immutable-js@0.5.2
└── transit-js@0.8.846 extraneous

npm ERR! extraneous: transit-js@0.8.846 /Users/glen/Development/Misc/peer-prune/node_modules/transit-js

Fri 15 Jan 22:47:02
~/Development/Misc/peer-prune glen ○ retina 1
> npm prune
npm WARN package.json peer-prune@1.0.0 No description
npm WARN package.json peer-prune@1.0.0 No repository field.
npm WARN package.json peer-prune@1.0.0 No README data

Fri 15 Jan 22:47:07
~/Development/Misc/peer-prune glen ○ retina
> npm ls
peer-prune@1.0.0 /Users/glen/Development/Misc/peer-prune
├── immutable@3.7.6
├── transit-immutable-js@0.5.2
└── transit-js@0.8.846 extraneous

npm ERR! extraneous: transit-js@0.8.846 /Users/glen/Development/Misc/peer-prune/node_modules/transit-js

Fri 15 Jan 22:47:10
~/Development/Misc/peer-prune glen ○ retina 1
> rm -rf node_modules/

Fri 15 Jan 22:48:36
~/Development/Misc/peer-prune glen ○ retina
> npm i
npm http request GET https://registry.npmjs.org/transit-immutable-js
npm http request GET https://registry.npmjs.org/immutable
npm http 304 https://registry.npmjs.org/immutable
npm http 304 https://registry.npmjs.org/transit-immutable-js
peer-prune@1.0.0 /Users/glen/Development/Misc/peer-prune
├── immutable@3.7.6
├── transit-immutable-js@0.5.2
└── UNMET PEER DEPENDENCY transit-js@>= 0.8

npm WARN EPEERINVALID transit-immutable-js@0.5.2 requires a peer of transit-js@>= 0.8 but none was installed.
npm WARN EPACKAGEJSON peer-prune@1.0.0 No description
npm WARN EPACKAGEJSON peer-prune@1.0.0 No repository field.

[iarna]

Yeah, this is a bug due to prune still using npm@2 semantics. I have an experimental branch w/ a version of prune that uses npm@3 semantics, but it probably still needs a little work.

[MoOx]

@iarna is "npm prune" useless with npm3 (or even broken)?

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