[Bug?]: peerdependency version being ignored?

[lucas-zimerman]

Self-service

• [ ] I'd be willing to implement a fix

Describe the bug

I am adding this as a bug since the behavior is different from npm. In short, running the bellow command has different behaviors, npm adds @sentry/angular using the version defined on the peerDependency of @sentry/[email protected] where yarn ignores that version number and uses the latest version of the package.

yarn install @sentry/[email protected] @sentry/angular

{
  "packageManager": "[email protected]",
  "dependencies": {
    "@sentry/angular": "^7.12.1",
    "@sentry/capacitor": "0.9.0",
  }
}

npm install @sentry/[email protected] @sentry/angular

{
  "dependencies": {
    "@sentry/angular": "^7.8.1",
    "@sentry/capacitor": "^0.9.0"
  }
}

sentry angular is defined as a peer dependency here: https://github.com/getsentry/sentry-capacitor/blob/0.9.0/package.json#L40

If not a bug, it would be great to know how yarn could behave the same as npm in this case where users type for example yarn add @sentry/capacitor @sentry/angular where @sentry/capacitor has a peer dependency version lower than the latest release of @sentry/angular.

To reproduce

yarn install @sentry/[email protected] @sentry/angular

no need to add additional code, the build will break because the types are incompatible with the latest version of @sentry/angular

// Sherlock reproduction. For instance:
await packageJsonAndInstall({
  dependencies: {
    [`@sentry/capacitor`]: `0.9.0`,
    [`@sentry/angular`]: ``,
  },
});

Environment

Same was reproduced by other users on different machines.

  System:
    OS: Windows 10 10.0.22000
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 18.7.0 - ~\AppData\Local\Temp\xfs-da2809f7\node.CMD
    Yarn: 3.2.3 - ~\AppData\Local\Temp\xfs-da2809f7\yarn.CMD
    npm: 8.19.1 - C:\Program Files\nodejs\npm.CMD

Additional context

No response

[yarnbot]

We couldn't reproduce your issue (all the assertions passed on master).

[RDIL]

I don't think this is a bug... it looks to me like npm is just resolving a different tag or something like that - Yarn just has different (and often better) resolution logic. Plus, if you're using Yarn as a package manager, you shouldn't really mix it with npm since the 2 are completely different and not necessarily compatible with each other.

[lucas-zimerman]

I don't think this is a bug... it looks to me like npm is just resolving a different tag or something like that - Yarn just has different (and often better) resolution logic. Plus, if you're using Yarn as a package manager, you shouldn't really mix it with npm since the 2 are completely different and not necessarily compatible with each other.

In this case it's not being mixed, I just added an example from both package managers with two empty projects to show the end result on which version they chose.

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

[merceyz]

The range declared in the peerDependencies field doesn't influence the resolution result but if it did, Yarn follows the SemVer rules and would use the highest satisfying version.