Part 18 of a design tokens workflow series, this guide explains how to split design tokens by component and use Style Dictionary to generate per-component CSS and Sass files. It covers directory structure options (centralised vs. co-located tokens), creating component token files, configuring Style Dictionary for per-component output, naming conventions, semantic token referencing, and combining per-component files with CSS @layer for specificity control. A working example is available in the accompanying GitHub repository.
Table of contents
Why It's Worth DoingDirectory Structure for Component TokensAn Alternative: Co-locating Tokens with ComponentsCreating Component Token FilesConfiguring Style Dictionary for Per-Component OutputOutput StructureIntegration with Component LibrariesA Few Things Worth RememberingCombining Per-Component Files with CSS @layerConclusionQuestions this post answers
How do I configure Style Dictionary to generate separate CSS and Sass files for each component?
Style Dictionary can be configured with per-component sources and destinations so each component gets its own output files. You define a source glob scoped to each component's token file, then set the destination to a path like `button.tokens.css` and `button.tokens.scss` using the `css/variables` and `scss/variables` formats respectively. A working example is available in the Style Dictionary Starter repository on the `18-component-tokens` branch. Teams building modular design systems track Style Dictionary patterns like this on daily.dev.
Should component design tokens reference base tokens or semantic tokens?
Component tokens should reference semantic tokens, not base tokens. Pointing to a value like `{color.semantic.primary}` means a system-wide change to that semantic token automatically updates every component that references it, without touching individual component files. Referencing base tokens directly bypasses this indirection and makes global updates harder to propagate consistently. Developers maintaining design token architectures find discussions on token layering strategies on daily.dev.
What are the trade-offs between centralised and co-located design token files in a component library?
Centralised tokens in `src/tokens/` work best when a dedicated design token team owns the system — everything is discoverable in one place. Co-located tokens (stored alongside component code) suit multi-team setups where each team owns a component end-to-end, reducing coordination overhead and preventing stray files. A hybrid approach keeps base and semantic tokens central while component tokens live with their components. Developers deciding on design system architecture find real-world comparisons like this on daily.dev.