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

Support overriding binary linking #1488

Open
ExE-Boss opened this issue Nov 14, 2018 · 7 comments
Open

Support overriding binary linking #1488

ExE-Boss opened this issue Nov 14, 2018 · 7 comments

Comments

@ExE-Boss
Copy link
Member

ExE-Boss commented Nov 14, 2018

webpack has three CLI implementations, the modern webpack‑command, the original webpack‑cli (which used to be part of webpack before version 4) and the now bare‑bones one that comes built‑in with webpack.

In this case, it’s preferred to use either webpack‑command or webpack‑cli over the built‑in one, but pnpm doesn’t provide any way to override which webpack CLI implementation is used.

@zkochan
Copy link
Member

zkochan commented Dec 27, 2018

We probably have to come up with some declarative way to configure this. Optional peers are introducing a new field, "*Meta". Maybe we can use something like this:

"devDependencies": {
  "webpack": "^4.28.2",
  "webpack-command": "^0.4.2"
},
"devDependenciesMeta": {
  "webpack": {
    "bin": false
  }
}

cc @arcanis

@ExE-Boss
Copy link
Member Author

That could probably also work for #1580.

@arcanis
Copy link

arcanis commented Dec 29, 2018

That's interesting, I wondered in the past whether this case happened in the wild - two conflicting binaries by two different packages. Well, now it apparently does 😄

I'd probably name this field something like linkBin (bin sounds a bit too generic), but I wonder if maybe that's not a bug that should be solved by webpack ... as far as I know the behavior is currently unspecified, so it's no wonder it doesn't work really well everywhere. For all we know it could even work in npm only because of how the filesystem sort the results of readdir 😕

cc @sokra

@sokra
Copy link

sokra commented Dec 29, 2018

All these package export different named binaries. i. e. the binary of webpack-cli is registered on the webpack-cli name. There is no conflict.

@ExE-Boss
Copy link
Member Author

ExE-Boss commented Dec 29, 2018

I also encountered this with gulp and gulp‑cli.

@zkochan
Copy link
Member

zkochan commented Jul 30, 2019

I created an RFC at Yarn for the linkBin feature.

yarnpkg/rfcs#118

@milahu
Copy link
Contributor

milahu commented Aug 14, 2023

another collision:
the binary react-native is provided by react-native and @react-native-community/cli

for example in manyverse

{
  "name": "manyverse",
  "version": "0.2307.3-beta",
  "dependencies": {
    "react-native": "0.66.5"
  },
  "devDependencies": {
    "@react-native-community/cli": "~6.4.0"
  }
}

surprise: npm and pnpm produce different results:

npm prefers @react-native-community/cli

$ npm install
$ readlink node_modules/.bin/react-native
../@react-native-community/cli/build/bin.js

pnpm prefers react-native

$ pnpm install
$ grep "exec node" node_modules/.bin/react-native 
  exec node  "$basedir/../react-native/cli.js" "$@"

both npm and pnpm show no warning for the collision

expected pnpm warning

 WARN  Issues with node_modules/.bin found
- node_modules/.bin/react-native is provided by multiple packages, currently using react-native
   - react-native
   - @react-native-community/cli
hint: to prefer different packages, modify dependenciesMeta in package.json

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

No branches or pull requests

5 participants