Yarn warns about peer dependencies even if they are installed #4850
Comments
fathyb
changed the title
|
I'm having similar problems too. I have an dependency This is one of the messages: I tried define in package.json the specific version and don't work. This is my package.json for test: After run yarn: |
|
Happening on nightly version 1.3.2-20171114.1200, the latest right now. |
|
Perhaps a regression? I noticed I started getting these warnings even when the required peer dependencies are explicitly in |
|
I've noticed that even NPM warns about my supposedly "missing" peer dependencies: Really weird. |
|
Any update on this? I am seeing the same: https://stackoverflow.com/questions/48297518/yarn-warning-package-has-unmet-react-peer-dependency Yarn version: 1.3.2 |
|
I encountered this as well using yarn v1.3.2, with an Angular-cli project and RxJS: with So long as rxjs@^5.5.2 finds a match, rxjs@^5.5.0 will also match, so the warning is spurious. I was able to resolve this by setting my package.json file to reference rxjs@^5.5.0. |
|
@BYK is this still needs confirmation? Is there anything can we provide to help you confirm this? |
|
We just had a report of this on the Firebase JS SDK. To reproduce: Will throw two warnings of a missing EDIT: I verified that the installed dependency version does meet the range specified by both of the packages w/ the peer dependencies. |
ghost
mentioned this issue
|
I'm seeing this too, particularly when using |
|
Is there a method of silencing the peer dependency warnings in the meantime while a fix is pending? I'm experiencing the same as #4850 (comment) but when combined with yarn workspaces + line wrapping the verbosity can be quite overwhelming :) |
|
Update on #4850 (comment), as of Yarn 1.6.0 we aren't seeing invalid warnings anymore 🥂 |
|
@spalger is right, I don't get any warnings on my repro with |
|
This doesn't seem to be entirely fixed, could this be re-opened? The issue still occurs with firebase on yarn 1.6, or at least yarn is not compatible with npm in this respect, and I'd like clarity from yarn team on their position. Situation:
Outcome:
Repro: It seems like yarn should consider the full transitive dependency graph before complaining about missing peer dependencies |
|
Yup, can confirm it also happens on non-Firebase libraries in our private npm server using a similar graph ( Using @patrickhulce instructions : $ yarn add @firebase/app
yarn add v1.5.1
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
[4/4] 📃 Building fresh packages...
success Saved lockfile.
success Saved 3 new dependencies.
info Direct dependencies
└─ @firebase/app@0.1.10
info All dependencies
├─ @firebase/app-types@0.1.2
├─ @firebase/app@0.1.10
└─ @firebase/util@0.1.10
✨ Done in 2.35s.
$ yarn list @firebase/app-types
yarn list v1.5.1
warning Filtering by arguments is deprecated. Please use the pattern option instead.
└─ @firebase/app-types@0.1.2
✨ Done in 0.09s.
$ yarn add @firebase/database
yarn add v1.5.1
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
warning "@firebase/database > @firebase/database-types@0.2.0" has unmet peer dependency "@firebase/app-types@^0.1.0".
warning " > @firebase/database@0.2.1" has unmet peer dependency "@firebase/app-types@^0.1.0".
[4/4] 📃 Building fresh packages...
success Saved lockfile.
success Saved 7 new dependencies.
info Direct dependencies
└─ @firebase/database@0.2.1
info All dependencies
├─ @firebase/database-types@0.2.0
├─ @firebase/database@0.2.1
├─ @firebase/logger@0.1.0
├─ faye-websocket@0.11.1
├─ http-parser-js@0.4.11
├─ websocket-driver@0.7.0
└─ websocket-extensions@0.1.3
✨ Done in 1.93s.Unlike what I said in the original post, here it's exclusive to transitive dependencies. It doesn't happen when I updated my reproduction repo to demonstrate the problem using Firebase :
|
There are no guarantees that B ends up at the root of your |
Sure but shouldn't there only be a warning when it's actually impacting my situation? i.e. there really are conflicting versions such that it's a possibility EDIT: for example I'm using |
Totally agree. If it's physically there and it's working through Node.js modules resolution logic then there is no need to warn me about it.
I'd like to rely on current state of node_modules folder structure, and it's up to package manager to determine if something is wrong and my transitive dependency wasn't hoisted the expected way and as the result my semver doesn't match. |
Yarn chooses to be safe than sorry. If something is not set up properly but working by chance, it let's you know about that.
"The expected way" is not a fixed contract so cannot be inferred. If it was, we'd already be using that more efficient way but still warn you due to the reason above. You can read about this more at https://yarnpkg.com/blog/2018/04/18/dependencies-done-right/ if you are interested. I'm closing this ticket as this is not something we can act on or change. |
|
@BYK but with |
|
@patrickhulce We may suppress the warnings when using flat mode. This would still hide the underlying problem tho.` |
|
@BYK I'm running into this same issue. The problem is, it seems theres no way of avoiding the warning if you want to control a version of a package centrally. I.e. I have multiple apps that should all use the same version of react. I want to bring in an internal package which in turn, brings in those core deps. I totally understand from the conversation why the warning is in fact given in this scenario. However, it's already possible for us to use things like webpacks I think another option (perhaps this is an RFC?) would be for a package to be able to declare in its package json or elsewhere -- "hey, I know I should be providing package X, but you can actually find it in here". This could coerce yarns module resolution to make guarantees about its position on the file system. I guess its like At the moment, its seems yarn can't support my use case unless I just ignore the warnings and use tooling like webpack to work around it. Event then, I guess thats not too reliable since I could have issues when resolving a module via node.js not webpack for testing or SSR reasons. |
|
Any update? These warnings are insanely annoying. |
|
I'm also running into an "unmet peer dependency" warning with yarn Here's how to reproduce the warning: Output:
I really want to fix this warning, but not sure how to do that. Related links: |
Do you want to request a feature or report a bug?
A bug.
What is the current behavior?
Yarn warns about missing peer dependencies (in this case React) even if the said dependency is in
package.dependencies.If the current behavior is a bug, please provide the steps to reproduce.
git@github.com:fathyb/yarn-unmet-peer-deps.gitWhat is the expected behavior?
It should not warn about missing peer dependencies.
Please mention your node.js, yarn and operating system version.
v6.11.3v1.2.1,v1.3.2-20171102.1724tested tooI've seen multiple issues with the same subject but not the same reason, here React is not a transitive dependency.
The text was updated successfully, but these errors were encountered: