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

[g-farrow]

What version of Turborepo are you using?

1.7.0

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

pnpm

What operating system are you using?

Mac

Describe the Bug

Following upgrading from 1.6.3 to 1.7.0 I have noticed that turbo now consistently fails to run my deployment command giving the following error:

> [email protected] deploy:dev /home/runner/work/monorepo/monorepo
> turbo run deploy:dev --continue --ignore="pnpm-lock.yaml"

 ERROR  run failed: Failed to add workspace "" from apps/website/.next, it already exists at apps/customer-portal/.next
Turbo error: Failed to add workspace "" from apps/website/.next, it already exists at apps/customer-portal/.next
 ELIFECYCLE  Command failed with exit code 1.
Error: Process completed with exit code 1.

This is being run in GitHubActions on a standard ubuntu image. The build command runs ok (which runs this script in the two affected workspaces: "build:export": "next build && next export",.

The turbo command which is failing is supposed to run this script command in the workspaces: "deploy": "cdk deploy --all --require-approval never --outputs-file ./cdk-outputs.json -c env=production && ts-node cdk/helpers/upload-source-maps.ts",

Expected Behavior

The command should execute successfully, as it was doing in 1.6.3.

To Reproduce

I'm unsure as I am not clear on the cause. I did notice that some changes were made in 1.7.0 which affect how workspaces are parsed, perhaps this has introduced a problem when using pnpm?

Reproduction Repo

No response

[tknickman]

Hey @g-farrow, sorry for the issue here. It looks like it's caused by this: #2659 (cc @mehulkar)

Do all of your workspaces have a unique name field in their package.json?

Interestingly this looks like it's picking up build output as workspaces (paths have .next), could you share your app structure and pnpm-worspaces.yaml file?

[c-kirkeby]

Not to hijack this issue, but I was also getting this error and it forced me to downgrade to 1.6.3. In my case, we have a @workspace/ui under apps/ui and another workspace called @workspace/reporting-ui under apps/reporting-ui. They are both Next.js apps.

[tknickman]

Not at all, thanks for the extra info @c-kirkeby. I'll take a look at getting a reproduction together tomorrow.

[jacobjove]

I have the same issue using pnpm 7.19.0 and turbo 1.7.0: Failed to add workspace "" from apps/dashboard/.next, it already exists at apps/kwstriping/.next

[mehulkar]

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.

[c-kirkeby]

In my case at least, they don't have missing names. They each have unique name fields in package.json with the format "@workspace/ui" and "@workspace/reporting-ui". If I get some time tonight I can try to create a minimal reproduction.

[mehulkar]

@c-kirkeby a repro would be very helpful, thank you! (Also feel free to try the patch in #3375 just to see if it solves your issue, even though we may not have found the cause.

[g-farrow]

@mehulkar I also have names set in each package.json, so I don't think that's the cause. The two affected projects (in my case) are both NextJS projects in the apps/ workspace. This is my pnpm-workspace.yaml contents:

packages:
  - "apps/**"
  - "packages/**"
  - "services/**"

Rolling back to v1.6.3 resolves the problem for me as well, so it looks like a problem released in v1.7.0?

[mehulkar]

so it looks like a problem released in v1.7.0?

It definitely looks like an issue with 1.7, just trying to narrow down the problem, since I can't think of a scenario where this error would come into play other than missing names. Not to say I don't believe you, but any chance I can get my hands on your repo so I can do some good old debugging? Happy to pair / get a private drop of the codebase as well, if a minimal repro is not easy to make.

[tknickman]

I wasn't able to reproduce this one either. I was suspicious of turbo picking up the package.json from .next after a build when running your build command - but it doesn't look like that's the case.

A simple reproduction would be awesome!

[c-kirkeby]

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.

[mehulkar]

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:
   

   turbo/cli/internal/packagemanager/packagemanager.go

   Line 154 in 552768b

   f, err := globby.GlobFiles(rootpath.ToStringDuringMigration(), justJsons, ignores)

2. Allow workspaces with missing names #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/*"

[tknickman]

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

[mehulkar]

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

Spoke about this internally and came to the conclusion that:

1. Excluding packages without names is a bit extreme, because name are not required by package.json, so disallowing that could cause more trouble for other people's legitimate configurations.
2. Reverting Don't allow multiple workspaces to be named the same #2659 would not be good, because workspaces getting overwritten due to the same name is a real bug.
3. Making an exception for "" in the check is not a good idea because of (1) ^.

IMO, some good options going forward are:

1. Exclude git-ignored paths when getting the list of workspaces
2. Log a bigger warning when a workspace path is discovered with a missing name (this doesn't fix the problem, but could help debug the issue if the config is unintentional)

[g-farrow]

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.

[mehulkar]

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?

[Netail]

As an extension to this problem:

I ran into the following errors;
npm: must not have multiple workspaces with the same name (npm ls)
yarn: error There are more than one workspace with name (yarn workspaces info)
(checked 2 package managers to make sure it was not related to one of the two)

We make a copy of the package.json into the dist folder for publishing, which is also recognized as workspace. So I tried to exclude all dist folders as workspaces with the following:

  "workspaces": [
    "apps/**",
    "packages/**/!(dist)"
  ],

However, Turbo stopped recognizing all workspaces in the packages directory at all, while yarn and npm now worked as expected.

[g-farrow]

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.

[ruijdacd]

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

[Netail]

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

[leontastic]

@mehulkar In response for your request for feedback on this issue:

I just spent a couple hours bewildered why turbo wouldn't run my tasks with a bare bones setup. Then I stumbled on this issue – only then did I realize omitting name from package.json will cause turbo to skip that project.

My opinion is all package.json should have a name. But in this case I was missing name inadvertently. All my other tools work, npm works, turbo works from the root dir. But turbo doesn't recognize the package and says Running dev in 0 packages. I can imagine many others will encounter the same issue inadvertently, and be completely confused, and waste time like I did.

Two possible ways I think the turbo experience could be improved here:

• Use the directory name/path as a fallback
• Validate the package.json so turbo throws an error when it does not conform to expected schema (has name)

I definitely think libraries must have name in package.json, but I think some applications can be developed/run without a name. There's no obvious way to know what went wrong when turbo doesn't recognize the project.

[mehulkar]

@leontastic can you open a new issue? I think it's worth revisiting, especially since we're gearing up for 2.0 which has the luxury of including breaking changes, but I'd like to look at it with fresh eyes instead of as part of this issue.