Yarn: Working with multiple monorepos

[akosyakov]

I have 2 mono repos with yarn workspaces: A and B. B packages are using packages from A. I want to be able to change packages in A, rebuild them in context of A and then use changes without publishing in B. What is the suggested approach to achieve it?

[akosyakov]

As an example:

• the Theia repo: https://github.com/theia-ide/theia
• the Theia extension repo: https://github.com/theia-ide/theia-plantuml-extension

In the extension repo, i would like to work against the local Theia repo.

One important thing that we cannot allow duplicated packages for some dependencies, like inversify, phosphor, since it will lead to different instances of same classes at runtime and breaks the app.

[svenefftinge]

Any news on this? Is it possible? Can we help making it work?

[arcanis]

Noone works on this at the moment. I personally don't believe it's something we want to do, since the point of monorepos kinda is to be a single repo 😛

That being said, we're thinking about nested workspaces, and maybe it's something that would make more sense while solving this issue.

[svenefftinge]

I would like to consume a mono repo in a downstream repo with the ability to change/fix upstream code without going through npm.

If the upstream is not a mono repo, I can simply create a monorepo and have git submodules for the individual upstream projects. But what if the upstream is a mono repo? I cannot compose it.

How would you handle such a situation?

How would a nested workspace be different from a nested mono repo?

[myuseringithub]

Monorepos is a pattern, workspaces could be used for managing nested projects, but it is limited by design to be used for specific patterns like the common monorepo flow.
Nested workspaces could definitely allow for more modular approach for managing the repos deployment with out the tight entanglement of repos in a single repository.
I would suggest changing the title of this issue @akosyakov to include "nested workspaces".
The tooling for managing for example nested workspaces - dealing with different yarnk.lock files, installing nested workspaces as part of root and dealing with installs as individual project workspace, sharing dependencies across nested workspaces, are missing.
Personally I use them with submodules, where each submodule is a root workspace itself. But that I will try to write on later.

[ariofrio]

@myuseringithub Did you say you use them with submodules? Do you have a workaround you're currently using?

[myuseringithub]

@ariofrio that's not a workaround, just an example usage for nested workspaces. Submodules aside, I use multiple package.json in the same project, and in dependency packages of the project.
Yarn install is limited to installing dependencies of root workspaces, but ignores the nested package.json workspaces.
I think the best solution is to contribute to yarn and make it more flexible.
Or write a shell script that will install the nested workspaces, either attach it to postinstall/preinstall phases or as a separate command step.

Yarn isn't very customizable.