I'm confused by the "Some peer dependencies are incorrectly met by your project" message

[snowystinger]

In yarn 4.2.2 this worked. I came across it while trying to update to 4.8.1.

Here's an example showcasing the behaviour ready to be installed locally https://github.com/snowystinger/yarn-peer-test

I'm posting the same structure outline here for reference.

example
| - .yarnrc.yml
|      nodeLinker: node-modules
| - package.json
|    packageManager: "[email protected]"
|    workspaces: ["packages/*"]
|    devDependencies: 
|      "react": "^18.2.0",
|      "react-dom": "^18.2.0"
| - packages
   | - package-a
   |     dependencies: 
   |       package-c: "workspace:^*" 
   |     peerDependencies: 
   |      "react": "^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0-rc.1",
   |      "react-dom": "^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0-rc.1"
   | - package-b
   |     dependencies: 
   |       package-c: "workspace:^*" 
   |     peerDependencies: 
   |      "react": "^18.0.0 || ^19.0.0-rc.1",
   |      "react-dom": "^18.0.0 || ^19.0.0-rc.1"
   | - package-c
   |     peerDependencies: 
   |      "react": "^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0-rc.1",
   |      "react-dom": "^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0-rc.1"

Then I will get the error:

package-a@workspace:packages/package-a doesn't provide react (p3cdcc), requested by package-c

but package-a IS providing the peer, it has its own peer dependency on react

Have I missed something here? Surely I don't need to add a devDependency for every instance of this? if I do that, then I get node_modules installed in every package and I actually end up with multiple copies and different versions of react/react-dom.

[clemyan]

So, at one point, the peer dependency warning system wasn't as rigorous as it is now and would miss stuff that should be reported. A lot of those cases got fixed in 4.3.

One of the cases that got fixed is this:

{
  "name": "@my/package",
  "devDependencies": {
    "@babel/preset-env": "^7.26.9"
  },
  "peerDependencies": {
    "@babel/core": "*"
  }
}

Imagine this is the only workspace of a project. It would "provide" @babel/core to @babel/preset-env via its peer dependency, which would be provided by the parent. But this is a workspace -- it is the root of the dependency tree and thus has no parent. You'd end up with a @babel/preset-env that has no @babel/core provided. That is a problem because, say, if you have scripts that uses @babel/preset-env, it would throw when trying to resolve @babel/core. Before 4.3, the install would succeed silently. Since 4.3, there would be a peer warning.

Even in a monorepo, each workspace is, on its own, the root of a dependency tree. This is true even if it is not the root workspace or if another workspace explicitly declares a dependency on it, because there are situations (e.g. running a script from it) where it is the dependency tree root.

Back to your case, there are a number of things to discuss:

• Yes, each workspace will always be able to resolve react. But that is not because Yarn understands that each workspace needs react, but rather simply due to how node_modules resolution work. Even if a workspace doesn't have react, it will continue to search for n_m directories outside the workspace and eventually end up resolving to the react instance in the root workspace simply by happenstance of how the workspaces are laid out in the filesystem. This makes it a ghost dependency.
• Any node_modules-based installation has some fundamental limitations:
  • For one, regular dependencies do not request package managers to deduplicate instances. In fact, under node_modules, it is quite easy to create cases where the only way to avoid making duplicate instances of the exact same package is to use symlinks and run node without --preserve-symlinks.
  • Peer dependencies do request package managers to deduplicate two package instances in the dependency tree. However, under node_modules, there cases where, without using --preserve-symlinks, it is impossible to enforce that constraint across symlinked dependencies (e.g. workspaces).

It is an unfortunate case of "damned if you do, damned if you don't". If you don't declare the dev dependencies, Yarn will see that package-a won't have a react (and react-dom) to provide to package-c. But if you do declare the dev dependencies, the singleton-ness can't always be enforced under node_modules, and you run the risk of duplicate instances.

---

As far as I understand, if there is a single version of react in the whole project (more precisely, a single reference), then the hoister will always hoist react to a single instance in the project root (as long as the nmHoistingLimits config and installConfig.hoistingLimits manifest field allow it) even if multiple workspaces depend on it. A single reference can be enforced using a resolution.

Unless someone has a better idea, I think this is your best workaround under node_modules.

[snowystinger]

Thanks for the detailed info. I assume this implies that pnp land is free of this somehow?

Wouldn't it be safe to assume that, if a workspace defines a peer that meets the peer declared by its dependencies, then if that peer is covered by the root of the monorepo, it shouldn't need to define the devDependency? The root of a monorepo would essentially be considered as implicitly depending on every package in the workspace. Meaning we could get rid of this statement?

Even in a monorepo, each workspace is, on its own, the root of a dependency tree

I understand the sentiment there, but it seems like for monorepos this rule could be bent a little.

Otherwise, I think what you're suggesting is that every devDep in our monorepo root should become a resolution? (some devDeps would still stick around in duplicate with the resolution for scripts that exist at the root level)
Unless all of those need to move into a "tools" workspace package and there really should be NO dependencies in the workspace root?