RFC: support nested workspaces

[dobesv]

What version of Turborepo are you using?

1.1.10

What package manager are you using / does the bug impact?

Yarn v2/v3 (node_modules linker only)

What operating system are you using?

Linux

Describe the Bug

When I run turbo it only builds workspaces that are mentioned in the root-level package.json - it doesn't detect workspaces that are listed in the workspaces fields of those workspaces.

So for example:

• package.json - has workspaces set to [ "packages/*" ]
• packages/p1/package.json - has build script
• packages/platform/package.json - has workspaces set to [ "*" ]
• packages/platform/p2/package.json - has build script

When I run turbo run build it only builds packages/p1 and not packages/p2

Expected Behavior

It should accumulate workspaces recursively if they listed in the workspaces field of a workspace that is being loaded.

To Reproduce

See bug description above

Workaround

Define all the paths to workspaces in subfolders in the top-level workspaces field instead of used nested worktrees / workspaces.

[sebastiangug]

I too would be interested in using nested workspaces, did an SO thread about it, so far I'm guessing it's just not a feature that's supported?

[dobesv]

I imagine a pull request to resolve this would have a good chance of being accepted. It's kind of an unusual use case so I can imagine the project maintainers probably have other things higher on their TODO list currently.

[tlivings]

I agree this feature would be useful. My use case is not particularly unusual: I'd like to be able to setup CODEOWNERS for a particular workspace for different groupings.

The main problem doesn't seem to be finding the nested packages during build, but rather local module linking (the package builds but is not copied to node_modules).

[jambsik]

In case it could be useful... I had a similar problem as I had the following distribution:

apps/
     app1/
     platform/
            app2
            app3

My workaround was as follows:

{
    "name": "myturborepofolder",
    "version": "1.0.0",
    "private": true,
    "workspaces": {
        "packages": [
            "apps/*",
            "apps/platform/*"
        ]
    }
}

On the other hand, I had tasks like the start task customised to only pick up certain apps from my workspaces (some I don't care to start). So in order to run the commands you would have to add the additional filter of this "sub folder for the workspace". "command": "turbo run start --filter='./apps/*' --filter='./apps/platform/*' ",

This step is not necessary as it is just a reminder in case you have filtered commands, but if you are interested in launching the build or start command in all projects it should work...

Obviously it might be interesting to be able to launch them per workspace but I think this can be achieved by playing a bit with the tasks and custom definitions of turbo.json although I haven't tried it!

I hope it will be useful...

[gsoltis]

We don't currently support nested workspaces. I'm going to mark this as a feature request.

[dbousamra]

Any updates on this? This would be so useful for my team. We have a monorepo of separate business products, and want to share code. We want to group them still (thus the nested workspace aspect). Currently we use yarn v3, which works well, but I'd like to use Turborepo

[ThimoDEV]

I would also love to see this work <3

[zakpatterson]

I ran into a potential bug in a project dependency, and my first thought was, well no problem I'll just git clone the dependency into my packages/ directory and convert it to a workspace dependency so I can track the bug down. But that project dependency uses turborepo! So now it's a nested workspace and won't work without a lot of headache.

[vgseven]

anyone have any solution for this ?

templates/
       monorepo/
           turborepo01
           turborepo02
       next/
           next01
           next02

as i'm offering templates with cli, error say's extends key

https://github.com/silver-radium/init

turbo it's uses nested monorepo structure at :- https://github.com/vercel/turbo/tree/main/examples

[anthonyshew]

These are not nested Workspaces/Turborepos because the examples are not included in the Workspace definition: https://github.com/vercel/turbo/blob/main/pnpm-workspace.yaml

If the examples line was examples/* instead, then we would be getting the error that you're seeing.

[dolanmiu]

My use case is that I use NPM workapaces, and one of the packages is an Angular Workspace. So if this feature were to exist, it would be great if it could support this kind of mix too