A new field in dependenciesMeta - linkBin

[zkochan]

related: pnpm/pnpm#1488

[arcanis]

A few questions I may have (not that I think they must necessarily be actioned upon, just that we should at least consider them):

Is the use-case significant enough?

On the top of my head I don't see a lot of packages that may encounter the problem described in the post. I think webpack is in this situation, maybe gatsby, but that's still a bit fringe (except in term of downloads). Can they slightly change how they operate to solve this on their side?

Is the dependenciesMeta field the best place?

Yarn implements a few fields in the dependenciesMeta field:

• built and unplugged must be listed at the top-level and affect the package wherever it is in the dependency tree.
• optional can be listed anywhere, but also affects the package wherever it is in the dependency tree (in the sense that one non-optional package will make it non-optional everywhere).

A new linkBin (which maybe should rather be bins to avoid the use of the imperative tense, which would conflict with the other fields) would be the first instance of a field that would only affect the direct dependency node. I don't think that's a problem, just an interesting note 🙂

Should the decision come from the dependent or the dependency?

In the case you described (gulp vs gulp-cli), in the end the Gulp project knows which of those binaries should have precedence. Wouldn't it make sense that they would be the one configuring which of gulp and gulp-cli has precedence over the other, rather than ask the user to configure it themselves?

I think the same thing is true for all other affected packages I have in mind: webpack vs webpack-cli, gatsby vs gatsby-cli, ...

Alternative design: precedence

Packages are processed according to their sort order, which is based on their name. Would it make sense to provide a precedence field in dependenciesMeta to change the order (higher precedences would cause the bin links to be preferred to other packages)?

Alternative design: prefer the *-cli binaries over their non-suffixed counterparts?

If all affected packages follow the same pattern, would it make sense to just say that all packages with a -cli suffix get a preferred treatment?

[zkochan]

I think the best solution would be if webpack/webpack-cli would solve this on their end. They could update webpack-cli to not export any bins. Then webpack could have a bin like the following:

#!/usr/bin/env node
try {
  require('webpack-cli');
} catch (err) {
  require('webpack');
}

[ljharb]

This is indeed how the ecosystem typically solves this; it’s not really expected to be a supported use case to have conflicting bins and be able to control which one you get.

Regarding your last alternative design, anything implicit is dangerous; i could add my own -cli package into the dep tree; and requiring the package name prefix and binary name be the same to get that precedence wouldn’t actually match frequent ecosystem usage (often package names aren’t that close to binary names).

The only thing i can think of that might make sense to properly address this problem is actively failing the install when there’s a binary name conflict.