Nested workspaces

[Anber]

PR which implements this RFC.

[bestander]

I have some concerns. This change would save some code duplication between parent workspace' and children workspaces' package.json files. Is it a big deal, can you add real life use cases that you want to solve with the RFC?

It could cause breaking changes, this RFC needs to consider some existing use cases. @arcanis, what do you think?

[Anber]

@bestander We use it in e2e-project which tests a group of packages which already have their own workspaces.

[arcanis]

I think the devil lies in the "Unresolved section" paragraph. I'm all for nested workspaces, but we need to find a good way to solve this:

Actually, there are two ways of implementation: using a definition of workspaces from parent package or merging all definitions. The first way is more preferable because it is more transparent and gives more control but it ignores all information about nested workspaces. On the other hand, the second way uses already defined workspaces from nested packages but it can be undesirable in case we want to override some workspaces in the parent project.

First approach

Pros: works fine with the current Yarn model, doesn't require recursing the filesystem Cons: verbose, nested workspaces must be manually synced or they won't work, unintuitive

Second approach

Pros: automatically updated, intuitive behavior Cons: not clear whether nested workspaces should apply to the whole tree or only their branch

Probably others. Need to think more time on this.

[ringods]

I just tried to do something similar: I have a Yarn workspaces based git repository named blueprints. Each package in this repo is a reusable NPM library. We are not yet at the stage that these packages have a stable API and will be published to an NPM repository. This repository is configured in Gitlab CI and has a yarn.lock file in the root.

I have another repository using the current state of these packages. I tried adding the blueprints repo as a git submodule, but also as a nested workspace.

In both repositories, I installed the Yarn workspace-tools plugin for ease of use.

Setup 1

Folder structure:

\-- parent
     |-- packages
     | .   |- blueprints    ( <-- reusable libs monorepo )
     | .   | .   |- packages
     |     | .   |    |- core
     | .   | .   |    | .  |- src/*
     | .   | .   |    | .  \- package.json
     | .   | .   |    |- ...
     | .   | .   |    \- lastlib
     | .   |     |- package.json
     |     |     \- yarn.lock
     | .   \- foundation .  ( <-- package using the libs )
     | .         |- src/*
     | .         \- package.json
     |- package.json
     \- yarn.lock

Top-level package.json:

"workspaces": [
    "packages/*"
]

Setup 2

Folder structure:

\-- parent
     |- blueprints    ( <-- reusable libs monorepo )
     | .   |- packages
     | .   |    |- core
     | .   |    | .  |- src/*
     | .   |    | .  \- package.json
     | .   |    |- ...
     | .   |    \- lastlib
     |     |- package.json
     |     \- yarn.lock
     |-- packages
     | .   \- foundation .  ( <-- package using the libs )
     | .         |- src/*
     | .         \- package.json
     |- package.json
     \- yarn.lock

Top-level package.json:

"workspaces": [
    "packages/*",
    "blueprints/packages/*"
]

In both cases, it seems that the yarn.lock file from the blueprints repository prevents proper functioning of dependency resolution within the blueprints repository when triggered from the top level project.

A review of nested workspaces together with https://github.com/yarnpkg/yarn/issues/5428 could make such a setup more consistent.