[Bug?]: Yarn change the peer dependencies on his own.

[Pnlvfx]

Self-service

• I'd be willing to implement a fix

Describe the bug

"packageManager": "yarn@4.4.1+sha512.f825273d0689cc9ead3259c14998037662f1dcd06912637b21a450e8da7cfeb4b1965bbee73d16927baa1201054126bc385c6f43ff4aa705c8631d26e12460f1"

Installed through corepack

Let's say a library which has 2 peer dependencies,
you do

yarn add -P coraline@https://github.com/Pnlvfx/coraline.git

then yarn will not install it but just add it on the peer dependencies as:

"peerDependencies": {
"coraline": "https://github.com/Pnlvfx/coraline.git"
},

So after that you have to add it on the development dependencies too.

so you do

yarn add -D coraline@https://github.com/Pnlvfx/coraline.git

After doing that the peer dependencies will automatically switch to:

"peerDependencies": {
"coraline": "*"
},

Which of course when you try to install the main library that will try to install the peer, yarn will not find it as it is only on github and not on npm.
So how can yarn find the repo url from just a * character?
The same thing happens with any other peer dependencies that will be automatically converted to "*"

I don't know if it's expected, already the fact that you have to add it in both dev and peer seems to be avoidable for me.
Npm does install them and I don't find the utility of this, but maybe there is.

However great work, sorry for the report, I'm switching back to npm for now, as I'm not able to find a workaround if not changing it manually everytime.

To reproduce

none

Environment

yarn dlx -q envinfo --preset jest

  System:
    OS: macOS 14.6.1
    CPU: (8) x64 Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
  Binaries:
    Node: 22.7.0 - /private/var/folders/jf/sjh3dgcs1337tv31_17wsyxh0000gn/T/xfs-58355ed6/node
    Yarn: 4.4.1 - /private/var/folders/jf/sjh3dgcs1337tv31_17wsyxh0000gn/T/xfs-58355ed6/yarn
    npm: 10.8.2 - /usr/local/opt/node@21/bin/npm

Additional context

No response

[Pnlvfx]

Screen.Recording.2024-08-28.at.18.14.22.mov

[arcanis]

yarn add -P coraline@https://github.com/Pnlvfx/coraline.git

then yarn will not install it but just add it on the peer dependencies as:

"peerDependencies": { "coraline": "https://github.com/Pnlvfx/coraline.git" },

It should actually throw an error - a git repository isn't a valid peer dependencies. Peer dependencies can only specify the version of the package they accept, not their provenance. As a result, Yarn later rewrites it into * as a fallback.

[ReDrUm]

As a result, Yarn later rewrites it into * as a fallback.

Somewhat unrelated to the original issue (faux pas), but i'm curious why Yarn 4 is removing an NPM alias and replacing with *.

Yarn 3 supported the alias, but Yarn 4 removes it, citing Invalid dependency range.

We use the alias to aid incremental upgrades of third party libs within a monorepo, and the packages are published, so * doesn't have the desired effect outside the monorepo.

Why does Yarn 4 consider it invalid? Of note, we have the same alias defined as a devDependency in the root package.json.

"peerDependencies": {
-	"react-intl-next": "npm:react-intl@^6.5.0"
+	"react-intl-next": "*"
},

[clemyan]

Yarn does not enforce provenance of peer dependencies. (Neither does npm, not sure about pnpm). You cannot specify where a package comes from, only that the parent can resolve the name and it resolves to a package whose version satisfies a semver range.

As such, for Yarn, the only valid peer dependency ranges are semver and workspace: ranges. Anything else is ignored.

[yarnbot]

Hi! 👋

It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.