Summary
When a theme color is defined as a nested object with a DEFAULT key (the Tailwind convention), the DEFAULT variant never generates a rule. Numbered/named sub-keys work fine, and flat string keys work fine — only DEFAULT is dropped, silently.
Version: @cwcss/crosswind 0.2.4, Bun 1.3.13, macOS arm64
Reproduction
import { CSSGenerator, defaultConfig } from '@cwcss/crosswind'
const gen = new CSSGenerator({
...defaultConfig,
theme: {
...defaultConfig.theme,
extend: {
colors: {
brand: { DEFAULT: 'var(--brand)', 2: 'var(--brand-2)' },
},
},
},
})
gen.generateBatch(['bg-brand', 'text-brand', 'bg-brand-2'])
console.log(gen.toCSS(false, false))Actual output
.bg-brand-2 {
background-color: var(--brand-2);
}bg-brand and text-brand produce nothing — no rule, no warning.
Expected output
.bg-brand {
background-color: var(--brand);
}
.text-brand {
color: var(--brand);
}
.bg-brand-2 {
background-color: var(--brand-2);
}Workaround
Flatten the palette to string keys — these all generate correctly:
colors: {
'brand': 'var(--brand)',
'brand-2': 'var(--brand-2)',
}Notes
- Affects every utility prefix tried (
bg-,text-,border-), and hover/focus variants of theDEFAULTform are likewise missing. - The same shape works in Tailwind, where
brand: { DEFAULT: ... }makesbg-brandresolve to theDEFAULTvalue, so configs ported from Tailwind break silently — in our app this surfaced as a login page with a white background and an invisible submit button, sincebg-bg,text-text, andbg-accentwere allDEFAULTvariants.