[Bug?]: inter-workspace dependencies are not properly resolved when installing a package from git

[MOZGIII]

Self-service

• I'd be willing to implement a fix

Describe the bug

Yarn doesn't look for the workspace dependency of a dependency installed from git in that workspace, and tries to look for it at the registry instead.

To reproduce

1. Have a workspace (@repo-a/root) in a github repo github.com/user/repo-a.
2. In this workspace, have @repo-a/package-1 and @repo-a/package-2.
3. Have @repo-a/package-1 depend on @repo-a/package-2 with workspace:^.
4. Have a github repo github.com/user/repo-b with a package @repo-b/root.
5. At the @repo-b/root add a dependency to @repo-a/package-1 as "@repo-a/package-1": "git@github.com:user/repo-a.git#workspace=@repo-a/package-1"
6. Observe yarn install fail to resolve @repo-a/package-2 and fail the install @repo-a/package-1 because of it.

Environment

  System:
    OS: macOS 15.1.1
    CPU: (8) arm64 Apple M1
  Binaries:
    Node: 22.13.0 - /private/var/folders/cn/860vwq3j5zv_7_vzbtdfq9h40000gn/T/xfs-4e1f5446/node
    Yarn: 3.8.7 - /private/var/folders/cn/860vwq3j5zv_7_vzbtdfq9h40000gn/T/xfs-4e1f5446/yarn
    npm: 10.9.2 - /opt/homebrew/opt/node@22/bin/npm
    bun: 1.1.8 - ~/.bun/bin/bun

Additional context

This was brought up before but was closed without a solution due to being stale - #4545. The problem still exists and didn't go away.

[shinebayar-g]

Yup faced the same problem, gave up using workspace:^ syntax. If you still want to keep using workspace: syntax, you can work around it by making it a peer dependency and install it by yourself on the client side.

[MOZGIII]

A work around that we've adopted is using resolutions to specify all git dependencies and their recursive dependencies. This works because we provide resolution for in-workspace dependencies of the git repo packages, thus making them resolved.
It should, ideally, also be coupled with a .npmrc setting that overrides a particular namespace (as we typically organize the workspace packages to also have a single common npm namespace) with a "fake", unreachable npm registry - to avoid the risks of injection at the public npm registry.

Rant

Needless to say, this state of things, and this architecture and software design seems borderline maliciously negligent on the npm developers part. Unwillingness to properly support using git repos with workspaces puts people & projects at elevated risk.

Why npm developers? They are de-facto leaders of opinion of the node.js package management domain core functionality scope. They have also been mentioning exactly these attacks in the past, and were like "oh boy how can we improve the resilience of the npm and the ecosystem to these kinds of attacks". Failure to recognize this issue (I know we're at yarn issue tracker - but this has been brought up at npm issue tracker too) as a security risk is, well, just sad. They should hire someone who understand their own domain.

Yarn could actually solve this better by providing a way to programaically generate resolutions, or at least make it easier to declare a whole set of resolutions by setting a single value, like

"resolutionsFromWrokspaces": [
  "git@github.com:user/mynamespace1.git"
]

which would implicitly inject resolutions for each workspace from the repo git@github.com:user/mynamespace1.git as declared by it's root package.json:

"resolutions": {
  "@mynamespace1/package1": "git@github.com:user/mynamespace1.git#workspace=@mynamespace1/package-1",
  "@mynamespace1/package2": "git@github.com:user/mynamespace1.git#workspace=@mynamespace1/package-2",
  ...
}

(currently we have to provide all of them manually, although they can be - and should be - discovered automatically)

and you'd then be able to simply do:

"dependencies": {
  "@mynamespace1/package1": "*"
}

where * is fine since there's a custom resolution implicitly which will pick an exact version (from git).
This will also override all the workspace: version specifiers.

It should also work fine for git repos managed by any of the package managers (as opposed to just yarn), as long as they declare workspace via package.json; so only the consumer will have to use yarn - but that's how it works either way: you have to use yarn to get yarn features.