Yarn incorrectly warns about unmet peer dependencies

[smikula]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
In some cases, yarn will report that a peer dependency is unmet even when that dependency is available (as demonstrated by examining node_modules or running yarn list).

If the current behavior is a bug, please provide the steps to reproduce.
The following is a simplified version of my scenario. I have the following package.json:

{
  "dependencies": {
    "@storybook/addon-actions": "^3.3.6",
    "@storybook/react": "^3.3.6",
    "babel-core": "^6.26.0",
    "react": "*",
    "react-dom": "*"
  }
}

When I run yarn I get the following warning (among others):

warning " > @storybook/[email protected]" has unmet peer dependency "@storybook/addons@^3.3.0".

However, @storybook/addons does get installed at an appropriate version:

>yarn list --pattern @storybook/addons
yarn list v1.4.1
warning package.json: No license field
warning No license field
└─ @storybook/[email protected]
Done in 0.92s.

This makes sense because @storybook/addons is a dependency of @storybook/react.

What is the expected behavior?
No peer dependency warning in this case.

Please mention your node.js, yarn and operating system version.
NodeJS: v8.7.0
Yarn: v1.4.1
OS: Windows 10

[rtm]

In my case, with yarn v1.5.1 (WSL, node 8.9) I get the message

warning " > @angular/[email protected]" has unmet peer dependency "@angular/[email protected]".

even though @angular/compiler is indeed at 5.2.3.

[swrobel]

The most annoying recurring yarn bug...
#4433
#4850
#4969
#4595

[mririgoyen]

Can confirm this is an issue.

yarn v1.5.1
node 8.11.1

[naganowl]

I encountered something similar where I had the a direct dependency (call it bar) depended on a package (baz) which was declared as a dev dependency and peer dependency of bar. However, the semver specification differed between the two (the dependency was ^0.5.0 and the peer dependency was ^0.4.0).

I resolved the issue with a combination of changing the peer dependency semver to >= 0.4.0 and upgrading to yarn 1.6.0 and noticed after various combinations of clearing the cache (via yarn cache clean and installs that the warning message disappeared.

Your mileage may vary, however I hope this information helps!

[BYK]

This makes sense because @storybook/addons is a dependency of @storybook/react

This is not a bug. Yarn is right to complain here since a peer dependency cannot be reliably satisfied by a depenpency's dependency. This relies on hoisting, which is an opportunistic optimization, not a guarantee.

You can read more about this here: https://yarnpkg.com/blog/2018/04/18/dependencies-done-right/

[CelticParser]

Why is this closed? I was just forced into using Yarn (again) on a single project and running a yarn install with ~30 dependencies in the package.json, Yarn throws >80 of these warnings?? I reinstall with NPM and get two???

[kitfit-dave]

I think maybe what people miss reading these (long and numerous) discussions on this particular issue, is what should/could be done to fix the warning. (And who would do it)

As I understand it, if a package A declares a peer dependency B, it then becomes the obligation of anyone (say package C) depending on package A to also take a dependency on package B, so that the peer dependency is resolved.

So, in any circumstances where the warning shows up:

• where "package C" is your code, then you are the creator of your own problems and should take a dep on package B and we are done.
• where "package C" is one of your dependencies, then the problem lies with the C package (it has a dependency on A, and thus should have a dependency on B, but does not) and is really best resolved in that package (C).

A concrete example:

warning "firebase > @firebase/[email protected]" has unmet peer dependency "@firebase/[email protected]".

• @firebase/database has a peer dependency on @firebase/app-types (https://github.com/firebase/firebase-js-sdk/blob/master/packages/database/package.json)
• therefore anyone depending on @firebase/database needs to take a dep on @firebase/app-types also
• as indicated, firebase has a dep on @firebase/database and should also have a dep on @firebase/app-types, but does not (https://github.com/firebase/firebase-js-sdk/blob/master/packages/firebase/package.json)
• it does though have a dep on @firebase/app, which in turn does depend on @firebase/app-types - but this is not good enough (hoisting not guaranteed etc etc) (https://github.com/firebase/firebase-js-sdk/blob/master/packages/app/package.json) - it does allow it to "just work" though, and npm does not care about warning about this same problem.

In this example it seems that the answer is: firebase should depend on @firebase/app-types directly...

The firebase repo already has at least one issue for this: firebase/firebase-js-sdk/issues/541. There they blame yarn, "npm does not do that", but the response here and in other issues against yarn are that this is how yarn works, yarn is not npm, npm is optimistic (if the package is there it's okay, no warning) but yarn is playing it safe. It seems like the only thing to do is to try to get those other package maintainers to accept the reality of how yarn works and please add those dependencies...

This seems like the correct course of action to me... And I'm pretty sure it's been explained multiple times (when you know what to look for...) I'm not certain why there is so much friction to adding the dep... it is literally there on node_modules anyway and works due to hoisting, but the philosophy of yarn is that this must be warned about. Also, I guess it is just a warning and can be ignored, but some of us are in the "warnings are like broken windows" school of thought.

[1v]

it does though have a dep on @firebase/app, which in turn does depend on @firebase/app-types - but this is not good enough (hoisting not guaranteed etc etc)

@kitfit-dave Why not?

[craigphicks]

For what it's worth, in a monorepo, at monorepo top level,

yarn add <pkgname> -W

will add the package at the top level and the warning(s) in question will stop.
That's not saying it is the best strategy, but it is a strategy.

[josemigallas]

To anybody finding @kitfit-dave 's comment contradictory (regarding the package.json) I think it's because they point to master. If I understand correctly, back when he wrote it, the dependency he talks about was under peerDependencies whereas now it is under devDependencies. Other than that the comment is perfect. Kudos!!!