turbo `build` inputs: the root `postcss.config.mjs` is a dormant fifth instance of the #3514 class — outside every build program only by coincidence

[yinlianghui]

Found while measuring the build derivation for #4185. Not a live defect today — filed as an observation so the next reader does not have to re-measure it, and so the coincidence keeping it dormant is on the record rather than in one agent's head.

What is dormant

Vite hands CSS to postcss-load-config, which searches upward from the Vite root. So a package whose vite build processes CSS and which has no postcss.config.* of its own would read the repo-root postcss.config.mjs — a file outside its own directory, and therefore invisible to turbo's build cache key exactly as the root tsconfig.json was before #4185.

The guard that ships with #4185 (scripts/__tests__/helpers/build-program.ts) does not model postcss config discovery, and deliberately so: it would mean reproducing a plugin-adjacent resolution whose defaults drift between versions. That decision is sound only while nothing reaches the root config.

Why it is dormant — measured, both halves

Nothing reaches it, because two independent facts happen to hold at once:

1. Every vite build package that actually processes CSS carries its own postcss config, which stops the upward walk before the repo root: apps/console, packages/components, packages/runner, examples/console-starter, examples/byo-backend-console.
2. packages/fields is the only vite build package with no postcss config of its own, and it does have a CSS file — but packages/fields/src/index.css never enters the Vite graph. Nothing imports it: packages/fields/scripts/build-css.mjs compiles it separately, invoking postcss with an explicit plugin list (postcss([tailwindPostcss()])) that reads no config file at all.

Remove either fact and the root config silently becomes part of a build program.

Why it is worth recording

The trigger is one line. Adding import './index.css' to packages/fields/src/index.tsx — an ordinary-looking change, and the shape every other CSS-carrying package already uses — would pull the repo-root postcss.config.mjs into that package's build program. Turbo would not hash it, build would replay a stale dist/, and #4185's guard would stay green, because the derivation does not follow postcss.

That is the same "looks like enforcement, isn't" shape the class keeps producing, with the twist that the guard's own blind spot is what hides it.

Options, if this is ever picked up

• A. Teach build-program.ts postcss discovery. Model postcss-load-config's upward search from each vite build root. Cost: a third config-resolution mirror to keep in step with a dependency, for a file nothing reads today.
• B. Give packages/fields its own postcss.config.js. Two lines, matches what its five siblings already do, and makes fact 1 hold universally so the upward walk can never reach the root. Does not close the class, but removes the only package that could trigger it.
• C. Leave it, with the narrowing written down. What ships in turbo build inputs have the same out-of-package hole as #3514 / #4178 — root tsconfig.json / tsconfig.base.json and scripts/vite-*.ts are not hashed; measured frozen at 3f85d1417964dce6 #4185: the blind spot is stated in the derivation's docblock alongside its other narrowings, with the measurement above.

C is what is in place. B looks like the cheapest thing that would actually retire the risk, but it is a judgement call about a file no user hits today, so this is filed unassigned and unqueued for triage rather than fixed inside #4185's scope.

Related

• guard: turbo type-check 的手维护 inputs 名单已两次因"包程序越出包目录"失真 —— 评估从 tsconfig include 派生或加钉扎测试 #3514 / PR ci(turbo): derive the type-check inputs guard from each package's tsc program (#3514) #4176 — type-check, the class origin and the guard architecture.
• turbo test inputs have the same out-of-package hole #3514 closed for type-check — the root vitest.config.mts every package re-exports is not hashed #4178 / PR ci(turbo): derive the test inputs guard from each package's Vitest config program (#4178) #4188 — test.
• turbo lint inputs have the same out-of-package hole as #3514 / #4178 — the root eslint.config.js that IS the lint program is not hashed; measured frozen at 79872f192ee4828c #4184 / turbo build inputs have the same out-of-package hole as #3514 / #4178 — root tsconfig.json / tsconfig.base.json and scripts/vite-*.ts are not hashed; measured frozen at 3f85d1417964dce6 #4185 — lint and build; this was found by the latter's derivation work.

---

Generated by Claude Code

[claude]

Findings triage (first grade; premise check @ origin/main e1ade8f): HOLD — finding stands.

Both halves of the dormancy argument re-verified, and they still hold exactly:

• fact 1 — every CSS-processing vite build package carries its own postcss config, so the upward walk stops before the root: apps/console, packages/components, packages/runner, examples/console-starter, examples/byo-backend-console all have one; the repo-root postcss.config.mjs exists;
• fact 2 — packages/fields has no postcss config of its own (confirmed absent from the full repo listing), and packages/fields/src/index.css still has no importer: the only in-repo mentions of it are inside the file itself (:7 a docblock line, :24 a @reference), so it never enters the Vite graph.

Held, not queued: nothing reads the root config today, so there is no defect — and which way to retire the risk is a real choice, not a mechanical one (A pays a third config-resolution mirror against a drifting dependency; B is two lines but only removes the one package that could trigger it; C, the narrowing docblock, already shipped in #4185).

⚠️ Restart condition, recorded because it is one line wide: the moment packages/fields/src/index.css gains an importer — import './index.css' in packages/fields/src/index.tsx is the natural shape, and it is what five sibling packages already do — fact 2 dies, the root config joins that package's build program, turbo stops hashing it, and #4185's guard stays green while build replays a stale dist/. Any card that touches packages/fields' CSS entry should take option B (add packages/fields/postcss.config.js) in the same PR rather than rediscovering this; that is cheaper than either re-grading here or debugging a stale build later.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Findings cadence re-check @ origin/main 6314e87: HOLD — finding stands.

Premise live: the root postcss.config.mjs still exists with @tailwindcss/postcss + autoprefixer — the dormant fifth instance of the #3514 class, outside every build program only by coincidence, as filed. Held with a dedup note for promotion time: ui#4065 (pm:queue) already covers this same file from the unresolvable-plugins angle — if that card lands as a deletion, this finding closes with it; if it lands as a declaration fix, the turbo-inputs angle here survives. Whoever takes ui#4065 should read this card first.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code