Alpha — breaking changes ship without a deprecation cycle. What is built vs. planned
daisyUI exporter
Acme · Cathode · GOV.UK · Carbon. One page, four design systems, compiled to daisyUI. All 44 demos →
Emits daisyUI v5 theme blocks (Tailwind 4 era): one @plugin "daisyui/theme" block per color-scheme mode, OKLCH values, light as default, dark as prefersdark. This is standard daisyUI multi-theme behavior, generated from your design system.
On Acme: 92 declarations over the two blocks, over 26 classified rows.
"targets": { "daisyui": { "output": "dist/daisyui" } }/* your global CSS */
@import 'tailwindcss';
@plugin "daisyui" {
themes:
acme-design-system-light --default,
acme-design-system-dark --prefersdark;
}
@import './daisyui.transtyle.css';The interesting part: false friends, resolved correctly#
daisyUI’s secondary and accent are true brand roles, so this exporter maps them from secondary.solid and accent.solid. shadcn’s identically-named variables are subtle surfaces, so that exporter maps them from neutral.tint and accent.tint. Same design system, same words, opposite mapping decisions, both correct. That’s the pivot-language principle doing its job. Every role ships with its -content pair from <role>.on-solid, contrast-checked at derivation time.
Mapping table#
| daisyUI variable | Comes from | Note |
|---|---|---|
--color-base-100 / -200 |
elevation.0.surface / elevation.1.surface |
|
--color-base-300 |
border.base |
approximated. daisyUI wants a third bg-ramp step the IR doesn’t define (catalog watch item) |
--color-base-content |
text.base |
|
--color-{primary,secondary,accent,neutral,info,success,warning} + -content |
the same-named roles’ .solid + .on-solid grid cells |
brand-direct |
--color-error + -content |
danger.solid + danger.on-solid |
name translation |
--radius-{selector,field,box} |
radius.md |
one radius feeds three families, approximated |
--depth, --noise, --size-* |
— | dropped: stylistic effects without token semantics; daisyUI defaults apply |
daisyUI wants every role authored or derived, so coverage skews derived on minimal systems (Acme: 65% derived). The report shows exactly which roles you might want to author. Both examples ship daisyUI targets.
A slot’s own $description and $deprecated are written as comment lines above its variable in the light theme block.
Your own tokens (custom vocabulary)#
The theme block takes any custom property. So the semantic.* tokens you add outside the catalog are written into each theme too, named like the css-variables target names them: GOV.UK’s semantic.color.govuk.link becomes --color-govuk-link, native, with each theme’s own value. A composite (a shadow, a typography) has no single-value form there and is reported dropped. Set options.customTokens to "omit" to leave them all out; each is then dropped in report.json.
Custom roles (role archetypes)#
daisyUI’s color set is open: any --color-<name> custom property is a real Tailwind utility color. So a custom role declaring $extensions.transtyle.role (docs/architecture/ir.md’s role archetypes) gets --color-<name> + --color-<name>-content emitted alongside the built-ins, native. Cathode’s crt-amber role (archetype status) demonstrates this: it’s authored once, with no other bindings, purely to show the open-role-set path. Contrast Bootstrap/shadcn, whose closed sets can’t take it at all.
Contrast, motion and brand#
daisyUI picks a theme by name, so each brand and contrast combination is one more theme in the same file, named after its values with the defaults left out: acme-globex-light, acme-dark-more. Only the default pair keeps --default and --prefersdark; select the others with data-theme. daisyUI has no prefers-contrast switch, so contrast is reported approximated, and motion dropped (themes carry no duration).