fix(vibe-tests): disable lightningcss in report build — fixes missing styles - #558
Merged
Conversation
LightningCSS was lowering native light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) despite browser targets being set. These polyfill variables are never initialized in the report, causing all theme colors to be invisible. The pre-compiled CSS from @xds/core/dist/xds.css is already minified, so CSS minification in the report build is unnecessary.
meta-cla
Bot
added
the
CLA Signed
Contributor
PR Analysis Report📚 Storybook PreviewView Storybook for this PR 🧪 Sandbox PreviewView Sandbox for this PR No new or modified components detected. Bundle Size Summary
Accessibility AuditStatus: No accessibility violations detected. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
cixzhang
pushed a commit
that referenced
this pull request
Mar 11, 2026
![navi[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
Same fix as the report build (PR #558) — lightningcss mangles light-dark() into polyfill variables that never get set, causing XDS styles to be invisible in previews. The StyleX plugin already handles CSS extraction with proper targets. Setting cssMinify: false prevents Vite's build phase from running lightningcss again and breaking the output.
cixzhang
added a commit
that referenced
this pull request
Mar 15, 2026
… breakage LightningCSS lowers CSS light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) that are never initialized, silently breaking all XDS theming colors. This has bitten us 3 separate times (PRs #558, #566, #499) across different Vite configs. Changes: - apps/example-vite/vite.config.ts: add build.cssMinify: false - apps/storybook/vite.config.ts: add build.cssMinify: false - apps/example-vite/README.md: add lightningcss gotcha as top entry, detailed explanation section, and update inline config example - apps/example-nextjs/README.md: add awareness note (Next.js uses PostCSS so not directly affected, but warn about custom minifiers) Co-authored-by: Navi <navi@navibot.dev>
cixzhang
added a commit
that referenced
this pull request
Mar 15, 2026
… breakage (#623) LightningCSS lowers CSS light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) that are never initialized, silently breaking all XDS theming colors. This has bitten us 3 separate times (PRs #558, #566, #499) across different Vite configs. Changes: - apps/example-vite/vite.config.ts: add build.cssMinify: false - apps/storybook/vite.config.ts: add build.cssMinify: false - apps/example-vite/README.md: add lightningcss gotcha as top entry, detailed explanation section, and update inline config example - apps/example-nextjs/README.md: add awareness note (Next.js uses PostCSS so not directly affected, but warn about custom minifiers) Co-authored-by: Navi <navi@navibot.dev>
cixzhang
added a commit
that referenced
this pull request
Mar 15, 2026
LightningCSS lowers light-dark() into --lightningcss-light/--lightningcss-dark polyfill variables for older browsers. This polyfill actually works correctly IF the color-scheme declaration is in the same CSS file — lightningcss injects toggle variable initialization wherever it sees color-scheme. But when light-dark() and color-scheme are in separate files (as with XDS, where tokens are in xds.css but color-scheme is set by XDSTheme via StyleX), the polyfill vars are used but never defined, breaking all colors. Fix: include `color-scheme: light dark` in both xds.css and theme CSS output so the polyfill is self-contained. This makes XDS CSS compatible with any bundler that runs lightningcss regardless of target configuration. This reverts the cssMinify: false workarounds from PR #623 and earlier (PRs #558, #566) since they're no longer needed — the root cause is fixed. Co-authored-by: Navi <navi@navibot.dev>
cixzhang
added a commit
that referenced
this pull request
Mar 15, 2026
LightningCSS lowers light-dark() into --lightningcss-light/--lightningcss-dark polyfill variables for older browsers. This polyfill actually works correctly IF the color-scheme declaration is in the same CSS file — lightningcss injects toggle variable initialization wherever it sees color-scheme. But when light-dark() and color-scheme are in separate files (as with XDS, where tokens are in xds.css but color-scheme is set by XDSTheme via StyleX), the polyfill vars are used but never defined, breaking all colors. Fix: add `color-scheme: light dark` to: - reset.css — on :where(html), the canonical place for the declaration. Every XDS app imports this first. - build-css.mjs output (xds.css) — for consumers who import xds.css without reset.css - build-theme.mjs output (theme.css) — for theme files containing light-dark() values This makes XDS CSS compatible with any bundler that runs lightningcss regardless of target configuration. Reverts the cssMinify: false workarounds from PR #623 and earlier (PRs #558, #566). Co-authored-by: Navi <navi@navibot.dev>
cixzhang
added a commit
that referenced
this pull request
Mar 15, 2026
LightningCSS lowers light-dark() into --lightningcss-light/--lightningcss-dark polyfill variables for older browsers. This polyfill actually works correctly IF the color-scheme declaration is in the same CSS file — lightningcss injects toggle variable initialization wherever it sees color-scheme. But when light-dark() and color-scheme are in separate files (as with XDS, where tokens are in xds.css but color-scheme is set by XDSTheme via StyleX), the polyfill vars are used but never defined, breaking all colors. Fix: add `color-scheme: light dark` to: - reset.css — on :where(html), the canonical place for the declaration. Every XDS app imports this first. - build-css.mjs output (xds.css) — for consumers who import xds.css without reset.css - build-theme.mjs output (theme.css) — for theme files containing light-dark() values This makes XDS CSS compatible with any bundler that runs lightningcss regardless of target configuration. Reverts the cssMinify: false workarounds from PR #623 and earlier (PRs #558, #566). Co-authored-by: Navi <navi@navibot.dev>
cixzhang
added a commit
that referenced
this pull request
Mar 15, 2026
LightningCSS lowers light-dark() into --lightningcss-light/--lightningcss-dark polyfill variables for older browsers. This polyfill actually works correctly IF the color-scheme declaration is in the same CSS file — lightningcss injects toggle variable initialization wherever it sees color-scheme. But when light-dark() and color-scheme are in separate files (as with XDS, where tokens are in xds.css but color-scheme is set by XDSTheme via StyleX), the polyfill vars are used but never defined, breaking all colors. Fix: add `color-scheme: light dark` to: - reset.css — on :where(html), the canonical place for the declaration. Every XDS app imports this first. - build-css.mjs output (xds.css) — for consumers who import xds.css without reset.css - build-theme.mjs output (theme.css) — for theme files containing light-dark() values This makes XDS CSS compatible with any bundler that runs lightningcss regardless of target configuration. Reverts the cssMinify: false workarounds from PR #623 and earlier (PRs #558, #566). Co-authored-by: Navi <navi@navibot.dev>
cixzhang
added a commit
that referenced
this pull request
Mar 15, 2026
LightningCSS lowers light-dark() into --lightningcss-light/--lightningcss-dark polyfill variables for older browsers. This polyfill actually works correctly IF the color-scheme declaration is in the same CSS file — lightningcss injects toggle variable initialization wherever it sees color-scheme. But when light-dark() and color-scheme are in separate files (as with XDS, where tokens are in xds.css but color-scheme is set by XDSTheme via StyleX), the polyfill vars are used but never defined, breaking all colors. Fix: add `color-scheme: light dark` to: - reset.css — on :where(html), the canonical place for the declaration. Every XDS app imports this first. - build-css.mjs output (xds.css) — for consumers who import xds.css without reset.css - build-theme.mjs output (theme.css) — for theme files containing light-dark() values This makes XDS CSS compatible with any bundler that runs lightningcss regardless of target configuration. Reverts the cssMinify: false workarounds from PR #623 and earlier (PRs #558, #566). Co-authored-by: Navi <navi@navibot.dev>
cixzhang
added a commit
that referenced
this pull request
Apr 26, 2026
) LightningCSS was lowering native light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) despite browser targets being set. These polyfill variables are never initialized in the report, causing all theme colors to be invisible. The pre-compiled CSS from @xds/core/dist/xds.css is already minified, so CSS minification in the report build is unnecessary.
cixzhang
added a commit
that referenced
this pull request
Apr 26, 2026
… breakage (#623) LightningCSS lowers CSS light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) that are never initialized, silently breaking all XDS theming colors. This has bitten us 3 separate times (PRs #558, #566, #499) across different Vite configs. Changes: - apps/example-vite/vite.config.ts: add build.cssMinify: false - apps/storybook/vite.config.ts: add build.cssMinify: false - apps/example-vite/README.md: add lightningcss gotcha as top entry, detailed explanation section, and update inline config example - apps/example-nextjs/README.md: add awareness note (Next.js uses PostCSS so not directly affected, but warn about custom minifiers) Co-authored-by: Navi <navi@users.noreply.github.com>
cixzhang
added a commit
that referenced
this pull request
Jun 21, 2026
) LightningCSS was lowering native light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) despite browser targets being set. These polyfill variables are never initialized in the report, causing all theme colors to be invisible. The pre-compiled CSS from @xds/core/dist/xds.css is already minified, so CSS minification in the report build is unnecessary.
cixzhang
added a commit
that referenced
this pull request
Jun 21, 2026
… breakage (#623) LightningCSS lowers CSS light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) that are never initialized, silently breaking all XDS theming colors. This has bitten us 3 separate times (PRs #558, #566, #499) across different Vite configs. Changes: - apps/example-vite/vite.config.ts: add build.cssMinify: false - apps/storybook/vite.config.ts: add build.cssMinify: false - apps/example-vite/README.md: add lightningcss gotcha as top entry, detailed explanation section, and update inline config example - apps/example-nextjs/README.md: add awareness note (Next.js uses PostCSS so not directly affected, but warn about custom minifiers) Co-authored-by: Navi <navi@users.noreply.github.com>
cixzhang
added a commit
that referenced
this pull request
Jun 21, 2026
) LightningCSS was lowering native light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) despite browser targets being set. These polyfill variables are never initialized in the report, causing all theme colors to be invisible. The pre-compiled CSS from @xds/core/dist/xds.css is already minified, so CSS minification in the report build is unnecessary.
cixzhang
added a commit
that referenced
this pull request
Jun 21, 2026
… breakage (#623) LightningCSS lowers CSS light-dark() into polyfill variables (--lightningcss-light/--lightningcss-dark) that are never initialized, silently breaking all XDS theming colors. This has bitten us 3 separate times (PRs #558, #566, #499) across different Vite configs. Changes: - apps/example-vite/vite.config.ts: add build.cssMinify: false - apps/storybook/vite.config.ts: add build.cssMinify: false - apps/example-vite/README.md: add lightningcss gotcha as top entry, detailed explanation section, and update inline config example - apps/example-nextjs/README.md: add awareness note (Next.js uses PostCSS so not directly affected, but warn about custom minifiers)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Vibe test reports have no visible styles. All theme colors are invisible.
Root Cause
LightningCSS (used as
cssMinify) was lowering nativelight-dark()into polyfill variables (--lightningcss-light/--lightningcss-dark). These polyfill variables are never initialized in the report HTML, so all token values resolve to empty — making everything invisible.The
lightningcssTargetsconfig was supposed to prevent this, but lightningcss still loweredlight-dark()during CSS transformation.Fix
Disable CSS minification in the report build (
cssMinify: false). The pre-compiled CSS from@xds/core/dist/xds.cssis already production-ready.Also cleans up the resolve aliases to use regex-based matching for
@xds/coresubpath imports.Verification
Before:
--color-wash:var(--lightningcss-light,#f1f4f7)var(--lightningcss-dark,#111112)After:
--color-wash:light-dark(#F1F4F7, #111112)