Per-task opt-out of framework inference in turbo.json

[bitttttten]

Right now there are two ways to opt out of Framework Inference:

• --framework-inference=false on the CLI — global, all tasks.
• Negative wildcards in env — per-task, but you have to spell out every framework's prefix.

Neither really matches the intent when a task is just framework-agnostic and you want to say "don't infer anything for this one."

The case that made me want this

We have a codegen task (codegen:gql) that turns a GraphQL schema into TypeScript. The output is a function of the schema and the config, nothing else. But it lives inside packages that happen to be Next.js and Vite apps, so framework inference injects NEXT_PUBLIC_* and VITE_* into its cache key. In general it's fine but if someone changes an env var, it seems that the codegen:gql task gets missed. So not ideal.

We opened a PR to fix this, with smthing like:

"codegen:gql": {
  "env": ["!NEXT_PUBLIC_*", "!VITE_*"],
  ...
}

Works (thanks to #11303), but it means I now have to remember to list every framework prefix that could ever appear in the repo, and keep that list in sync with turborepo's inference list forever. If turborepo adds a new framework prefix (Solid, Redwood, and Sanity have all been added at various points), any config using negative wildcards silently over-invalidates and there's no signal that anything went wrong. But mainly tbh.. I find it more "declarative". Future devs won't come across a "env": ["!NEXT_PUBLIC_*", "!VITE_*"], and think what the heck. But a "frameworkInference": false, is self explanatory.

What I'd love instead

A per-task boolean:

"codegen:gql": {
  "frameworkInference": false,
  ...
}

Same semantics as the CLI flag, just scoped to one task instead of the whole turbo run. Reads like the actual intent ("this task doesn't care about framework env"), and it keeps working when new framework prefixes get added upstream. A smol request but I think a big improvement for maintenance :)

Why not just...

• Move it to passThroughEnv that's per-package, easy to get wrong across a big repo, and doesn't help when the task legitimately runs in framework-owning packages.
• Root-level negative wildcards same brittleness as above, just centralised.
• envMode orthogonal (that's about strict/loose for undeclared vars, not inference).