[Feature] Support "resolutions" field in any package

[alamothe]

• I'd be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story

The way I understand it, the "resolutions" is great to solve TypeScript's type-hell problem, see more here:
DefinitelyTyped/DefinitelyTyped#44777
microsoft/TypeScript#31148
https://stackoverflow.com/questions/50530597/how-to-exclude-node-modules-types-node-modules
https://dev.to/aleclarson/keep-types-node-out-of-your-react-project-4k3o

The way this can be achieved is to point @types/x to an exact version, but also point (short-circuit) e.g. @types/node to an empty package for a front-end project, to prevent type pollution.

However, the "resolutions" field has a restriction that it can only appear in the root package. So it falls short: for example, I have two workspaces, client and server. Inside client, I would like to short-circuit @types/node to an empty package. However, in the server project I don't want that. Instead, I want to point it to an exact version I'll use.

Describe the solution you'd like

The solution could be to allow the "resolutions" field in any package.

Let me know what you think, or if there's anything unsound with the above logic.

[arcanis]

This restriction is intended; Yarn can only ever resolve one name/range combination to a single version, so it couldn't support two sets of resolutions for different workspaces. This is a core requirements, and removing it would be very difficult for little gain.

[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.

[alamothe]

Sounds fair, will look into other options.

[alamothe]

I am reopening this issue because of another use case which is very important.

Currently yarn allows patching either:

1. In dependencies, by specifying patch: protocol, for top-level dependencies,
2. In resolutions in the top level for any package.

However, for transitive dependencies only option 2 can be used. The problem is that this forces every workspace to use exact same version of the dependency, which breaks fundamental expectation for multi-workspace projects.

Is there any other way to patch a transitive dependency?

[alamothe]

Closing again, looks like global resolutions field is very flexible: https://yarnpkg.com/configuration/manifest#resolutions

I wasn't aware of this.

[javier-dojo]

Closing again, looks like global resolutions field is very flexible: https://yarnpkg.com/configuration/manifest#resolutions

I wasn't aware of this.

Hi @alamothe, did you find a way to use different resolutions for different packages within a workspace? I'm trying to achieve something similar but no luck :(