Workspaces complain about missing hoisted peer dependencies #4743

jquense · 2017-10-19T15:26:48Z

What is the current behavior?

peer deps that are hoisted to the repo root are seen as missing by each workspace

If the current behavior is a bug, please provide the steps to reproduce.

Add two workspaces with a Peer dependency and dev dependency on react (or anything in npm). Running yarn results in "[Workspaces package] has unmet peer dependency" warning

You can try it out with: https://github.com/jquense/react-widgets and would see complaints about react, react-dom, moment, and globalize being missing.

What is the expected behavior?

It not to warn

Please mention your node.js, yarn and operating system version.
Yarn 1.2.0, node 8.5 and Mac Sierra

The text was updated successfully, but these errors were encountered:

BYK · 2017-10-19T17:13:36Z

There was a fix in 1.2.1 which may affect the behavior around this: #4687

Would you like to give it a try?

jquense · 2017-10-19T17:20:28Z

Aww I was hoping that was it, but i'm still seeing the warnings on 1.2.1 (just checked)

likeavirgil · 2017-10-25T06:37:52Z

Same here with 1.2.1. (Linux 4.10.0-37-generic / Node 8.1.4)

warning "[email protected]" has unmet peer dependency "react@^0.14.0 || ^15.0.0-0 || ^16.0.0-0".

"dependencies": {
  ...
  "react": "15.5.4",
  "react-redux": "5.0.6"
  ...
}

gandazgul · 2017-10-30T15:45:59Z

Yes, I can confirm this too with yarn 1.2.1 as well as nightly. With workspaces enabled I get peer dep warnings for the workspace aggregator that should be met by dev deps. And I get warning for all hoisted deps in each workspace.

I'll try and look into this issue and see what I can find.

jpickwell · 2017-11-03T15:11:47Z

I'm also seeing this with the following warnings:

warning " > @rails/[email protected]" has unmet peer dependency "coffeescript@>= 1.12.7 || >= 2.x".
warning "@rails/webpacker > [email protected]" has unmet peer dependency "coffeescript@>= 1.8.x".
warning "@rails/webpacker > [email protected]" has unmet peer dependency "caniuse-lite@^1.0.30000697".
warning " > [email protected]" has unmet peer dependency "css-loader@*".

The coffeescript warnings are legitimate, but caniuse-lite and css-loader are installed and meet the version requirements.

Node 8.2.1, Yarn 1.3.2 (Homebrew), macOS 10.12

blackxored · 2017-11-09T19:58:27Z

Same issue here. In addition, it seems like it fails to install one of the modules that it's complaining about.

jonathancopperstone · 2017-11-15T16:57:10Z

Experiencing the same issue..

node_modules/
  - react (15.6.2)
  - react-transition-group (2.2.1)

Where react-transition-group defines react as a peer dependency:

"peerDependencies": {
    "react": ">=15.0.0"
}

but complains with [email protected]" has unmet peer dependency "react@>=15.0.0"

rally25rs · 2017-11-16T16:30:16Z

Some of these issues seem to be fixed, but some still exist.

For example the case from @likeavirgil no longer throw a warning in 1.3.2.:

"dependencies": {
  "react": "15.5.4",
  "react-redux": "5.0.6"
}

Here is a minimal example of one that still doesn't work in 1.3.2

~/Projects/yarn-test : cat package.json
{
  "name": "yarn-test",
  "version": "0.0.1",
  "description": "yarn-test",
  "author": "",
  "license": "NONE",
  "devDependencies": {
  },
  "dependencies": {
    "@rails/webpacker": "3.0.2",
    "coffeescript": "~1.12.0",
    "caniuse-lite": "^1.0.0"
  }
}

~/Projects/yarn-test : ~/Projects/yarn/bin/yarn
yarn install v1.3.2
warning package.json: License should be a valid SPDX license expression
info No lockfile found.
warning [email protected]: License should be a valid SPDX license expression
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning "@rails/webpacker > [email protected]" has unmet peer dependency "caniuse-lite@^1.0.30000697".
[4/4] 📃  Building fresh packages...
success Saved lockfile.
✨  Done in 8.85s.

~/Projects/yarn-test : grep version node_modules/caniuse-lite/package.json
  "version": "1.0.30000765",
  "description": "A smaller version of caniuse-db, with only the essentials!",

This seems to be because the code is checking the un-hoisted dependency tree to see if a peerDep is resolved up the trunk, but it fails to check the actual root package.json file's direct dependencies.

growthcode · 2017-11-26T02:12:42Z

I was able to fix it after some guessing... I'm new to yarn but fixed 4 warnings including the one here.

[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning "@rails/webpacker > [email protected]" has unmet peer dependency "caniuse-lite@^1.0.30000697".
warning " > [email protected]" has unmet peer dependency "css-loader@*".
warning " > [email protected]" has unmet peer dependency "eslint-plugin-standard@>=3.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^2.2.0 || ^3.0.0".
warning "webpack-dev-server > [email protected]" has unmet peer dependency "webpack@^1.0.0 || ^2.0.0 || ^3.0.0".
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
✨  Done in 5.03s.

I'll list my fixes individually so you can see the pattern:

# 1) @rails/webpacker > [email protected]" has unmet peer dependency "caniuse-lite@^1.0.30000697".
bin/yarn add caniuse-lite@^1.0.30000697

# 2) warning " > [email protected]" has unmet peer dependency "css-loader@*".
bin/yarn upgrade css-loader -p

# 3) warning " > [email protected]" has unmet peer dependency "webpack@^2.2.0 || ^3.0.0".
# 4) warning "webpack-dev-server > [email protected]" has unmet peer dependency "webpack@^1.0.0 || ^2.0.0 || ^3.0.0".
yarn upgrade webpack@^2.2.0 || ^3.0.0

Be sure to use the appropriate dependency flags referenced in the warning, more info here:
https://yarnpkg.com/lang/en/docs/managing-dependencies/

After I ran those lines... I got what I spent hours trying to achieve... 0 warnings 😄 :

⇒  yarn install --check-files
yarn install v1.3.2
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 7.45s.

rtm · 2017-11-27T08:21:47Z

@growthcode But the point is you shouldn't need to do that.

jonathancopperstone · 2017-11-29T13:12:00Z

I'm currently working on a fix for this, but can't assign it to myself. Is anyone able to grant me access to do so?

markmcdermid · 2017-12-11T10:54:16Z

@rally25rs How's this fix going? :)

rally25rs · 2017-12-11T14:34:18Z

@johnnycopperstone ⬆️ (I can lend a hand with this if you haven't made much progress, just let me know.)

gandazgul · 2017-12-11T19:24:04Z

I'm happy to give some pointers, I tried debugging this and hit a wall. The problem is definitively related to either how yarn builds the tree on a workspace or how the validator works against a workspace tree.

For a simple example of a peerDep not being satisfied by a devDep I see the devDep added to the workspace tree fine, but then when the validator runs it finds that the dep is too far removed from the one with the peer declaration and so it warns (as it should). I don't know enough about how yarn structures the tree and I haven't had time to delve deeper. :(

rally25rs · 2017-12-11T19:35:34Z

Alright, after much trial and error, I finally came up with a unit test that reproduces this. It calls for a dependency structure like:

package.json
|-dep- b
|  |-peerDep- caniuse-lite
|  |-dep- caniuse-api
|     |-dep- caniuse-lite
|-dep- caniuse-lite

so the peer dep (caniuse-lite) exists at both a shallower and deeper level in the hierarchy relative to where it was requested.

I suspect that when Yarn goes to check for the peerDep, it finds it at b > caniuse-api > caniuse-lite then throws up it's hands and says "nope, that can't be used to satisfy b > caniuse-lite" then stops checking (and never finds the one at the root level that would satisfy the peerDep).

But I have a failing unit test, so that's step 1... 😃

…pkg#4743 Added a failing unit test to reproduce issue yarnpkg#4743. It seems that if a peerDep exists deeper in the dep tree than where it is included, yarn will output a earning, even if that peerDep is satisfied by the same library included shallower in the tree, or at the root level.

…multiple levels. A missing peerDep warning was being issued if the exact same pattern was a deep transitive dep and a direct dep. This was due to only the first request for a pattern being added to the list of requests that peerDep was checking. Now all references are tracked. Also fixed a logic error in Warn where a dep would be reported multiple times. yarnpkg#4743

rally25rs · 2017-12-14T15:29:18Z

@johnnycopperstone I know you were working on this, but I went ahead and put together a PR ⬆️ If you could try it out and verify that it works, that would be great!

Zerim · 2017-12-14T22:38:28Z

Adding a reference to this issue: #4503 since it seems related. Generally hoisting seems to cause problems w/ both peer dependencies as well as a host of other tooling that expects scripts, types, etc. to be in the individual workspaces.

rtm · 2017-12-15T04:02:20Z

Let's keep these issues separate. 1. Yes, hoisting should work as advertised. This includes NOT giving spurious errors/warnings about unmet peer dependencies. 2. Scripts--assuming you mean things going into `.bin`--are already always placed where expected. I am not aware of any bugs raised against this. No, adding packages at the top level should **not** add their scripts to sub-workspaces. That violates basic rules of expectations. 3. "Types"--assuming you mean things like `*.d.ts` files--pretty much work as they should in the default case. In other words, TypeScript will consume types from all `@type` directories up the npm search path, so it doesn't matter if `@types/*` is hoisted. However, there are some problems when types are being explicitly called for in the `typeRoots` property of `tsconfig.json`, which may require doing things like `[../@types', '../../@types`]` and so on. This is an issue which needs to be addressed by TS, unless there's some work-around that I'm not aware of. 4. Packages which assume that they live in a particular place relative to something else are poorly designed and should be fixed. Any kind of hoisting whitelists or hoisting blacklists are merely bandaids for this kind of poor behavior. For instance, at least in the past some Angular tools insisted that some Angular packages be in the very directory they were being run from. This violates the basic notion of npm search paths and should be dealt with by fixing the tool. Bob

…

On Fri, Dec 15, 2017 at 4:08 AM, Brandon Ramirez ***@***.***> wrote: Adding a reference to this issue: #4503 <#4503> since it seems related. Generally hoisting seems to cause problems w/ both peer dependencies as well as a host of other tooling that expects scripts, types, etc. to be in the individual workspaces. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4743 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfR00VacEjEB5b8hNbyh188vZqvYGdks5tAaN5gaJpZM4P_aZh> .

jonathancopperstone · 2017-12-19T11:42:28Z

Awesome @rally25rs. I didn't get very far, wasn't sure how I could compare the patterns for each dependency with the actual hoisted tree (given it's hoisted as a flat tree with paths as far as I understand). I'll take a look at the PR and test this on our code base today.

…t root level. (#5088) * test(resolution): Added a (failing) unit test to reproduce issue #4743 Added a failing unit test to reproduce issue #4743. It seems that if a peerDep exists deeper in the dep tree than where it is included, yarn will output a earning, even if that peerDep is satisfied by the same library included shallower in the tree, or at the root level. * fix(resolution): No longer warn for mising peerDep when it exists at multiple levels. A missing peerDep warning was being issued if the exact same pattern was a deep transitive dep and a direct dep. This was due to only the first request for a pattern being added to the list of requests that peerDep was checking. Now all references are tracked. Also fixed a logic error in Warn where a dep would be reported multiple times. #4743 * fix(tests): Remove snapshot test of "yarn why" due to different output local vs ci. Now assert with Remove snapshot test of "yarn why" due to different output local vs ci. Now assert with actual object value comparison.

Cedric1994 · 2018-04-10T09:12:54Z

I encoutered this issue using Yarn 1.3.2. The probleme was resolve when I upgrade to the last current version of Yarn (1.5.1)

nevir · 2018-11-15T17:28:34Z

I'm encountering this on yarn 1.12.1 :(

PaulRBerg · 2019-04-21T20:11:55Z

Same for yarn 1.15.2!

lkiarest · 2019-06-18T06:05:27Z

Same for yarn 1.16.0!

sepehr · 2019-09-05T23:05:54Z

Annnd same for 1.17.3.

KatieMFritz · 2020-04-07T20:22:33Z

I'm encountering this on 1.22.4

ttt43ttt · 2021-09-15T10:07:34Z

Same for yarn 1.22.5!

rally25rs mentioned this issue Nov 28, 2017

peerDependencies installed but still shows warning #5007

Closed

rally25rs self-assigned this Nov 29, 2017

rally25rs mentioned this issue Dec 4, 2017

Incorrect unmet peer dependency warning #4969

Closed

rally25rs mentioned this issue Dec 13, 2017

fix(resolution) Eliminate "missing peerDep" warning when dep exists at root level. #5088

Merged

Zerim mentioned this issue Dec 14, 2017

Workspaces - Is it possible to exclude some node_modules from beeing hoisted to the root node_modules folder? #3882

Open

arcanis closed this as completed in #5088 Jan 15, 2018

kuncevic mentioned this issue Feb 15, 2018

compiler-cli 5.2.3 - wrong unmet peer dependency for typescript angular/angular#21997

Closed

soorajvnair mentioned this issue Feb 20, 2018

Update to React 16 and remove prop-types from peer dependency bentatum/better-react-spinkit#21

Open

Glavin001 mentioned this issue Mar 10, 2018

Unable to publish "peer dep missing" Unibeautify/vscode#11

Closed

panjiesw mentioned this issue Jul 30, 2018

Unmet peer deps with workspaces #5810

Closed

oxc mentioned this issue May 4, 2020

[update]Update kotlin-wrappers -> pre.104 subroh0508/kotlin-material-ui#23

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Workspaces complain about missing hoisted peer dependencies #4743

Workspaces complain about missing hoisted peer dependencies #4743

jquense commented Oct 19, 2017

BYK commented Oct 19, 2017

jquense commented Oct 19, 2017

likeavirgil commented Oct 25, 2017 •

edited

Loading

gandazgul commented Oct 30, 2017

jpickwell commented Nov 3, 2017 •

edited

Loading

blackxored commented Nov 9, 2017

jonathancopperstone commented Nov 15, 2017

rally25rs commented Nov 16, 2017

growthcode commented Nov 26, 2017

rtm commented Nov 27, 2017

jonathancopperstone commented Nov 29, 2017

markmcdermid commented Dec 11, 2017

rally25rs commented Dec 11, 2017 •

edited

Loading

gandazgul commented Dec 11, 2017

rally25rs commented Dec 11, 2017

rally25rs commented Dec 14, 2017

Zerim commented Dec 14, 2017

rtm commented Dec 15, 2017 via email

jonathancopperstone commented Dec 19, 2017 •

edited

Loading

Cedric1994 commented Apr 10, 2018

nevir commented Nov 15, 2018

PaulRBerg commented Apr 21, 2019

lkiarest commented Jun 18, 2019

sepehr commented Sep 5, 2019

KatieMFritz commented Apr 7, 2020

ttt43ttt commented Sep 15, 2021

Workspaces complain about missing hoisted peer dependencies #4743

Workspaces complain about missing hoisted peer dependencies #4743

Comments

jquense commented Oct 19, 2017

BYK commented Oct 19, 2017

jquense commented Oct 19, 2017

likeavirgil commented Oct 25, 2017 • edited Loading

gandazgul commented Oct 30, 2017

jpickwell commented Nov 3, 2017 • edited Loading

blackxored commented Nov 9, 2017

jonathancopperstone commented Nov 15, 2017

rally25rs commented Nov 16, 2017

growthcode commented Nov 26, 2017

rtm commented Nov 27, 2017

jonathancopperstone commented Nov 29, 2017

markmcdermid commented Dec 11, 2017

rally25rs commented Dec 11, 2017 • edited Loading

gandazgul commented Dec 11, 2017

rally25rs commented Dec 11, 2017

rally25rs commented Dec 14, 2017

Zerim commented Dec 14, 2017

rtm commented Dec 15, 2017 via email

jonathancopperstone commented Dec 19, 2017 • edited Loading

Cedric1994 commented Apr 10, 2018

nevir commented Nov 15, 2018

PaulRBerg commented Apr 21, 2019

lkiarest commented Jun 18, 2019

sepehr commented Sep 5, 2019

KatieMFritz commented Apr 7, 2020

ttt43ttt commented Sep 15, 2021

likeavirgil commented Oct 25, 2017 •

edited

Loading

jpickwell commented Nov 3, 2017 •

edited

Loading

rally25rs commented Dec 11, 2017 •

edited

Loading

jonathancopperstone commented Dec 19, 2017 •

edited

Loading