Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A new field in dependenciesMeta - linkBin #118

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

zkochan
Copy link

@zkochan zkochan commented Jul 30, 2019

related: pnpm/pnpm#1488

@arcanis
Copy link
Member

arcanis commented Jul 30, 2019

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
Copy link
Author

zkochan commented Jul 30, 2019

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
Copy link

ljharb commented Jul 30, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants