Yarn: Workspaces complain about missing hoisted peer dependencies

[jquense]

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

[BYK]

There was a fix in 1.2.1 which may affect the behavior around this: https://github.com/yarnpkg/yarn/pull/4687

Would you like to give it a try?

[jquense]

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

[likeavirgil]

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

warning "react-redux@5.0.6" 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]

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]

I'm also seeing this with the following warnings:

warning " > @rails/webpacker@3.0.2" has unmet peer dependency "coffeescript@>= 1.12.7 || >= 2.x".
warning "@rails/webpacker > coffee-loader@0.8.0" has unmet peer dependency "coffeescript@>= 1.8.x".
warning "@rails/webpacker > postcss-cssnext@3.0.2" has unmet peer dependency "caniuse-lite@^1.0.30000697".
warning " > vue-loader@13.3.0" 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]

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

[jonathancopperstone]

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 react-transition-group@2.2.1" has unmet peer dependency "react@>=15.0.0"

[rally25rs]

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 yarn-test@0.0.1: License should be a valid SPDX license expression
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning "@rails/webpacker > postcss-cssnext@3.0.2" 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]

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 > postcss-cssnext@3.0.2" has unmet peer dependency "caniuse-lite@^1.0.30000697".
warning " > vue-loader@13.5.0" has unmet peer dependency "css-loader@*".
warning " > eslint-config-standard@10.2.1" has unmet peer dependency "eslint-plugin-standard@>=3.0.0".
warning " > webpack-dev-server@2.9.4" has unmet peer dependency "webpack@^2.2.0 || ^3.0.0".
warning "webpack-dev-server > webpack-dev-middleware@1.12.1" 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.
└─ eslint-plugin-promise@3.6.0
✨  Done in 5.03s.

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

# 1) @rails/webpacker > postcss-cssnext@3.0.2" has unmet peer dependency "caniuse-lite@^1.0.30000697".
bin/yarn add caniuse-lite@^1.0.30000697

# 2) warning " > vue-loader@13.5.0" has unmet peer dependency "css-loader@*".
bin/yarn upgrade css-loader -p

# 3) warning " > webpack-dev-server@2.9.4" has unmet peer dependency "webpack@^2.2.0 || ^3.0.0".
# 4) warning "webpack-dev-server > webpack-dev-middleware@1.12.1" 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]

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

[jonathancopperstone]

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]

@rally25rs How's this fix going? :)

[rally25rs]

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

[gandazgul]

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]

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

[rally25rs]

@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]

Adding a reference to this issue: https://github.com/yarnpkg/yarn/issues/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]

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 [e-mail]
wrote:

Adding a reference to this issue: #4503
https://github.com/yarnpkg/yarn/issues/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
https://github.com/yarnpkg/yarn/issues/4743#issuecomment-351857827, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABfR00VacEjEB5b8hNbyh188vZqvYGdks5tAaN5gaJpZM4P_aZh
.

[jonathancopperstone]

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.

[Cedric1994]

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]

I'm encountering this on yarn 1.12.1 :(

[PaulRBerg]

Same for yarn 1.15.2!

[lkiarest]

Same for yarn 1.16.0!

[sepehr]

Annnd same for 1.17.3.

[KatieMFritz]

I'm encountering this on 1.22.4