Berry: [Feature] Yarn 1 and Yarn 2 split mode

[larixer]

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

Describe the user story

I'm as a JavaScript engineer have monorepos that target multiple frameworks and depend on many 3rd party packages. Part of my codebase can be perfectly managed with Yarn 2 and PnP and part cannot survive in a PnP world yet. I want to migrate part of my packages in a monorepo to Yarn 2 and PnP and leave the other part managed by Yarn 1.

Describe the solution you'd like

It is probably possible to add minimal API to Yarn 1, so that it can be used as a library and make other minor adjustments so that Yarn 1 can be embedded into Yarn 2 node_modules linker plugin. Semantic of package.json -> workspaces field should be extended to support tagging, which workspace should be managed by v1 and v2, for example we can add nm: and pnp: prefixes to workspace globs to distinguish which linker should be used.

Describe the drawbacks of your solution

The main drawback is that this solution is a compromise everywhere. node_modules support will not be perfect, but rather we will try to make Yarn v1 work in a way it was not designed for. The milage may vary and there are might be some unexpected blockers that render the whole idea not viable.

Describe alternatives you've considered

The alternative is to make node_modules linker implementation from scratch. It is much more fun, but it will take much more time to implement all the edge cases of node_modules linking that Yarn 1 already supports.

[larixer]

There is another obvious alternative - do not support node_modules at all in v2, but rather make PnP mode versatile enough to support most real-world scenarios. Like, for example, make pnpify more powerful, handle edge cases with v2's yarn link, maybe add better way then editing yarn.lock to override missing peer dep in 3rd party lib, and many more small improvements. This is my personal favourite.

[arcanis]

For RN in particular, I'm not sure PnPify would be enough - iirc one problem is that native Xcode modules are referenced through their node_modules, and PnPify wouldn't affect Xcode 🤔 I've never done native development though so I might have misunderstood.

[larixer]

I'm not sure what is the market split between vanilla RN and Expo, but I guess for Expo it should be rather straightforward to support PnP, because all the user code is written in JS. I'm curious what will be the minimum requirements for node_modules consumed by native Xcode modules though, maybe we can do some shortcuts there...

[larixer]

We have implemented an alternative approach - node-modules linker for Yarn 2, hence the issue can be closed now