Learn Tailwind CSS - Design Tokens & Design System Integration

#Introduction

As projects grow, the need for a single source of truth for design becomes critical. In episode 10 we cover design tokens: storing them in tailwind.config.js, exposing them as CSS variables, syncing from Figma, and building a consistent component library.

A good design system means teams stop arguing about #3b82f6 versus #2563eb. All values live in one place, managed jointly between design and engineering, and are accessed through consistent names everywhere.

#Storing Tokens in the Config and Exposing via CSS Variables

Define tokens as CSS variables in the root stylesheet:

Tokens as CSS variables

:root {
  --color-brand: #3b82f6;
  --color-surface: #ffffff;
  --space-card: 1rem;
  --radius-card: 0.5rem;
}

Then wire them into the config:

Wiring tokens into config

theme: {
  extend: {
    colors: {
      brand: "var(--color-brand)",
      surface: "var(--color-surface)",
    },
    spacing: {
      card: "var(--space-card)",
    },
    borderRadius: {
      card: "var(--radius-card)",
    },
  },
},

This combination gives two advantages: utilities like bg-brand and p-card are created, and the underlying values can still be changed at runtime through CSS. This colors: { brand: "var(--color-brand)" } pattern is the bridge between static config and dynamic theming.

#Figma Sync and Tools

Figma and Tailwind don't talk to each other automatically. A common workflow:

1. Tokens are designed in Figma using a plugin like Tokens Studio.
2. The plugin exports the tokens to JSON format.
3. The JSON is transformed into part of the config or CSS variables.

A simple JSON token example:

{
  "color": {
    "brand": "#3b82f6",
    "surface": "#ffffff"
  },
  "spacing": {
    "card": "1rem"
  }
}

Tools like Style Dictionary can turn JSON tokens into various outputs — including :root CSS variables or Tailwind config snippets. This flow makes Figma the source of truth, with the Tailwind config as its derivative.

#Building a Consistent Component Library

A component library starts from small, consistent decisions. First, standardize patterns with @apply in the components layer:

Standard component patterns

@layer components {
  .btn {
    @apply inline-flex items-center justify-center rounded-card bg-brand px-4 py-2 font-medium text-white;
  }
  .card {
    @apply rounded-card border border-gray-200 bg-surface p-card shadow-sm;
  }
}

Then wrap them with a component API in your framework — for example a Button component in React or Svelte — that provides variants and a class slot. To publish as a package, follow these steps:

npm init -y
npx tsc --init

A common package structure: a src folder with components, a styles folder with CSS that includes @tailwind and @layer components, and a tailwind-preset.js that exports the tokens. Consumers just install it and register the preset in their config:

Consumer using a library preset

module.exports = {
  content: ["./node_modules/@org/ui/**/*.{js,jsx}"],
  presets: [require("@org/ui/tailwind-preset")],
};

This presets: [require("@org/ui/tailwind-preset")] pattern is what spreads one design language across many applications.

#Conclusion

Episode 10 took you to the design system level: storing tokens in the config, exposing them as CSS variables, syncing from Figma, and building a component library that can be published and used across projects.

Key takeaways:

• CSS variables are the bridge between static config and dynamic theming.
• Wire tokens into the config using var(...) values.
• Figma to code must be one-way so they don't drift apart.
• JSON tokens can be transformed with Style Dictionary.
• Standardize component patterns with @apply and @layer components.
• Tailwind presets let a design language be shared across projects.

Next, in episode 11, we'll cover handling dynamic content & security — the risks of dynamic classes from user input, validation and safelist patterns, avoiding injection via class names, and content scanning strategies for multi-tenant environments.