Yarn: Yarn warns about peer dependencies even if they are installed

[fathyb]

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.

• Clone [email protected]:fathyb/yarn-unmet-peer-deps.git
• Run yarn
• You should see this :

warning " > [email protected]" has unmet peer dependency "react@^15.3.0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "react-dom@^15.3.0 || ^16.0.0".
warning "material-ui > [email protected]" has unmet peer dependency "react@^15.3.0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "react@>=0.13".
warning "material-ui > [email protected]" has unmet peer dependency "[email protected] || ^15.0.0 || ^16.0.0".
warning "material-ui > [email protected]" has unmet peer dependency "[email protected] || ^15.0.0 || ^16.0.0".
warning "material-ui > [email protected]" has unmet peer dependency "react@^15.3.0 || ^16.0.0".
warning "material-ui > [email protected]" has unmet peer dependency "react@>=15.0.0".
warning "material-ui > [email protected]" has unmet peer dependency "react-dom@>=15.0.0".
warning "material-ui > [email protected]" has unmet peer dependency "react@^0.14.0 || ^15.0.0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "react@^15.3.0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "react-dom@^15.3.0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "react@^0.13.0 || ^0.14.0 || ^15.0.0 || ^16.0.0".
warning "react-hot-loader > [email protected]" has unmet peer dependency "react@^0.14.0 || ^15.0.0 || ^16.0.0-beta || ^16.0.0".
warning "react-hot-loader > [email protected]" has unmet peer dependency "react-dom@^0.14.0 || ^15.0.0 || ^16.0.0-beta || ^16.0.0".

What is the expected behavior?
It should not warn about missing peer dependencies.

Please mention your node.js, yarn and operating system version.

• node v6.11.3
• Yarn v1.2.1, v1.3.2-20171102.1724 tested too
• macOS 10.13.1

I've seen multiple issues with the same subject but not the same reason, here React is not a transitive dependency.

[hersonls]

I'm having similar problems too. I have an dependency angular/compiler-cli@^4.4.0 and [email protected]. So gulp-ngc has "@angular/compiler-cli": ">=2.4.1" and yarn installs version 5.0.0 ignoring my version ^4.4.0 of angular/compiler-cli causing problems between versions.

This is one of the messages:
warning "gulp-ngc > @angular/[email protected]" has incorrect peer dependency "@angular/[email protected]".

I tried define in package.json the specific version and don't work. This is my package.json for test:

{
  "dependencies": {
    "@angular/compiler-cli": "<5.0.0",
    "gulp-ngc": "^0.3.2"
  }
}

After run yarn:

$ yarn
yarn install v1.3.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] 🔍  Resolving packages...
warning gulp-ngc > gulp > vinyl-fs > glob-stream > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning gulp-ngc > gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning gulp-ngc > gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected]: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " > @angular/[email protected]" has unmet peer dependency "typescript@^2.0.2".
warning " > @angular/[email protected]" has unmet peer dependency "@angular/[email protected]".
warning " > @angular/[email protected]" has unmet peer dependency "@angular/[email protected]".
warning "@angular/compiler-cli > @angular/[email protected]" has unmet peer dependency "typescript@^2.1.5".
warning "@angular/compiler-cli > @angular/tsc-wrapped > [email protected]" has unmet peer dependency "typescript@^2.1.0".
warning "gulp-ngc > @angular/[email protected]" has unmet peer dependency "typescript@>=2.4.2 <2.5".
warning "gulp-ngc > @angular/[email protected]" has unmet peer dependency "@angular/[email protected]".
warning "gulp-ngc > @angular/compiler-cli > [email protected]" has unmet peer dependency "[email protected]".
[4/4] 📃  Building fresh packages...
success Saved lockfile.
✨  Done in 6.34s.

[BYK]

@hersonls I think yours is a different issue so I recommend filing a new issue with concrete reproduction steps as @fathyb did.

@fathyb thanks for the report with the repro repo. I think this is related to my recent work around peer dependencies so I'll see what is wrong here.

[leodutra]

Happening on nightly version 1.3.2-20171114.1200, the latest right now.

[razor-x]

Perhaps a regression? I noticed I started getting these warnings even when the required peer dependencies are explicitly in package.json. In the same project, npm 5 does not give the warnings.

[jedwards1211]

I've noticed that even NPM warns about my supposedly "missing" peer dependencies:

$ npm ls @jcoreio/sir-plotalot
@pasonpower/[email protected] /Users/andy/pason-power
├─┬ UNMET DEPENDENCY @jcoreio/[email protected]
│ └── UNMET DEPENDENCY @jcoreio/[email protected] 
└── UNMET DEPENDENCY @jcoreio/[email protected] 

npm ERR! missing: @jcoreio/[email protected], required by @pasonpower/[email protected]
npm ERR! missing: @jcoreio/[email protected], required by @pasonpower/[email protected]
npm ERR! missing: @jcoreio/[email protected], required by @jcoreio/[email protected]
andy@Andys-MBP-2:pason-power (package-updates) $ node -p 'require("@jcoreio/sir-plotalot/package.json").version'
3.1.3

Really weird.

[nickspiel]

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

[asgallant]

I encountered this as well using yarn v1.3.2, with an Angular-cli project and RxJS:

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

with "rxjs": "^5.5.2" in my package.json file. [email protected] was installed.

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.

[pbarbiero]

@byk is this still needs confirmation? Is there anything can we provide to help you confirm this?

[jshcrowthe]

We just had a report of this on the Firebase JS SDK. To reproduce:

yarn add @firebase/app @firebase/database

Will throw two warnings of a missing @firebase/app-types package (a dependency of @firebase/app).

_EDIT: I verified that the installed dependency version does meet the range specified by both of the packages w/ the peer dependencies._

[spalger]

I'm seeing this too, particularly when using link: to pull in packages. I'm trying to create an isolated reproduction but can't figure out what the minimum requirement is...

Installing dependencies in [kibana]:

$ node ./preinstall_check
[1/5] 🔍  Validating package.json...
[2/5] 🔍  Resolving packages...
[3/5] 🚚  Fetching packages...
[4/5] 🔗  Linking dependencies...
warning " > [email protected]" has unmet peer dependency "react@>=0.14.2".
warning " > [email protected]" has unmet peer dependency "react@^16.0.0".
warning " > [email protected]" has unmet peer dependency "react@^0.14.0 || ^15.0.0".
warning " > [email protected]" has incorrect peer dependency "react-dom@^0.14.0 || ^15.0.0".
warning "react-grid-layout > [email protected]" has unmet peer dependency "[email protected] || 15.x || 16.x".
warning " > [email protected]" has unmet peer dependency "react@^15.0.0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "react@^15.0.0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "react@^0.14.0 || ^15.0.0-0 || ^16.0.0-0".
warning " > [email protected]" has unmet peer dependency "react@>=15".
warning " > [email protected]" has unmet peer dependency "react@>=15".
warning " > [email protected]" has unmet peer dependency "react@^0.14.9 || ^15.3.0 || ^16.0.0-rc || ^16.0".
warning "react-select > [email protected]" has unmet peer dependency "react@^0.14.9 || ^15.3.0 || ^16.0.0-rc || ^16.0".
warning " > [email protected]" has unmet peer dependency "prop-types@^15.0.0-0".
warning " > [email protected]" has unmet peer dependency "react@^0.14.0 || ^15.0.0-0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "prop-types@^15.3.0".
warning " > [email protected]" has unmet peer dependency "react@^15.3.0 || ^16.0.0".
warning " > [email protected]" has unmet peer dependency "react@^16.0.0-0".
warning "enzyme-adapter-react-16 > [email protected]" has unmet peer dependency "[email protected] || 0.14.x || ^15.0.0-0 || ^16.0.0-0".
warning "enzyme-adapter-react-16 > [email protected]" has unmet peer dependency "react@^16.0.0".
warning "enzyme-adapter-react-16 > [email protected]" has unmet peer dependency "react@^16.0.0".
[5/5] 📃  Building fresh packages...

[patrickhulce]

Is there a method of silencing the peer dependency warnings in the meantime while a fix is pending? I'm experiencing the same as https://github.com/yarnpkg/yarn/issues/4850#issuecomment-369992761 but when combined with yarn workspaces + line wrapping the verbosity can be quite overwhelming :)

[spalger]

Update on https://github.com/yarnpkg/yarn/issues/4850#issuecomment-371985515, as of Yarn 1.6.0 we aren't seeing invalid warnings anymore 🥂

[fathyb]

@spalger is right, I don't get any warnings on my repro with v1.5.1. I'm closing this, time to chase real missing peer-dependencies 😅

[patrickhulce]

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:

• Your app directly depends on modules A and C
• Module A directly depends on module B
• Module C has peer dependency on module B

Outcome:

• Yarn throws warnings into the console about peer dependency B being unmet for module C, NPM does not.

Repro:
Compare yarn add @firebase/app @firebase/database and npm install --save @firebase/app @firebase/database

It seems like yarn should consider the full transitive dependency graph before complaining about missing peer dependencies

[fathyb]

Yup, can confirm it also happens on non-Firebase libraries in our private npm server using a similar graph (C is a peerDep of B and a dep of A, getting warnings about C when installing A and B). There is no warnings when npm is used and the semver ranges are respected.

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/[email protected]
info All dependencies
├─ @firebase/[email protected]
├─ @firebase/[email protected]
└─ @firebase/[email protected]
✨  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/[email protected]
✨  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/[email protected]" has unmet peer dependency "@firebase/app-types@^0.1.0".
warning " > @firebase/[email protected]" 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/[email protected]
info All dependencies
├─ @firebase/[email protected]
├─ @firebase/[email protected]
├─ @firebase/[email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
└─ [email protected]
✨  Done in 1.93s.

Unlike what I said in the original post, here it's exclusive to transitive dependencies. It doesn't happen when @firebase/app-types is installed on the root package.

I updated my reproduction repo to demonstrate the problem using Firebase :

• Clone https://github.com/fathyb/yarn-unmet-peer-deps
• Checkout the transitive branch
• Run yarn
• Expected output :

yarn install v1.5.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " > @firebase/[email protected]" has unmet peer dependency "@firebase/app-types@^0.1.0".
warning "@firebase/database > @firebase/[email protected]" has unmet peer dependency "@firebase/app-types@^0.1.0".
[4/4] 📃  Building fresh packages...
✨  Done in 0.40s.

[Hypnosphi]

• Your app directly depends on modules A and C
• Module A directly depends on module B
• Module C has peer dependency on module B

There are no guarantees that B ends up at the root of your node_modules not in node_modules/A/node_modules. In the latter case it will be unavailable for C. Hoisting is an optimization not a contract, you can't rely on it.

[patrickhulce]

There are no guarantees that B ends up at the root of your node_modules not in node_modules/A/node_modules. In the latter case it will be unavailable for C. Hoisting is an optimization not a contract, you can't rely on it.

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 yarn install --flat and this should really never be a problem yet I get warnings anyway everytime I do yarn add unrelated-package

[deepsweet]

shouldn't there only be a warning when it's actually impacting my situation

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.

Hoisting is an optimization not a contract, you can't rely on 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.

[BYK]

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.

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.

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.

"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.

[patrickhulce]

@BYK but with --flat it is a fixed contract, and the result is excessively noisy for no reason. Would you at least be open to a flag that could suppress warnings similar to a loglevel?

[BYK]

@patrickhulce We may suppress the warnings when using flat mode. This would still hide the underlying problem tho.`

[adamscybot]

@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 resolve.alias functionality to say "hey, I want you to look here when you look for react". So I wonder if there should be some option to manually surpress the warning for a given package if the developer feels they have solved the issue with other tooling?

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 yarn install --flat except for a specific pre-defined package. Kind of like a flag to say "install this dep flat no matter what". flatDependencies or something.

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.

[b33son]

Any update? These warnings are insanely annoying.

[ndbroadbent]

I'm also running into an "unmet peer dependency" warning with yarn 1.12.3.

Here's how to reproduce the warning:

mkdir /tmp/yarn-warnings-poc
cd /tmp/yarn-warnings-poc
yarn init --yes
yarn add react-scripts
yarn add less less-loader

Output:

yarn add v1.12.3
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " > [email protected]" has unmet peer dependency "webpack@^2.0.0 || ^3.0.0 || ^4.0.0".

react-scripts@^2.1.1 has a dependency for webpack version 4.19.1, and I don't want to add my own webpack dependency to package.json.

I really want to fix this warning, but not sure how to do that.

Related links:

• https://github.com/FormAPI/craco-less/issues/3
• https://github.com/FormAPI/craco-less/issues/4
• https://stackoverflow.com/questions/53681694/how-can-i-resolve-the-webpack-unmet-peer-dependency-warning-for-my-create-reac