Upcoming Yarn 2 will bring cleaner support for nested workspaces.
As stated in the workspaces documentation:
if you try to setup nested workspaces then you must make sure that the nested worktree is defined as a valid workspace of its parent worktree (otherwise Yarn won't find its correct parent folder)
Here is an example of a monorepo taking advantage of nested workspaces:
/my-app
package.json (my-app)
/back
package.json (@my-app/back)
/microservice1
package.json (@my-app/microservice1)
/microservice2
package.json (@my-app/microservice2)
/front
package.json (@my-app/front)
/mobile
package.json (@my-app/mobile)
/web
package.json (@my-app/web)
with my-app/package.json defining workspaces like this:
{
"name: "my-app",
"private": true,
"workspaces": {
"packages": ["back", "front"]
}
}
my-app/back/package.json defining workspaces like this:
{
"name: "@my-app/back",
"private": true,
"workspaces": {
"packages": ["microservice1", "microservice2"]
}
}
and my-app/front/package.json defining workspaces like this:
{
"name: "@my-app/front",
"private": true,
"workspaces": {
"packages": ["mobile", "web"]
}
}
Issue
Current algorithm stops as soon as it finds a package.json containing a workspaces section up in the tree.
Note: it already is possible to nest workspaces with Yarn 1 by defining the root worktree package like this:
{
"name: "my-app",
"private": true,
"workspaces": {
"packages": ["back/**", "front/**"]
}
}
With the workspaces section of @my-app/back and @my-app/front having no effect.
But Yarn 2's way of defining packages definitely seems cleaner.
What would you think about having the algorithm to search for the most upward worktree package ? Something like:
currentPackage = ./package.json
while (hasParentPackage(currentPackage) && parentPackage.workspaces.includes(currentPackage) {
currentPackage = parentPackage
}
return currentPackage
It will still work for Yarn 1 workspaces while being ready for Yarn 2 nested workspaces.
Upcoming Yarn 2 will bring cleaner support for nested workspaces.
As stated in the workspaces documentation:
Here is an example of a monorepo taking advantage of nested workspaces:
with
my-app/package.jsondefining workspaces like this:my-app/back/package.jsondefining workspaces like this:and
my-app/front/package.jsondefining workspaces like this:Issue
Current algorithm stops as soon as it finds a
package.jsoncontaining aworkspacessection up in the tree.Note: it already is possible to nest workspaces with Yarn 1 by defining the root worktree package like this:
With the
workspacessection of@my-app/backand@my-app/fronthaving no effect.But Yarn 2's way of defining packages definitely seems cleaner.
What would you think about having the algorithm to search for the most upward worktree package ? Something like:
It will still work for Yarn 1 workspaces while being ready for Yarn 2 nested workspaces.