Turborepo globalEnv versus per-task env for build-time public variables

Cache key stability across deployment environments

Turborepo v2 defaults to strict environment variable mode, where only variables declared in globalEnv or a task's env array participate in the task hash. Framework-prefixed variables such as NEXT_PUBLIC_* or VITE_* are inlined at build time, so their values must vary the cache key when the target environment changes. The documentation shows both globalEnv and per-task env can declare these variables, but it does not prescribe which scope is appropriate for values that differ between preview, staging, and production deployments.

Placing a variable in globalEnv forces every task in the pipeline to re-execute when that variable changes, even tasks that do not consume it. Declaring the same variable in each task's env array limits invalidation to the tasks that actually read it, but duplicates configuration and risks drift. Neither approach clearly addresses whether a shared remote cache should store separate artifacts per deployment environment or rely on a single cache key for all builds of the same commit.

Open questions

1. Should framework public variables live in globalEnv or per-task env when their values differ across deployment targets?
2. Does the remote cache key need to incorporate the deployment environment identifier, or can a single artifact be safely reused?
3. Is there a recommended pattern for injecting environment-specific public variables without polluting the global cache namespace?