[Feature] Make peerDependency types available to Typescript

• I’d be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

I’m using Typescript Project References with a single root tsconfig which references all my projects.

In order to compile some of my workspace packages with Typescript, I must copy many of their peerDependencies into their devDependencies, even when my root package.json lists those already. This leads to busy-work and bloated package.json files.

Example 1: I have a workspace package called my-typeorm-utils that lists “typeorm” as a peerDependency but in order to compile I must list it as a devDependency even though my root package.json lists it as a dependency.

Example 2: I use @storybook/react across many workspace packages and list it as a peerDependency in all. In order to compile all the stories, I must also list it as devDependency. Upon doing that I find I now must list babel-loader and @babel/core as devDependencies. Once again I find I need to add webpack and on it goes.

Describe the solution you’d like

Ideally Typescript (or any other build tool) would somehow know to use the matching dependency or devDependency provided by the root workspace package.json.

Describe the drawbacks of your solution

• Not sure how you would limit it to just build tools.

Describe alternatives you’ve considered

One alternative that wouldn’t be so turn-key and would add complexity to yarn’s internals is something I’m calling Virtual Dependencies. I’ll detail that idea in a follow-up comment

[sparebytes]

I tried different values for pnpFallbackMode but it didn’t seem to have an effect, at least with my setup.

Introducing a JS file that alters the package.json would need to be done carefully because it wouldn’t be able to rely on any absolute dependencies.

I think it makes sense for the so-called “spreads” to be referenced very much like existing packages. This way existing tooling around resolvers, fetchers, and linkers can be used. EG:

1. Via a new property on package.json
   • { "virtualDependencies": { "shared-dependencies": "1.0.0" }}
   • { "virtualDependencies": { "shared-dependencies": "file:./my-package" }}
   • { "virtualDependencies": { "shared-dependencies": "workspace:*" }}
2. Via the existing properties on package.json
   • { "dependencies": { "shared-dependencies": merge:1.0.0" }}
   • { "dependencies": { "...shared-dependencies": "1.0.0" }}
   • { "peerDependencies": { "...shared-dependencies": "file:./my-package" }}
   • { "devDependencies": { "...shared-dependencies": "workspace:*" }}

The first verison has the benefit of a very simple mapping. Dependencies, peerDependencies and devDependencies of the virtual dependency are merged into the dependencies, peerDependencies and devDependencies of the consumer respectively.

The second version would take more consideration and I’m not totally sure of the benefits. It would require some new type of notation or protocol. Also, if the spread can be listed under dependencies, peerDependencies or devDependencies, then you have decide how the DependencyTypes of the spread are mapped into the consumer. See the table below for how it might work.

shared-dependencies package.json DependencyType	Placement of "shared-dependencies": "*" inside consumer package.json	Destination DependencyType
dependency	dependency	dependency
dependency	peerDependency	peerDependency
dependency	devDependency	devDependency
peerDependency	dependency	peerDependency
peerDependency	peerDependency	peerDependency
peerDependency	devDependency	???
devDependency	dependency	devDependency
devDependency	peerDependency	devDependency
devDependency	devDependency	devDependency

P.S. My first instinct was to call it something like bundled but that name already has baggage too.

[merceyz]

Closing as PnP is strict on purpose, if you want it to be more relaxed you can use pnpMode: loose but if you end up isolating your workspaces you’ll run into issues (https://github.com/yarnpkg/berry/issues/838#issuecomment-581152350).