chore(config): retire the dead tailwind.config.js eslint ignore; reword the postcss blind-spot docblock (#4350)

[yinlianghui]

Part of #4350

Two of the three items land here. Item 1 STOPPED on its measured stop condition and is left for a ruling, so this PR says Part of rather than Fixes — merging it does not close the card.

The PM ruling on #4350 delegated all three items with conditions attached. Items 2 and 3 met theirs. Item 1's condition turned out to be met in substance and violated in fact, by a mechanism the ruling's proxy could not see.

Item 1 — root tailwindcss + autoprefixer: STOPPED, not removed

The ruling's stop condition:

does any workspace package build CSS through tailwind/autoprefixer WITHOUT declaring them itself (the only way the root copy could be load-bearing under pnpm's isolation, and exactly what the #4394 phantom-deps gate now polices)? Zero such packages (the card's own sweep suggests zero) -> the two root devDependencies + lockfile lines go [...] Any hit -> STOP that item, report.

The CSS sweep is clean — zero hits. The card's own measurement reproduces exactly. But the root copy is load-bearing anyway, for a reason that is not about resolution at all, and item 1 is stopped on it.

The anchor-hypothesis sweep

Every package whose build or stylesheet actually loads either package, against its own manifest. "Loads" means a real module-resolving form (a postcss plugin key, an @import that resolves the package), not a mention in a comment or docs:

Package	What loads it	tailwindcss declared	autoprefixer declared	Hit?
apps/console	src/index.css@import 'tailwindcss'	yes	yes	no
apps/site	app/global.css@import 'tailwindcss'	yes	n/a (not used)	no
examples/byo-backend-console	src/index.css@import 'tailwindcss'	yes	yes	no
examples/console-starter	src/index.css@import 'tailwindcss'	yes	n/a (not used)	no
packages/components	src/index.css + postcss.config.js names autoprefixer	yes	yes	no
packages/runner	src/index.css + postcss.config.js names autoprefixer	yes	yes	no
packages/fields	src/index.css@import 'tailwindcss/utilities.css'	yes	n/a (not used)	no
packages/app-shell	nothing — the only tailwindcss strings in src/styles.css are inside a docblock (lines 4 and 6); the file itself is @custom-variant / @keyframes / @utility only, and its build is plain tsc	no	no	no
repo root	nothing — the only match anywhere at the root is package.json's own two declaration lines	(the two under test)	(the two under test)	no

Zero packages process CSS through either package without declaring it. Confirmed independently by pnpm check:phantom-deps staying green.

A resolution probe is deliberately not offered as evidence here: all 47 manifests "resolve" both names through the root symlink, which is the precise trap scripts/check-phantom-dependencies.mjs was written to document (#4394). Resolution answers the wrong question.

The hit: the root manifest is the declared version anchor for the CLI scaffold

packages/cli/src/utils/scaffold-dependencies.ts exports SCAFFOLD_DEV_DEPENDENCIES — the devDependency map written into every app generated by all three generators (objectui init and the two app generators). It declares tailwindcss: '^4.3.3' and autoprefixer: '^10.5.4', and its docblock names the anchor outright:

Every range is anchored to an in-repo manifest, and app-generator.test.ts's DEPENDENCY_ANCHORS names the anchor for each one and fails on an unanchored addition. [...] they are anchored to this repo's Tailwind 4 like everything else — tailwindcss to the root, @tailwindcss/postcss [...] to the in-repo range every postcss.config.* here already names.

DEPENDENCY_ANCHORS in packages/cli/src/__tests__/app-generator.test.ts records it as data: autoprefixer: 'root' and tailwindcss: 'root', alongside seven toolchain siblings anchored the same way (@types/react, @types/react-dom, react, react-dom, react-router-dom, typescript, vite).

So this is exactly the possibility the card raised as its reason to escalate — "a monorepo root sometimes carries a dependency deliberately — as a version anchor for the workspace [...] and that intent is not visible in the tree". The intent is in the tree; it is just not in any build config, which is where both the card's sweep and the ruling's proxy looked.

Measured, not argued. With the two devDependencies removed, pnpm exec vitest run packages/cli/ goes red on the anchoring gate, naming the anchor:

FAIL packages/cli/src/__tests__/app-generator.test.ts > generated app manifests
> sources every range from this repo instead of inventing one
AssertionError: autoprefixer must exist in the root manifest: expected undefined to be truthy
- Expected: true
+ Received: undefined
562| expect(rootRange, `${name} must exist in the root manifest`).toBeTruthy();

That is item 1's reverse verification, and it ran in the direction nobody predicted: the removal was expected to be inert everywhere, and it is inert in the CSS pipeline while breaking a scaffold-versioning contract one package away.

Doctor before / after (captured while item 1 was applied)

The ruling asked for objectui doctor at the root going "clean for the first time" as the acceptance evidence. It does not go clean, and I am reporting that rather than smoothing it:

before: ✓ Tailwind CSS ^4.3.3 installed
x Tailwind CSS 4 needs @tailwindcss/postcss, which is neither declared nor
installed here. ...
Found 1 issue(s).
after: ⚠️ Tailwind CSS not found in dependencies
Found 1 issue(s).

Reading packages/cli/src/commands/doctor.ts: the whole Tailwind block is gated on deps.tailwindcss, and a directory that declares no tailwindcss collects warn('tailwind-missing', ...) instead. So removal swaps an error for a warning and the issue count stays at 1. The severity genuinely improves and the remaining line is truthful — but "clean" was not achievable this way, and the card's prediction that it would be is measurably wrong.

What is now a decision rather than a task

Both options keep the scaffold emitting byte-identical ranges (^4.3.3, ^10.5.4), so this is about where the range of record lives, not about any user-visible version:

• A — keep both root devDependencies (what this PR does, by reverting). They are the anchor of record, and seven sibling toolchain deps are anchored the same way. Cost: doctor at the root keeps reporting its one issue, and the two lines keep looking unused to the next reader — which is how Residue after the dead-Tailwind-config deletions (#4065/#4066): the repo root still declares tailwindcss + autoprefixer it never uses, and two references to the deleted files survive #4350 came to be filed.
• B — remove them and re-anchortailwindcss / autoprefixer in DEPENDENCY_ANCHORS from 'root' to 'in-repo'. Measured as mechanically viable: every non-root manifest agrees on exactly one range for each (^4.3.3 across 7 manifests, ^10.5.4 across 5), which is what the 'in-repo' anchor requires. Cost: it splits one deliberate convention into two, leaving seven toolchain deps anchored at the root and these two anchored elsewhere.

My recommendation is B, but only as a maintainer's or PM's call, not an agent's — the anchoring discipline was established deliberately across #3742 / #3754 / #3892, and "which manifest is the source of truth for a scaffold range" is a convention question, not a mechanical one. B is the option that makes the root manifest stop claiming to be a Tailwind project while keeping every generated range anchored to a manifest that actually uses the package, which reads as the stronger long-term shape. A is the safe default and is what is committed here.

Item 2 — the dead **/tailwind.config.js eslint ignore: REMOVED

Sweep, per the ruling's condition ("ANY tailwind.config.js anywhere, fixtures/harnesses included"):

• git ls-files matching tailwind.config.* — zero tracked files.
• find . -name 'tailwind.config.*' excluding node_modules and .git — zero files on disk, so untracked fixtures and harness output are covered too.
• The scaffold is pinned not to regenerate one: packages/cli/src/__tests__/app-generator.test.ts:978 ("writes no tailwind.config.js, because v4 would never read it") and cli-bin.test.ts:229, which asserts both tailwind.config.js and tailwind.config.ts are absent from a real generated app.
• One string match that is not a file, recorded so the next reader does not re-chase it: packages/components/shadcn-components.json has "tailwind": { "config": "tailwind.config.js" }. That is shadcn's own components.json schema field, no such file has ever existed in that package, and no script in the repo reads the key (scripts/shadcn-sync.js and scripts/shadcn-local-patches.mjs contain no tailwind reference at all). It predates chore(config): delete three Tailwind config files nothing reads (#4065, #4066) #4349 and is untouched here.

Zero matches, so the glob and its comment go.

Reverse verification, with my prediction stated first — and my prediction was wrong. I predicted the removal would be inert even for a hypothetical future file, reasoning that every config object in eslint.config.js is scoped to .ts/.tsx (files: appears three times, all TS-only), so a .js file would match no configuration and simply not be linted.

Measured instead, with a scratch packages/components/tailwind.config.js holding the exact shape the deleted file had (import type ... from 'tailwindcss' plus satisfies Config):

glob present (origin/main): ✖ 919 problems (0 errors, 919 warnings)
named explicitly: "File ignored because of a matching ignore pattern"
glob removed (this PR): ✖ 920 problems (1 error, 919 warnings)
packages/components/tailwind.config.js
1:13 error Parsing error: Unexpected token {

Exactly one error, exactly on the scratch file. So the original comment's rationale was accurate and mine was not: ESLint does reach .js by default and the default parser does choke on import type. The card's stated expectation — "removing it turns any such file into a lint error rather than a silent skip" — is the measured truth. With zero such files today the removal is inert, and that is what makes it safe now rather than harmless in principle. Scratch file removed; the tree carries only the two intended edits.

The load-bearing check that nothing was silently skipped: repo-wide turbo run lint — 45 successful, 45 total, zero packages reporting a nonzero error count, run at the exact tree state pushed here.

Item 3 — the counterfactual docblock sentence: REWORDED

scripts/__tests__/helpers/build-program.ts. Comment-only; the helper's tests are unchanged and its behavior is untouched.

The narrowing stays, because it is still true in principle — postcss config discovery genuinely is not modelled. What changed is the sentence that named the repo-root postcss.config.mjs as a present-tense fact; after #4349 deleted that file it was counterfactual as written. It is now conditional and future-shaped, aligned with what the #4198 comment recorded:

What this does not close. The class concern in the title survives the deletion [...] if a postcss.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 the docblock now says a package with no config of its own "would read the nearest one ABOVE its directory", records that no such file exists today (verified: all six tracked postcss.config.* sit inside the package that uses it, and there is none at the repo root or in packages/, apps/, examples/), credits #4065 / PR #4349 with deleting the one that used to sit above them all, and states plainly that this retires the instance and not the gap. The two measured coincidences (every vite-build CSS package carries its own config; packages/fields' index.css never enters the Vite graph) are kept and re-labelled as what would have to hold for a re-introduced config to stay harmless.

Verification

All run in the worktree at the pushed commit, heavy steps serialized under the shared lock.

• pnpm exec turbo run lint --concurrency=2 — 45 successful, 45 total, no package reporting a nonzero error count. Item 2's proof.
• pnpm exec vitest run scripts/__tests__/ packages/cli/ --maxWorkers=2 — 43 files, 998 tests passed. Covers item 3's own file (turbo-build-inputs.test.ts builds on that helper) and the CLI doctor / generator suites.
• pnpm exec tsc -p tsconfig.scripts.json — clean (build-program.ts is in that program).
• node scripts/check-control-bytes.mjs — OK, 4147 tracked text files scanned, 85 binary skipped. Plus a direct self-scan of both edited files for the wider control-byte range: no matches.
• node scripts/check-phantom-dependencies.mjs — green: 40 released packages, 2660 source files, 12777 specifiers, "Every in-scope import is declared by the package that publishes it."
• node scripts/check-changeset-presence.mjs — "No source of a released package changed in this range, so no changeset is owed." 2 files changed, 0 under any released package's src/. check-changeset-fixed.mjs and check-changeset-no-major.mjs both exit 0.
• pnpm install --frozen-lockfile — clean (the lockfile is untouched in the pushed state; the 6-line delta from item 1 was reverted with it).

The doctor before/after and the failing anchor test above were captured while item 1 was applied, then reverted with git checkout origin/main -- package.json pnpm-lock.yaml and re-verified: packages/cli goes back to 998/998 green.

Scope

 eslint.config.js | 4 ---
scripts/__tests__/helpers/build-program.ts | 39 ++++++++++++++++++------------
2 files changed, 23 insertions(+), 20 deletions(-)

No changeset: no released package's src/ is touched and the presence gate self-determines. No skip-changeset label, per the same reasoning.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectui	Ignored		Aug 12, 2026 8:01am

[yinlianghui]

ACCEPT — PM 复核 (session session_017Qqyix2QcnpUC9XeYVDzx3); items 2+3 delivered, item 1's stop honored and ruled on the card (closing #4350 there).

• Item 1's stop is the protocol at its best: my ruling's stop condition (the CSS-pipeline proxy) was the wrong instrument, and the dev found the anchor's intent IN the tree where the card said it wasn't visible — SCAFFOLD_DEV_DEPENDENCIES + DEPENDENCY_ANCHORS naming 'root', converted from hypothesis to fact by one red test one package away. Applied-measured-reverted with Part of instead of executing a wrong deletion: exactly right.
• Item 2's wrong prediction honestly reported is worth more than a right one: the measured truth (ESLint reaches .js by default and the base parser chokes on import type — the deleted comment's rationale was accurate, the card's loud-not-silent expectation correct) is now recorded with a scratch-file proof, and the removal is safe precisely because zero such files exist today.
• The doctor delta reported as error→warning rather than the predicted clean — measured over manufactured — and item 3's facts verified rather than assumed. CI converged, changeset self-determination correct.

Flipping ready + arming auto-merge.

---

Generated by Claude Code