unmet peer dependency warnings using yarn

[rgant]

Version

3.0.0-beta.9

Reproduction link

https://github.com/rgant/vue-helloworld-test-fails

Steps to reproduce

Run yarn add something. Also for remove.

What is expected?

No warnings

What is actually happening?

unmet peer dependency warnings.

---

euphorbus:~/Programming/vue (master)$ yarn remove babel-preset-env --dev
yarn remove v1.6.0
(node:10184) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
[1/2] 🗑  Removing module babel-preset-env...
[2/2] 📃  Regenerating lockfile and installing missing dependencies...
warning "@vue/cli-plugin-babel > babel-loader@8.0.0-beta.2" has unmet peer dependency "webpack@>=2".
warning "@vue/cli-plugin-e2e-cypress > eslint-plugin-cypress@2.0.1" has unmet peer dependency "eslint@>= 3.2.1".
warning "@vue/cli-plugin-pwa > workbox-webpack-plugin@3.1.0" has unmet peer dependency "webpack@^2.0.0 || ^3.0.0 || ^4.0.0".
warning "@vue/cli-plugin-typescript > fork-ts-checker-webpack-plugin@0.4.1" has unmet peer dependency "webpack@^2.3.0 || ^3.0.0 || ^4.0.0".
warning " > babel-core@7.0.0-bridge.0" has unmet peer dependency "@babel/core@^7.0.0-0".
warning " > sass-loader@6.0.7" has unmet peer dependency "webpack@^2.0.0 || ^3.0.0 || ^4.0.0".
warning " > ts-jest@22.4.4" has unmet peer dependency "jest@^22.4.0 || ^22.5.0-alpha.1 || ^23.0.0-alpha.1".
warning " > ts-jest@22.4.4" has unmet peer dependency "typescript@2.x".
success Uninstalled packages.
✨  Done in 6.62s.

[rgant]

Are these safe to ignore or signs of a problem with the cli?

[posva]

yes, safe to ignore

---

Please, next time consider using the forum, the Discord server or StackOverflow for questions first. But feel free to come back and open an issue if it turns out to be a bug 🙂

[tvkit]

@posva it may not be a bug, but it's definitely an issue since it's preferable not to get in the habit of ignoring warnings. Do have any idea what's causing the pointless warnings so we can hopefully eliminate them?

[jacekkarczmarczyk]

I don't think this issue should be closed, ignoring warning is not an acceptable solution

[posva]

Just to be clear: it's absolutely not okay to ignore warnings in general

the thing is the peer dependency system is flawed in this scenario because we already provide those dependencies as direct dependencies of other packages (like webpack for vue-cli-service). I haven't tried but maybe we could list those internal packages as peerDependencies and it will remove the warning. For example, adding @vue/cli-service (webpack dependency) as a peerDep of @vue/cli-plugin-babel (depends on babel-loader which has a peerDep on webpack)

[jacekkarczmarczyk]

If I understand correctly this might remove the warnings related to vue-cli packages, however there are still other packages that obviously can't add vue-cli as a peerDep, like for example ts-jest or sass-loader metioned in the comment above

[jacekkarczmarczyk]

Not having webpack as a (peer) dependency might be also the cause of this issue: yarnpkg/yarn#6962

[arcanis]

the thing is the peer dependency system is flawed in this scenario because we already provide those dependencies as direct dependencies of other packages (like webpack for vue-cli-service)

Please don't rely on this. A package is only allowed to access what it explicitly lists in its dependencies - anything else is susceptible to break in various and non-predictable ways, depending on the other projects used by your users or the version of their package manager.

Note that you are perfectly allowed to list webpack as regular dependency in every package that uses it - as long as you use the exact same range for all, the package manager will be able to optimize them.

[arcanis]

Also note (I don't think it's the problem here, but it's still relevant) that Yarn supports optional dependencies 🙂

[LinusBorg]

If we add webpack as a direct dependency of your project, then you lose the advantage of having this dependency managed by vue-cli-service. And since by default, you only use webpack through vue-cli-service, it's totally fine to have it only as a dependency of cli-service only in this regard.

Similarly, other core plugins, like the babel plugin, have dependencies like babel-loader, which has a peerDependency for webpack, which is satisfied by @vue/cli-service (the package actually consuming @vue/cli-plugin-babel. It's necessarily satisfied because the babel plugin can't work without the cli-service plugin, and both are tested and released in unison. But npm/yarn have problems picking that up during installation.

But yes, we could add webpack as a dependency to @vue/cli-plugin-babel. It would make dependency management harder for us, but would probably get rid of these warnings.

[arcanis]

But npm/yarn have problems picking that up during installation.

We (Yarn, but also pnpm) very strongly recommend listing peer dependencies at every step of the dependency chain - meaning that if A depends on B and B has a peer dependency on C, then A must also have a peer dependency on C.

But yes, we could add webpack as a dependency to @vue/cli-plugin-babel. It would make dependency management harder for us, but would probably get rid of these warnings.

Yarn v2 will introduce a new feature (constraints) that will make this use case a much better experience for workspace maintainers. Wanna be early adopters? 🙂

[LinusBorg]

@arcanis Sounds cool! But 2.0 is still a long way to go right?

I'll need to open a new issue as an enhancement request to get this sorted out throughout the monorepo meanwhile