test: nothing verifies that a theme's arbitrary Tailwind value compiles to a rule

[IgorShevchik]

What

Every assertion this repository makes about theme classes is a string assertion. test/utils/*.spec.ts reads the theme .ts sources, and the component snapshots record the rendered class attribute. Nothing compiles CSS.

So for any arbitrary value — max-h-[min(var(--max-height-popup-list),var(--reka-select-content-available-height,100vh))] and its neighbours — the suite proves the class is written, never that Tailwind emits a rule for it, and never that a custom property the class depends on reaches :root.

Why it matters

Both failure modes are silent and total:

• if Tailwind stops generating a rule for an arbitrary value (a parser change, a @source scope change, a syntax the engine tightens), the class stays in the snapshot and the cap is simply gone — popups grow unbounded in a real browser while CI is green;
• Tailwind v4 tree-shakes @theme variables, emitting only those a generated utility references. A change that stops the theme file being scanned drops the variable from :root, var(--max-height-popup-list) resolves to nothing, and again nothing here notices.

This is not hypothetical arithmetic: #430 moved the popup height caps from literals into tokens, and during its review the mechanism had to be checked by hand — compiling src/runtime/air-design-tokens/tw-style/index.css through the installed Tailwind engine with the exact class strings from the regenerated snapshots. That confirmed it works today. Nothing keeps it working.

Scope

One spec, not a build-pipeline overhaul:

• compile the token CSS entry through the tailwindcss package's own API with a small set of candidate class strings taken from the theme files;
• assert a max-height declaration is emitted for each;
• assert the referenced custom properties appear in the output.

Worth keeping the candidate list short and pointed at the arbitrary values that carry a real invariant (the popup caps to begin with) rather than sweeping every class in src/theme/, which would turn a guard into a second snapshot suite.

Estimated at half a day, most of it deciding how much of the Tailwind entry to compile.

Context

Raised during the review of #430. Filed rather than folded in: the fix there was a class-string swap plus a guard over the theme sources, and adding CSS compilation to the test harness is a different kind of change that deserves its own review.

Priority: P3.

[IgorShevchik]

Done in #564. The suite now compiles CSS — a small amount of it, on purpose.

test/utils/theme-css-compiles.spec.ts runs the token entry through the installed tailwindcss engine with the candidates read out of src/theme/*.ts, and asserts both halves this issue asked for: a max-height declaration per candidate, and the --max-height-popup-* tokens reaching the compiled output.

Six classes, four distinct values, extracted rather than restated — so an edited class stays covered, and a deleted one trips the floor assertion instead of thinning the list in silence:

theme files	token
context-menu, dropdown-menu, editor-suggestion-menu	--max-height-popup-menu
input-menu, select-menu, select	--max-height-popup-list

The half it catches, and the half it does not

This is in the file's own comment rather than left implied, because the whole point here is that a green suite was certifying something it never checked — a guard that overpromises has the same disease.

Failure mode 2 — the token dropping out of :root — is caught exactly. Verified by deleting --max-height-popup-list from sizes.css: it reds the corresponding assertion and nothing else.

Failure mode 1 is caught only in its total form. Probed against the installed engine:

EMITTED  max-h-[min(var(--max-height-popup-list)!!,var(--reka-select-...))]
EMITTED  max-h-[min(var(--max-height-popup-list)]        ← unbalanced
EMITTED  max-h-[not a length]
refused  max-h-[]
refused  maxx-h-[200px]

Tailwind v4 does not validate the meaning of an arbitrary value. So the utility ceasing to exist, or a value going empty, is caught; a value that still parses but no longer means anything is not this file's to find. Worth knowing before anyone leans on this guard for more than it does.

On the estimate

Estimated at half a day, most of it deciding how much of the Tailwind entry to compile.

That part turned out to be the easy half — @import "tailwindcss" plus the entry as it stands, with a loadStylesheet that resolves the package's own imports from node_modules. Because it reads the installed package, a real engine upgrade moves this test rather than a copy of one.

The time went elsewhere, on two wrong turns worth recording:

• The first matcher built a RegExp from the candidate and reported "no rule emitted" for all six while the rules sat in the output. It had to escape for the regex and match text that is itself backslash-escaped, and got the depth wrong. Replaced by a literal indexOf over a selector built the way Tailwind escapes one.
• The !! mutation staying green briefly read as a broken guard. It was a broken mutation — Tailwind emits that class happily. Same shape as the lesson from test(stringified-props): scan the corpus once, outside the timed test #561: a mutation that fails to go red is a claim about the mutation before it is a claim about the test.

The compile runs once at module scope, not inside an it(), which is exactly the shape that flaked in #561. A the guard itself block pins that the matcher reports absence as well as presence.

No upstream angle: nuxt/ui compiles no CSS in its tests and has no --max-height-popup-* tokens — they are Air's.

---

Generated by Claude Code