turbo: [turborepo] ERROR run failed: Failed to add workspace ""

That was really helpful @c-kirkeby, thank you!

I noticed it seems to only be happening when I change the pnpm-workspace.yaml pattern from - "apps/* to - "apps/**". I hope that helps!

You solved the bug! (at least yours, that is).

As mentioned in the pnpm docs, packages/** means “all subdirectories”. Once an app has built, your workspace declaration is picking up apps/docs/.next as a workspace.

#2659 exposed the bug that all these workspaces are being added into Turbo’s graph. However, since they don’t define any scripts and are not dependencies of anything, they are always skipped over during all execution. Our new check for duplicate workspaces is inadvertently catching this issue.

There are a few things we can do:

1. Ignore declared “workspaces” that are in .gitignore directories.

   I need to dig into pnpm itself to see how (and if) it does this, but our implementation is just expanding the globs at the moment: https://github.com/vercel/turbo/blob/552768bae0f92d716c3b6ea927502251be2992a3/cli/internal/packagemanager/packagemanager.go#L154

2. #3375.

   We can simply add a check for missing names. I think this is the wrong fix, because we shouldn’t have any of these in the first place. Based on this bug, I’m also concerned that large monorepos with a lot of Next.js apps that are misconfigured like this are bloating the graph unnecessarily.

3. We could revert the check for duplicate names.

   I also believe this is the wrong solution, as duplicate workspace names will overwrite each other, and it’s valuable to check against that.

I’ll float this to the rest of the team, but in the meantime, this should fix your issue:

packages:
-  - "apps/**"
-  - "packages/**"
+  - "apps/*"
+  - "packages/*"

I’ve solved this issue by adding the following ignore rules to my pnpm-workspace.yaml file, according to PNPM docs:

packages:
  - "apps/**"
  - "packages/**"
  - "!**/.next/**" # NEW
  - "!**/dist/**" # NEW

Please find the repo here: https://github.com/c-kirkeby/turbo-next-reproduction

This was created simply by using pnpm create turbo command, picking pnpm as the package manager. I noticed it seems to only be happening when I change the pnpm-workspace.yaml pattern from - "apps/* to - "apps/**". I hope that helps!

The issue is replicated by running pnpm build twice.

Hey all! Apologies for the inconvenience, and thanks for the reports!

Can you confirm that in each of your cases, the two workspaces mentioned int he error message are both missing the name field in their respective package.json files?

I’m submitting a “fix” in #3375, but it actually feels like creating a worse bug to fix this. As you may be able to tell, our WorkspaceGraph uses the name of the workspace to keep track of it. Workspaces with the same name (even if they are "" will overwrite each other in the graph). I’m surprised this hasn’t manifested as a much worse bug for you in some other way.

In any case, it seems like things were “working” for you before. Could you confirm that

1. my understanding of the issue is correct
2. adding unique name keys to each workspace “fixes” the issue
3. you really don’t want to add names to each workspace

If the last one is true, I’d love to hear why as well. We may need to consider using switching to paths instead of names, if that’s the case.

It’s worth noting that depending on your implementation there may be undesired effects of doing this

just so I understand, what do you mean by this? “Your implementation” refers to turborepo’s solution for this problem? Or a consuming monorepo’s setup? In either case, what are the undesirable effects of changing to a single star?

I meant the monorepo’s setup. PNPM config allows both ** and * because they do different things. In my use case switching from ** to * was fine. But in a different monorepo setup, it may not be appropriate.

Sadly does not work yarn or npm

Thanks for the workaround options. I can confirm that @c-kirkeby you workaround works for me (changing pnpm-workspace.yaml from apps/** to apps/* for example). It’s worth noting that depending on your implementation there may be undesired effects of doing this - but for me it’s a good solution.

@mehulkar I think both of the options you’ve suggested are good. Improving error messaging is always helpful. But ignoring git ignored paths makes a lot of sense to me and is, I think, fairly intuitive as well.

I think we should warn on a detected package with a missing name, exclude it from the graph, and continue (don’t panic).