dx-styles — Zero-runtime CSS-in-TS for design systems

Why dx-styles

Three guarantees you can build a design system on.

A small authoring surface, an aggressive build-time pipeline, and a framework-agnostic runtime. Designed to scale across applications without shipping a single byte of styling code to the browser.

The API

Five primitives. Everything you need for a design system.

Authoring stays in TypeScript. Composition is statically analyzable. Tab through the tagged APIs that participate in extraction — css, recipe, slotRecipe, createTheme — plus the runtime boundary assignVars. Each tab shows the declaration and the JSX that consumes it.

css()

Compose deterministic class names from style objects. Inputs are previously declared css() results, plain style objects, or public StyleHandle values.

1Declare

import { css } from "dx-styles";

const base = css({
  display: "inline-flex",
  alignItems: "center",
  gap: "8px",
});

export const button = css(base, {
  minHeight: "32px",
  paddingInline: "12px",
  borderRadius: "999px",
});

2Consume

export const Button = (props: ButtonProps) => (
  <button className={button} {...props} />
);

recipe()

Variant-driven runtime selector over statically compiled class groups. Default variants resolve at the call site without bundle-time conditionals.

1Declare

import { recipe } from "dx-styles";

export const button = recipe({
  base: { display: "inline-flex", alignItems: "center" },
  variants: {
    appearance: {
      primary: { backgroundColor: "var(--button-bg-primary)" },
      secondary: { backgroundColor: "var(--button-bg-secondary)" },
    },
    size: {
      sm: { minHeight: "28px", paddingInline: "10px" },
      md: { minHeight: "32px", paddingInline: "12px" },
    },
  },
  defaultVariants: { appearance: "primary", size: "md" },
});

2Consume

export const Button = ({ appearance, size, ...rest }: ButtonProps) => (
  <button className={button({ appearance, size })} {...rest} />
);

// renders class "button_root primary md"
<Button appearance="secondary" size="sm" />;

slotRecipe()

Multipart variant selector. Every slot is declared up front; each variant value updates the relevant slots only. Returns an object keyed by the declared slots.

1Declare

import { slotRecipe } from "dx-styles";

export const popover = slotRecipe({
  slots: ["root", "content", "arrow"] as const,
  base: {
    root: { position: "relative" },
    content: { borderRadius: "12px", padding: "12px" },
    arrow: { position: "absolute" },
  },
  variants: {
    tone: {
      neutral: { content: { backgroundColor: "var(--popover-bg)" } },
      danger:  { content: { backgroundColor: "var(--popover-bg-danger)" } },
    },
  },
  defaultVariants: { tone: "neutral" },
});

2Consume

import { popover } from "./popover.styles";

export const Popover = ({ tone, children }: PopoverProps) => {
  const slots = popover({ tone });
  return (
    <div className={slots.root}>
      <div className={slots.content}>{children}</div>
      <span className={slots.arrow} aria-hidden />
    </div>
  );
};

createTheme()

Token contracts produce stable CSS variable names. createTheme() emits a single themed class — apply it once at the root, swap themes by toggling classes, or scope per-subtree.

1Declare

import {
  createTheme,
  createTokenContract,
} from "dx-styles";

export const buttonTokens = createTokenContract(
  { background: null, foreground: null, focus: null },
  { prefix: "button" },
);

export const buttonTheme = createTheme(buttonTokens, {
  background: "#0057ff",
  foreground: "#ffffff",
  focus: "#7aa2ff",
});

2Consume

import { buttonTheme } from "./button-theme";

export const ThemedSection = ({ children }: Props) => (
  <section className={buttonTheme}>
    {/* every nested .button reads var(--button-background) */}
    {children}
  </section>
);

assignVars()

The runtime escape hatch for dynamic values. assignVars() returns inline style props bound to a token contract — typed, scoped to a subtree, and free of generated CSS rules.

1Declare

import {
  assignVars,
  createTokenContract,
} from "dx-styles";

export const layoutVars = createTokenContract(
  { rowHeight: null, columnWidth: null },
  { prefix: "grid-layout" },
);

export const layoutInline = (height: string, width: string) =>
  assignVars(layoutVars, {
    rowHeight: height,
    columnWidth: width,
  });

2Consume

import { layoutInline } from "./grid-layout";

export const Grid = ({ rowHeight, columnWidth, children }: Props) => (
  // dynamic dimensions cross the boundary as variables, not new rules.
  <div style={layoutInline(rowHeight, columnWidth)}>
    {children}
  </div>
);

// no new CSS — just two custom-property assignments on the element.

Live demo

The same recipe, every component below.

These site-local spike components are rendered with the recipes you see on the right. No runtime style insertion: open the network tab and the CSS arrived as a static asset.

Button · styleMode

Button · size

Checkbox · appearance

Default · uncheckedDefault · checkedIndeterminate

What you're seeingEvery variant on this page is a precompiled class. The component just selects between them — there is no style object passed at runtime, no provider in the tree.

From apps/site/src/spike/components/Button.styles.ts

import { recipe } from "dx-styles";

import { siteTokens } from "../theme";

export const buttonRoot = recipe({
  base: {
    display: "inline-flex",
    alignItems: "center",
    justifyContent: "center",
  },
  variants: {
    size: {
      small:  { minHeight: "24px", paddingInline: "8px"  },
      medium: { minHeight: "32px", paddingInline: "12px" },
      large:  { minHeight: "40px", paddingInline: "16px" },
    },
    styleMode: {
      contained: { backgroundColor: siteTokens["color-accent-strong"] },
      outline:   { backgroundColor: "transparent" },
      text:      { backgroundColor: "transparent" },
    },
  },
});

Theme studio

One base color. A live OKLCH scheme.

Pick a seed color and the site recomputes a balanced dark token set at runtime. Static extraction still owns the CSS rules; the picker only assigns typed CSS variables at the root boundary.

OKLCH · assignVars

The base hue drives accents, borders, cards, and dark surfaces. Every section keeps reading the same token contract, so the whole page shifts without regenerating rules or adding a provider.

#7C8CFFoklch(0.681 0.169 275)

import { assignVars } from "dx-styles";

const palette = getSitePalette(baseColor);
const vars = assignVars(siteTokens, palette);

for (const [name, value] of Object.entries(vars)) {
  document.documentElement.style.setProperty(name, String(value));
}

// The fallback createTheme() class stays mounted.
// Runtime variables only override the token values.

Runtime surface

Tokens follow the base hue

base=#7c8cff

ContainedOutlineText

Surface

Accent

Success

Warning

Border

theme fallbackoklch paletteruntime vars

How it works

What you author is exactly what ships.

A small build-time pipeline turns tagged calls into deterministic class names and CSS sidecars. The runtime only chooses between precompiled classes — no string concatenation at runtime, no style object serialization.

Step 1 · author

Tagged calls in TS/TSX

Type-safe authoring with recipe(), slotRecipe(), css(). Keep them inline next to a component, or split into a colocated *.styles.ts — the extractor treats both the same.

recipe(...) · slotRecipe(...) · css(...)

Step 2 · extract

WyW-in-JS transform

Tagged calls are evaluated at build time. Variant matrices compile to deterministic class groups; RTL-flippable rules emit their mirrored sibling.

processors/recipe.cts

Step 3 · ship

*.css sidecars

Built modules import generated CSS through the normal module graph. Bundler tree-shakes unused selectors. Runtime cost is a single cx() call.

sideEffects: ["**/*.css"]

No runtime renderer. No provider. No hydration mismatch surface.framework-agnostic

Developer experience

When the styling layer is honest, debugging is a grep away.

Static extraction makes the styling pipeline auditable. dx-styles ships first-class tooling so you can answer the questions that actually come up: where did this class come from, why is the variant name wrong, and what changed between builds.

class    button_bhhycyd__appearance-primary
source   button/styles.ts:14:5
symbol   button · recipe()
variant  appearance="primary"
compose  ← focusRing.ts:7  (css)
         ← styles.ts:18    (recipe.base)
css
  background: var(--button-bg-primary);
  border-color: transparent;
  color: var(--button-fg-primary);

warning  use logical "insetInlineEnd"
         instead of "right"
         so the rule follows document
         direction.

  Pipeline.tsx:78
  >  77 | position: "absolute",
     78 | right: "-14px",
        | ^^^^^

button({ size: "xl" });
//      ~~~~~~~~~~~~
//   Type '"xl"' is not assignable
//   to '"sm" | "md"'.

button({ tone: "danger" });
//       ~~~~
//   Property 'tone' does not exist
//   on type ButtonVariants.

import {
  createRecipeStyleHandles,
  css,
} from "dx-styles";

import { button } from "./Button.styles";

const buttonHandles = createRecipeStyleHandles(button);

// Layer overrides on the public handle —
// no source fork, no specificity ladder.
export const compactButton = css(buttonHandles.root, {
  minHeight: "24px",
  paddingInline: "8px",
});

deterministic by design

Class names are stable. Diffs are reviewable. Snapshots survive refactors.

Same input, same hash. CSS diffs in code review reflect real authoring changes — not bundler order or runtime evaluation. Snapshot tests stop being a liability.

- .button_bhhycyd__size-md { min-height: 32px; ... }
+ .button_bhhycyd__size-md { min-height: 32px; ...
+   padding-inline: var(--button-spacing-md); }

Wire the extractor once. Author the rest as TypeScript.

Add the package, drop the matching @wyw-in-js/* plugin into your bundler (Vite, webpack, Rollup, esbuild, Next; see the WyW-in-JS bundler guide), and start authoring. Tokens, themes, and RTL rules stay in TypeScript modules and compile into static CSS artifacts.

Read the docs Bundler integration View on GitHub

bun add dx-styles

// Pick the WyW-in-JS plugin for your bundler:
//   @wyw-in-js/vite      @wyw-in-js/webpack
//   @wyw-in-js/rollup    @wyw-in-js/esbuild
//   @wyw-in-js/next
bun add -d @wyw-in-js/vite

// vite.config.ts - same options across plugins
import wyw from "@wyw-in-js/vite";
export default {
  plugins: [wyw()],
};

// Component.tsx - inline or in a colocated *.styles.ts
import { recipe } from "dx-styles";

dx-styles · compiler-backed CSS for TypeScript.Statically extracted. Framework-agnostic. RTL-aware.

CSS-in-TS that compiles away

Three guarantees you can build a design system on.

Five primitives. Everything you need for a design system.

The same recipe, every component below.

One base color. A live OKLCH scheme.

What you author is exactly what ships.

Tagged calls in TS/TSX

WyW-in-JS transform

*.css sidecars

When the styling layer is honest, debugging is a grep away.

Explain any class — name to source.

Source-linked diagnostics at build time.

Variant typos fail in the editor.

Extend recipes without forking.

Class names are stable. Diffs are reviewable. Snapshots survive refactors.

Wire the extractor once. Author the rest as TypeScript.