Dependency name mismatches in package.json for git dependencies should produce error

[spion]

I'm opening this issue because:

• [ x ] npm is producing an incorrect install.

What's going wrong?

If a github dependency's name doesn't match the name as specified in its own package.json, npm doesn't produce an error but instead creates an unstable package-lock.json

How can the CLI team reproduce the problem?

• Add a github-based dependency, e.g. UglifyJS2's harmony branch

• use a name that doesn't match the name in that dependency's package.json (e.g. use uglify-js whereas the harmony branch contains "name":"uglify-es" in package.json

  "uglify-js":"mishoo/UglifyJS2#harmony"
  

• Run npm install

  • No errors repored
  • package-lock.json is produced that doesn't contain uglify-js (or uglify-es)

• Remove node_modules directory (but not the lockfile), then run npm install again

  • The direct dependencies of uglify-js (actually uglify-es) are removed i.e. commander and source-map. If other modules depend on them, they are still removed (and those other modules break). package-lock.json is updated as well to reflect the removals.

• Remove node_modules directory again, then run npm install again

  • More changes to package-lock.json (probably removing the indirect dependencies)

Expected behaviour:

• I think error would work best (github dependency is named incorrectly, please change it?). Not 100% sure, in theory it could ignore what the package says about its name...

supporting information:

• npm -v prints: 5.0.3
• node -v prints: v8.0.0
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?: Tested on both macOS and Linux

[iarna]

As of npm@5.1 we now consistently refuse to install it (there's no package-lock churn) but yeah, you're right, it should report this as an error.