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
Warning on XO install: has unmet peer dependency webpack #449
Comments
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
For what it's worth, I created a package ignoredep so you can add this to your package.json: {
"dependencies": {
// ...
"webpack": "npm:ignoredep@>=1.11.0",
// ...
}
} and that should get rid of the error message (at least, it did for me) |
Nice hack, thank you! But can we fix this properly? I assume the way this works is that
|
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
One of suggested solution is probably right, actually:
Now the choice is between:
Given how similar issues have been handled, I don’t think the latter will happen since XO is seen as "batteries included" and because the warning isn't a big deal. But let's see what the maintainers think. I also tried peerDependenciesMeta but it did not work. Similar issues: |
The other issue is that I can't replicate this issue with npm 7 nor with npm 8.
What npm version do you use? Can you replicate this issue in a fresh project? Try this in an empty folder and take a screenshot:
|
So I found out: This is a Yarn-specific issue that was fixed in npm 7 and npm 8. I don’t think anyone is interested in adding a workaround for something that Yarn developers choose to ignore. So you have two choices:
|
Hey @fregante - the behavior you describe is perfectly intended. It's how peer dependencies have worked for the past 6 years, and there is no plan to change that. Note that while npm 7+ does happen to auto-install peer dependencies, it's a non-standard behaviour that both Yarn and pnpm have expressed concerns against back when it was still in rfc period (lots of comments explaining why, I invite you to dig if you're curious); while our comments were largely ignored, our position still stands: we don't think this change is beneficial to the ecosystem (it may be handful in a couple of case, but very disruptive in many others), so we won't implement it as-is. There is a simple portable fix, which is to mark webpack as an optional peer dependency (essentially #678). This is supported by both Yarn, pnpm, and npm. |
I'm not here to argue about that, you made the choice and your users deal with them.
That does not seem to be the case:
Live run at: https://github.com/fregante/sandbox/runs/7764563532?check_suite_focus=true |
That’s yarn 1, with yarn 2 and the changes from my PR, everything seems to be in order: $ mkdir repro-yarn2-xo-peerdep
$ cd repro-yarn2-xo-peerdep
$ yarn init -2
➤ YN0000: Retrieving https://repo.yarnpkg.com/3.2.2/packages/yarnpkg-cli/bin/yarn.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-3.2.2.cjs
➤ YN0000: Done in 0s 434ms
{
name: 'repro-yarn2-xo-peerdep',
packageManager: 'yarn@3.2.2'
}
$ yarn add 'xo@https://github.com/flying-sheep/xo.git#webpack-peer-dep'
➤ YN0000: ┌ Resolution step
➤ YN0013: │ xo@https://github.com/flying-sheep/xo.git#commit=fbb192efb71dbb17655dafa851f3136a397c6cc5 can't be found in the cache and will be fetched from GitHub
➤ YN0000: └ Completed in 16s 459ms
➤ YN0000: ┌ Fetch step
➤ YN0013: │ yallist@npm:4.0.0 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ yaml@npm:1.10.2 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ yargs-parser@npm:20.2.9 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ yocto-queue@npm:0.1.0 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ yocto-queue@npm:1.0.0 can't be found in the cache and will be fetched from the remote registry
➤ YN0000: └ Completed in 0s 539ms
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0000: └ Completed in 0s 215ms
➤ YN0000: Done with warnings in 17s 278ms |
So you are agreeing that the issue cannot be fixed in Yarn 1, which is what most users are using. 👍 I'll leave further decisions to other maintainers, no more @ pings for me. |
I can’t speak for yarn 1, the maintainers should chime in about that one. What about merging #678? It’ll fix xo’s metadata as far as yarn 2 is concerned and is clearly more correct than what’s currently there. |
Same goes with pnpm: > pnpm add xo -D
Packages: +244
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Progress: resolved 772, reused 730, downloaded 0, added 0, done
devDependencies:
+ xo 0.52.3
WARN Issues with peer dependencies found
.
└─┬ xo 0.52.3
└─┬ eslint-import-resolver-webpack 0.13.2
└── ✕ missing peer webpack@>=1.11.0
Peer dependencies that should be installed:
webpack@>=1.11.0 but #678 does not fix the issue. Adding > pnpm add 'xo@https://github.com/flying-sheep/xo.git#webpack-peer-dep' -D
Packages: +257
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Progress: resolved 785, reused 742, downloaded 1, added 3, done
devDependencies:
+ xo 0.51.0
WARN Issues with peer dependencies found
.
└─┬ xo 0.51.0
├── ✕ missing peer webpack@>=1.11.0
└─┬ eslint-import-resolver-webpack 0.13.2
└── ✕ missing peer webpack@>=1.11.0
Peer dependencies that should be installed:
webpack@>=1.11.0 On the other hand, pnpm supports a config option for ignoring specific peer dependencies, so the issue is not much a problem as yarn. Maybe it might be a good idea to mention the issue and the workaround on // package.json
{
"pnpm": {
"peerDependencyRules": {
"ignoreMissing": ["webpack"]
}
}
} |
The text was updated successfully, but these errors were encountered: