package.json bin conflicts

[barneycarroll]

I've run into a problem with some packages I maintain. The package mithril used to be a self-complete package with no external dependencies, including its own test runner. It registers that internal dependency as an internal command:

  "bin": {
    "ospec": "./ospec/bin/ospec"
  },

Eventually ospec was broken out to its own discrete package, ospec.

We don't want to introduce an immediate breaking change for users reliant on mithril as a self-complete package including the ospec binary package, so we introduce a console warning in that script explaining deprecation with an eye to future removal, advising users to install the canonical ospec package.

In practice though, users can't make good on this warning: even though an installation of ospec – whose package.json registers its binary as a shorthand – supersedes the mithril installation, the prior binary registration takes precedence. This is unintuitive – I'd expect the explicit dependency on ospec to override the registration under mithrils package.

I can't find any documentation explaining the internal resolution logic for these conflicts. I did find these issues where core team acknowledge the problem – there seems to be a tentative decision to introduce warnings in case of conflict; elsewhere there's a suggestion to operate some automatic namespacing; but both issues peter off unresolved.

My own 2 cents:

• At the minimum, a warning ought to be produced when npm installs a package whose binary registrations conflict with an existing dependency.
• Conflict resolution logic ought to be documented.
• Latest registration ought to override previous registrations.

[MylesBorins]

Hey @barneycarroll thanks for the suggestions. If you want to propose a concrete change to the CLI the next step will be to open an issue over at https://github.com/npm/rfcs to propose the change.