This is an interesting use case, where turbo is responsible for a subtree in a larger repository.

There are some workarounds possible (move turbo.json and your package.json / workspace definitions to the monorepo root), but that does pollute the rest of your repository with turbo-related items that are only relevant to /frontend.

Out of curiosity, would you also want to outputs outside of the root of where you're using turbo?

@gsoltis

There are some workarounds possible (move turbo.json and your package.json / workspace definitions to the monorepo root), but that does pollute the rest of your repository with turbo-related items that are only relevant to /frontend.

Yeh unfortunately not an option atm just due to the way our over arching build system is working and our desire to keep this folder somewhat isolated from the rest of the app

Out of curiosity, would you also want to outputs outside of the root of where you're using turbo?

That would also be great! Currently having to run a task as cache:false because we copy output to another location for deployment

I guess the whole restriction seems somewhat arbitrary unless there's a particular performance reason it's not done.

Some internal comments on this track the conversation here just about 1:1. 😅

Possible options:

• Promote turbo.json to the root, add a package.json at the root and move the workspaces definition there.
• Some API to set a root that is separate from the npm workspace root?
• inputs can be from anywhere, but outputs have to be scoped to the turbo.json rooted directory?

Eventually this type of design is absolutely one where they're going to ask for outputs to be somewhere outside of the frontend monorepo because of some weird combination of things which will absolutely break our assumptions. So I'm tempted to encourage them to promote it to root.

We're all on the same page here about this being interesting and worth supporting, but it violates a few core assumptions about how we function in terms of cache creation and restoration (which are all predicated on the repository root).

In terms of a short-term fix, the workaround is the only option that we can propose. We do believe that there's something valuable to figuring out how to enable incremental adoption that isn't top-down and, as we explore the problem, we will try to "discover" what that design should be.

Hey guys, any momentum on this? Another use case for this existing apps. We have a microfrontend-based app that started out with many isolated repos by design (11 in total). I'd like to keep that repo structure but would like to add some pipelining (orchestration) via turbo rather than building custom scripts. We don't want to merge all repos into one, or have developers create a root parent folder and move all their repos there. Would be nice to have another repo that would "act as root".

I get that the ideal is to have a parent folder (root) and have all your apps/ and your packages/ inside. But an existing app won't have this. What is the limitation with forbidding repo to reach outside of the root?

Thanks!

Hey guys, any plans to move this forward?
My use case:

I have a multilanguage project with C++, Kotlin, and JS monorepo parts. The proto files are located in the root of the project (parent root of the monorepo) and I can't move proto files to the monorepo, because the C++ and Kotlin code requires those files also.