Repository navigation
turbo build inputs: the root postcss.config.mjs is a dormant fifth instance of the #3514 class — outside every build program only by coincidence #4198
Description
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:
- Every
vite buildpackage 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. packages/fieldsis the onlyvite buildpackage with no postcss config of its own, and it does have a CSS file — butpackages/fields/src/index.cssnever enters the Vite graph. Nothing imports it:packages/fields/scripts/build-css.mjscompiles 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.tspostcss discovery. Modelpostcss-load-config's upward search from eachvite buildroot. Cost: a third config-resolution mirror to keep in step with a dependency, for a file nothing reads today. - B. Give
packages/fieldsits ownpostcss.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
buildinputs have the same out-of-package hole as #3514 / #4178 — roottsconfig.json/tsconfig.base.jsonandscripts/vite-*.tsare 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
testinputs have the same out-of-package hole #3514 closed fortype-check— the rootvitest.config.mtsevery package re-exports is not hashed #4178 / PR ci(turbo): derive thetestinputs guard from each package's Vitest config program (#4178) #4188 —test. - turbo
lintinputs have the same out-of-package hole as #3514 / #4178 — the rooteslint.config.jsthat IS the lint program is not hashed; measured frozen at 79872f192ee4828c #4184 / turbobuildinputs have the same out-of-package hole as #3514 / #4178 — roottsconfig.json/tsconfig.base.jsonandscripts/vite-*.tsare not hashed; measured frozen at 3f85d1417964dce6 #4185 —lintandbuild; this was found by the latter's derivation work.
Generated by Claude Code
Activity
claude commentedon Aug 11, 2026
Findings triage (first grade; premise check @
origin/maine1ade8f): HOLD —findingstands.Both halves of the dormancy argument re-verified, and they still hold exactly:
vite buildpackage 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-consoleall have one; the repo-rootpostcss.config.mjsexists;packages/fieldshas no postcss config of its own (confirmed absent from the full repo listing), andpackages/fields/src/index.cssstill has no importer: the only in-repo mentions of it are inside the file itself (:7a docblock line,:24a@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).
packages/fields/src/index.cssgains an importer —import './index.css'inpackages/fields/src/index.tsxis 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 whilebuildreplays a staledist/. Any card that touchespackages/fields' CSS entry should take option B (addpackages/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 commentedon Aug 11, 2026
Findings cadence re-check @
origin/main6314e87: HOLD —findingstands.Premise live: the root
postcss.config.mjsstill 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
os-zhuang commentedon Aug 11, 2026
Findings cadence re-check @
origin/main6d01319: HOLD —findingstands, both dormancy facts intact.Re-verified:
packages/fieldsstill ships nopostcss.config.*of its own,index.cssis still not imported by any entry (counter-check:build-cssstill present inpackages/fields/package.json, so the out-of-graph compile path is unchanged). Recent commits on the package (#4244, #4208) touch field widgets, not the build seam. Disposition C (documented narrowing in #4185's derivation docblock) remains the shipped state; option B (a two-line local postcss config) remains the cheapest true retirement and is a natural rider for the next PR that touchespackages/fields' build anyway. Restart condition: promote immediately if anyone importsindex.cssinto the Vite graph or adds a sixthvite buildpackage without its own postcss config.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
yinlianghui commentedon Aug 11, 2026
Cross-reference from #4065 / #4066 (PR #4349): the file this finding is about is being deleted, which retires this instance by a route none of the three options here considered.
#4065 was triaged with a delete ruling — the root
postcss.config.mjsis vestigial, not a latent trap — and PR #4349 removes it. With no config at the repo root,postcss-load-config's upward walk from any package has nothing to find, so the trigger described here ("addingimport './index.css'topackages/fields/src/index.tsxwould pull the repo-rootpostcss.config.mjsinto that package's build program") can no longer fire. That is strictly stronger than option B: B made fact 1 hold universally so the walk would stop early, while deletion removes the thing the walk would have arrived at.Independent confirmation that this card's measurement was right, re-run at
f046f885awhile implementing #4065 — both halves still hold, and I found no third:vite buildpackage that processes CSS carries its ownpostcss.config.*(apps/console,apps/site,packages/components,packages/runner, and the two console examples);packages/fieldsis the only CSS-carrying package with no config of its own, andscripts/build-css.mjsstill passes an explicit plugin array topostcss([tailwindPostcss()]), so it reads no config file;packages/plugin-calendarsets vitestcss: trueand has no postcss config either, but imports no.cssfile at all, so its CSS pipeline never fires. Worth recording since it is a second package that would have reached the root config the moment it gained a stylesheet import.What this does not close. The class concern in the title survives the deletion and should probably survive this card's resolution too:
scripts/__tests__/helpers/build-program.tsstill does not model postcss config discovery, so if apostcss.config.*is ever added at the repo root — or anywhere above a CSS-building package — the same blind spot returns with nothing to catch it. Deletion removes today's instance, not the gap in the derivation.So this is triage's call rather than mine: close as resolved-by-deletion, or re-scope to the unmodelled-discovery gap alone (option A, with the concrete instance gone). I have deliberately not edited that docblock in #4349 — its narrowing stays true in principle but now names a file that no longer exists, which is noted in that PR as a follow-up rather than fixed inside a card that rules on three deletions.
Generated by Claude Code
Generated by Claude Code
os-zhuang commentedon Aug 17, 2026
Findings state conversion (batch 3): closing — resolved by deletion.
The subject file is gone: the root
postcss.config.mjswas deleted by PR #4349 (#4065's delete ruling), re-verified onorigin/mainjust now (git ls-treereturns nothing for the path). With no config at the repo root forpostcss-load-config's upward walk to find, the one-line trigger this card recorded (import './index.css'inpackages/fields) can no longer pull a root config into any build program — strictly stronger than the card's option B.On the residual class gap (
build-program.tsdoes not model postcss discovery): declining to re-scope this card to option A. A guard modeling config discovery for a file that no longer exists anywhere above any package is speculative infrastructure with zero instances — startup discipline says don't build it until an instance exists. The narrowing stays documented in #4185's derivation docblock (the stale filename there is already noted as a follow-up in PR #4349). If a root or intermediate postcss config ever reappears, that PR is the moment to reopen this.Maintainer may veto; reopen is free. 本评论来自分诊座位 Routine,不构成认领。
Generated by Claude Code
chore(config): retire the dead tailwind.config.js eslint ignore; rewo…