× invalid turbo json Error: × No "extends" key found if `./` is specified in the pnpm-workspace packages

[aminya]

Verify canary release

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

Link to code that reproduces this issue

https://github.com/aminya/temp-turbo-pnpm-bug

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

pnpm

What operating system are you using?

Linux

Which canary version will you have in your reproduction?

2.0.14

Describe the Bug

When ./ is specified in the packages list in pnpm-workspace.yaml, turbo gives this error. This is very confusing and doesn't provide any info on what the issue is. From the pnpm perspective, ./ is a valid package, but even if turbo doesn't accept this, it should provide a better error message.

turbo 2.0.14

  × invalid turbo json

Error:   × No "extends" key found
    ╭─[turbo.json:1:1]
  1 │ ╭─▶ {
  2 │ │     "$schema": "https://turbo.build/schema.json",
  3 │ │     "tasks": {
  4 │ │       "build": {
  5 │ │         "dependsOn": [
  6 │ │           "prebuild",
  7 │ │           "^build"
  8 │ │         ],
  9 │ │         "outputs": [
 10 │ │           "output-file.txt",
 11 │ │           "dist/**"
 12 │ │         ]
 13 │ │       },
 14 │ │       "prebuild": {},
 15 │ │       "lint": {},
 16 │ │       "type-check": {}
 17 │ │     }
 18 │ ├─▶ }
    · ╰──── add extends key here
    ╰────

Expected Behavior

Work without issues or provide a better error

To Reproduce

pnpm i
pnpm exec turbo build

Additional context

No response

[chris-olszewski]

I'm almost positive this is the same bug as reported in https://github.com/vercel/turborepo/issues/8599

We do want to fix this, but it currently isn't a high priority as the workaround is removing the leading ./ from the workspace globs.

[chris-olszewski]

Thank you for the report. This is the same issue as https://github.com/vercel/turborepo/issues/8599 so I will be closing this in favor of that.

TL;DR our workspace globbing codepath differs slightly from our "am I in this workspace" check in a way that isn't super easy to resolve.

Closing in favor of https://github.com/vercel/turborepo/issues/8599

[aminya]

Is there a workaround? Thank you

[SilentImp]

Still same problem. And I need to have root in the workspaces, because I want to have changeset for monorepo itself, for example when I change some kind of config there.

[siggerzz]

Also experiencing this problem and also rely on root package in my workspaces for changesets 👍🏼

[karamosusso]

I had the same issue and I solved it by pinning turbo to version 2.5.4. I had specified to use 2.5.4 and up. this has caused the cloud builder to use version 2.5.8, which in return caused the death loop of "unkown key extends".

AI version of comment:

Gemini Of course. It's an excellent idea to share your findings with the community, as it will undoubtedly save others from the same frustrating experience. Here is a well-structured comment you can post on the relevant GitHub issues (#9017 and #8599).

GitHub Comment Hello everyone,

I've been struggling with a similar issue when deploying a Next.js monorepo with pnpm to Firebase App Hosting. I was caught in a paradoxical loop of build errors related to turbo.json, and I wanted to share the solution that finally worked for me in case it helps others.

The Problem:

The Firebase App Hosting build environment seems to have multiple, contradictory validation steps for turbo.json:

If pnpm-workspace.yaml includes . in the packages list, the build fails with No "extends" key found in turbo.json. This is likely due to the bug discussed in this thread. If you add extends: ["//"] or extends: ["./turbo.base.json"] to turbo.json to fix this, a different part of the buildpack fails with Found an unknown key 'extends'. This "Catch-22" seems to be caused by an inconsistency between different versions or parsers of Turborepo used within the Firebase buildpacks.

The Solution:

The key was to force the build environment to use a specific, known-good version of Turborepo.

Pin the Turborepo Version: In my root package.json, I pinned the exact version of Turborepo that I knew was compatible with the extends: ["//"] workaround.

json "devDependencies": { "turbo": "2.5.4" } Configure pnpm-workspace.yaml: I ensured the root directory was included as a package.

yaml packages:

• '.'
• 'packages/*'
• 'functions' Configure turbo.json: I used the extends: ["//"] workaround.

json Show full code block { "$schema": "https://turbo.build/schema.json", "extends": [ "//" ], // ... rest of the config } By pinning the turbo version, the pnpm install step in the Cloud Build process installed the correct version, overriding the buildpack's default and making the build process consistent and successful.

I hope this detailed breakdown helps anyone else facing similar issues with Firebase App Hosting.