Yarn: Can not resolve "peerDependency" in workspace package that is a dependency of another workspace package

[vkatushenok]

Do you want to request a feature or report a bug?
A bug (I guess).

What is the current behavior?
Given following setup:

-> workspace/package.json:
  {
    "workspaces": {
      "packages": [ "packages/*" ],
      "nohoist": [ "**/a" ]
    }
  }
  -> packages/
    -> a/package.json
      {
        "version": "1.0.0",
        "peerDependencies": {
          "x": ">=1.0.0"
        }
      }
    -> b/package.json
      {
        "dependencies": {
          "a": "1.0.0",
          "x": "1.1.0"
        }
      }
    -> c/package.json
      {
        "dependencies": {
          "a": "1.0.0",
          "x": "2.2.0"
        }
      }

The workspace package a fails to find module x, as it gets installed under b and c with relevant versions and is not in module resolution path.
Removing nohoist does not allow to use correct (incompatible) versions of module x.

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

What is the expected behavior?
To be be able resolve peer dependency x of specified versions in b and c (e.g. via nohoist of a workspace package itself).

Please mention your node.js, yarn and operating system version.
Yarn: 1.6.0
Node: 9.11.1
macOS: 10.13.4

[BYK]

This is expected since you haven't defined x as a dependency above a's dependency tree. You can read more about this here: https://yarnpkg.com/blog/2018/04/18/dependencies-done-right/

[vkatushenok]

Based on the following from the post above:

The peerDependencies object guarantees that, for each entry, any package that requires you will be requested to provide a copy of the dependency listed here, ideally matching the version you requested. It also guarantees that you’ll be able to access this dependency through require(), and finally it also guarantees that the return of require() will be exactly the same version & instance than the one your parent would obtain if they were to require() it themselves.

This relationship appears to be broken. As parent does provides the dependency x and it's available in b and c but not in a.

[BYK]

@vkatushenok sorry you think this way. This is how the field is specced out and implemented by both npm and Yarn folks.

Feel free to propose a change or refinement in the RFC repo.

[rovansteen]

@BYK what is the best practice to work around this? Because installing the peer dependency in the root workspace folder will trigger this error.

error An unexpected error occurred: "Running this command will add the dependency to the workspace root rather than workspace itself, which might not be what you want - if you really meant it, make it explicit by running
this command again with the -W flag (or --ignore-workspace-root-check).".

That sounds like this is the wrong approach to fixing this problem.

[vkatushenok]

@BYK I understand your point - npm implements this constraint correctly due to limitations on where direct dependencies can be located in the folder structure.

What I am describing is a scenario that appears to be not covered with yarn introducing workspaces, as it allows to hoist direct dependencies that declare peerDependencies at the level above.

Hence, don't think this is not change in behaviour but rather a bug in how workspaces work.

[ajhyndman]

If someone could take a closer look at this, I'd appreciate it too. I'm running into the same issue that @vkatushenok describes in his initial post.