TurboRepo 1.12 output validation: tasks failing in CI after upgrade with no declared outputs

Short answer

Yes — for tasks that genuinely produce nothing, declaring "outputs": [] explicitly is the intended, stable way to tell TurboRepo "this task is expected to emit no artifacts." It is not a fake path and it does not poison the cache; it simply removes the ambiguity between "you forgot to declare outputs" and "this task has none by design." That is the fix I would apply for lint, typecheck, and the packaging step, and I would avoid --skip-output-validation in a production pipeline.

Likely explanation vs. confirmed facts

Confirmed by your symptoms: the failure happens before the task executes, which means it occurs during task-graph resolution, not in your deployment script. Your deployment job is almost certainly fine — it is being blocked upstream by the validation gate, so you cannot yet conclude anything about the deployment itself.

Likely, but worth verifying: that 1.12 tightened validation so tasks with no outputs key at all are treated differently from tasks with an explicit empty array. Omitting outputs has historically meant "nothing to cache," and lint/typecheck tasks ran fine under that reading — which matches your 1.11 behavior. If 1.12 now rejects the omitted-key case while accepting "outputs": [], that fully explains what you are seeing. I could not verify the exact 1.12 changelog wording here, so treat the precise rule change as unconfirmed and validate it against your own logs (below).

What to change

In turbo.json, make the intent explicit for each affected task:

{
  "tasks": {
    "lint": { "outputs": [] },
    "typecheck": { "outputs": [] },
    "deploy#package": { "outputs": ["dist/**"] }
  }
}

Note the distinction: lint and typecheck are true no-output tasks, but a "deployment packaging step" that produces an artifact should declare its real output directory — otherwise Turbo cannot cache it and, more importantly, downstream tasks that depend on the artifact may not re-run correctly. Only use [] where nothing is written.

About --skip-output-validation

A flag that does not appear in the release notes should be treated as experimental or internal. Even if it works on your exact 1.12.x patch, it can change behavior or disappear in any minor bump — precisely the upgrade fragility that caused this incident. Use it, at most, as a temporary unblock while you roll out explicit outputs declarations, not as the fix.

Distinguishing validation failures from real task failures

• Timing: validation errors appear before the task's command starts — there is no output from your script at all. Real failures show your command's stdout/stderr and a non-zero exit code from the task itself.
• Log origin: validation messages come from the turbo engine (graph/config resolution), not from the task's shell. Grep the CI log for the exact error string and check whether the task's command line was ever echoed as "running."
• Local reproduction: run turbo run lint --force locally on 1.12. If it fails identically with no task output, it is validation. Then add "outputs": [] and re-run — if the task now executes, the gate was the whole problem.
• Graph check: turbo run deploy --dry-run shows whether graph resolution succeeds independent of execution; a validation failure will surface there too.

Once outputs: [] is in place, any remaining failure in the deployment job will be a genuine task failure, and the logs will contain your script's own error output — that is how you separate the two classes cleanly.