Turbo chooses to create cookie files in the first project in the workspace of the VSCode single repository

[Chen-913]

Verify canary release

• [X] I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

-

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

pnpm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

2.1.1

Describe the Bug

I'm trying to learn this exciting library today, but as I'm reading the official docs and taking action, something confuses me, Turbo creates a lot of cookies files, not in the root of the project, but in the first project's folder in my vscode workspace, which is very strange and interferes with my This is very strange and affects my experience.

I don't know what these files do yet, but one thing is for sure, these files "can't find their mommy".

These cookie files are giving me a headache🥲

Expected Behavior

The cookies file is exported in the correct project folder.

To Reproduce

1. create a workspace in vscode
2. Create multiple projects and add the project root directory to the workspace you just created in vscode.
3. Use create-trubo on the command line to create a starter example according to the documentation.
4. Add the trubo project to the workspace you just created.
5. Run pnpm install -r
6. Make the changes as described in the documentation.
7. A large number of cookies appear in the git workspace.

Additional context

I have found that this issue may be in the same situation as mine, and I hope it can be helpful for fixing it. https://github.com/vercel/turborepo/issues/7671

[NicholasLYang]

Hey, thanks for the issue. Turborepo does not support nested workspaces, which your setup appears to be. In the case where a nested workspace does appear, Turborepo assumes that the workspace closest to your drive home is the root one and puts all relevant files there. In this case, it's putting the cookie files, which are produced by the daemon for file watching, in that workspace. If you are indeed using nested workspaces, I'd recommend moving the learn-turbo folder into a separate directory that is not nested under http-data-trans-method

[Chen-913]

Hey, thanks for the issue. Turborepo does not support nested workspaces, which your setup appears to be. In the case where a nested workspace does appear, Turborepo assumes that the workspace closest to your drive home is the root one and puts all relevant files there. In this case, it's putting the cookie files, which are produced by the daemon for file watching, in that workspace. If you are indeed using nested workspaces, I'd recommend moving the learn-turbo folder into a separate directory that is not nested under http-data-trans-method

Thank you very much for answering my questions, it helps me a lot to understand Turbo.😄 One of the reasons I use vscode's workspace feature a lot in my day-to-day work is because I have a very large number of projects that I need to switch back and forth between (maybe 5+), and it would be inconvenient for me to switch back and forth between projects if I had a vscode window open for each one. I would like to ask if Turbo has any plans in the future to support working properly in nested workspaces? For example, resolving the root field in turbo.json to indicate that this is the root directory of the project, and that anything Turbo does should be done in this agreed upon directory. If not, I'll close the issue.

[NicholasLYang]

It's definitely something we're looking into. To be frank, we need to investigate the support story for nested workspaces in the larger ecosystem. If it looks good, we're definitely more likely to consider it. So, as someone who uses it a fair amount, would you say that the support is good? Have you tried with different package managers?

[Chen-913]

Perhaps there is a misunderstanding regarding the term "workspace" mentioned in this issue. I want to clarify that the workspace I am referring to is VSCode's own workspace, and you can find its documentation here. It has no correlation with the "workspace" in a monorepo.

In the second step of the reproduction process I initially mentioned, I tried adding a monorepo managed by Turbo into the workspace, and this "workspace" refers to VSCode's Multi-root Workspaces. Of course, the project http-data-trans-method is also one of the many projects under this Multi-root workspace. It’s just a simple standalone repository generated by the Nest CLI.

As per my understanding, if I didn’t create a Multi-root workspace and just placed multiple projects in the same folder, opening the folder in VSCode, it might make some sense if Turbo was still generating cache files within http-data-trans-method. However, in VSCode's Multi-root Workspaces, none of the projects should interfere with the others, regardless of whether they are part of a monorepo. Each project should remain isolated from one another. Based on the current behavior, I still believe this is a bug.

Lastly, I haven’t used the workspace feature of other package managers. As far as I recall, package managers like Yarn and Bun also support monorepo workspaces. My team is still using Yarn, but none of our repositories are monorepos. That said, I currently believe pnpm remains one of the best options for managing monorepos.