From Figma to React component in 5 steps - and half the glue from before is no longer needed

Half of my token pipeline disappeared in one year

A year ago, my pipeline from a Figma design token to a React component included a fair amount of plumbing: a JavaScript configuration file that re-exposed the tokens, constants imported manually into each component, a theme provider that juggled it all. Today, half of this code has disappeared from my projects - not because I've found a trick, but because the ecosystem has caught up with the need. Tailwind v4, released in January 2025, now exposes all tokens as default CSS variables via its CSS-first configuration. The W3C Design Tokens specification reached its first stable version on October 28, 2025. When tooling absorbs your plumbing, hanging on to your old pipeline becomes debt, not mastery.

The basic contract, on the other hand, has not changed: a design token is a vocabulary shared between Figma and the code that leaves no room for interpretation. When a designer sets color/action/primary in Figma, the developer knows exactly which variable to use. What has changed is the amount of code that needs to be written to bring this contract to life. Here are the five steps as I practice them in 2026, with what I've kept and what I've discarded.

Step 1 - Structuring variables in Figma

It all starts with a rigorous variable hierarchy, and it hasn't lost any of its importance - in fact, it's what makes everything else possible, including AI readability. I create three collections: primitives (raw values, hexes and pixels), semantics (contextual aliases such as surface/primary or text/on-primary), and component tokens (button/padding-md, card/radius). This three-level hierarchy allows you to toggle an entire theme by touching only the primitive layer.

The naming convention must be translated unchanged into the CSS path: color/surface/primary becomes --color-surface-primary. For types that Figma doesn't handle natively - composite shadows, full typography, transitions - the Tokens Studio plugin remains indispensable, and exports directly in DTCG-compliant JSON format. Important detail since late 2025: Figma added native import/export of variables in November 2025, precisely in line with the spec stable. For simple systems, this further reduces dependence on third-party plugins.

Step 2 - Export in stable Design Tokens format

This is where the most important update takes place. The article I would have written last year would have told you that the W3C spec was in "Second Editor's Draft" - a moving draft on which I personally rebuilt pipelines more than once. That's all over now: version 2025.10, published on October 28, 2025, is stable, neutral and supported by more than ten tools. In concrete terms, the format is richer and more precise than before. A color is no longer a simple hexadecimal string, but an object carrying its color space - Display P3, Oklch, the whole of CSS Color Module 4 are now covered - with its components, alpha and a hexadecimal fold. Dimensions and durations become structured objects with value and unit.

Two export options: Tokens Studio with integrated Git synchronization, or the Figma Variables REST API for CI/CD-connected programmatic export. For a mature project, I prefer the latter - the JSON file is versioned in the repository and follows the evolution of the tokens with the same rigor as the code. The key point: this file is your source of machine truth, and it must be clean, because everything that follows depends on it.

Step 3 - Transforming with Style Dictionary v5

Style Dictionary converts this JSON into what your stack needs. Version 5, aligned with spec 2025.10, has replaced the v4 that most tutorials were still talking about: its default export format is now JSON DTCG, its transformations natively handle the new color and dimension object types, and it requires Node 22. If you're running v4 on an old format, you're not broken, but you're accumulating a debt that will be paid off at the next theme refactor.

It was also at this stage that my plumbing melted. I used to output a CSS file, a JavaScript constant file and documentation. Today, I mostly generate a block of CSS custom properties - because step 4 will consume them directly, without going back through a JavaScript config file. The expand functionality remains valuable: a composite token of the typography type is automatically broken down into sub-tokens (fontFamily, fontSize, fontWeight, lineHeight), each generating its own variable. I keep JS constants only for the rare components that need programmatic access to values.

Step 4 - Plugging React components into Tailwind v4

This is the step that has changed the most. Tailwind v4 has abandoned the tailwind.config.js file in favor of CSS-first configuration: you declare your tokens in an @theme block, and Tailwind transforms them into utilities while exposing them as CSS variables at runtime.

CSS @theme { --color-surface-primary: #0b1020; --color-action-primary: #2f6bff; --radius-card: 12px; --font-display: "Inter", sans-serif; }

In other words, the output of Style Dictionary feeds directly into @theme, which becomes the sole source of truth for code-side tokens. No more JS config files to synchronize by hand, no more re-exported constants: the token defined once can be inspected in the browser's DevTools and overloaded at runtime. The new engine, built on Lightning CSS, speeds up complete builds by a factor of five - not the main argument, but a pleasant one.

The components themselves use only these tokens. For light/dark, I rely on React 19 - stable since December 2024, and in version 19.2.7 at the time of writing - with a minimalist theme provider that toggles custom properties, detects system preferences and persists the choice. Server Components, now standardized, change where this provider lives, but not the principle.

:::callout{type="warning" title="No hard-coded values"}
No hard-coded values in a component. A single #hex color written by hand, and you create a point that neither theming nor AI can follow.
:::

## Step 5 - Close the loop with Code Connect

The last step reconnects the code to Figma. The .figma.tsx files live next to your React components in the repository, and the figma.connect() API maps each Figma component to its JSX equivalent.

tsx
import figma from "@figma/code-connect";
import { Button } from "./Button";

figma.connect(Button, "https://figma.com/design/...?node-id=1-23", {
  props: {
    label: figma.string("Label"),
    variant: figma.enum("Variant", { Primary: "primary", Ghost: "ghost" }),
    disabled: figma.boolean("Disabled"),
  },
  example: ({ label, variant, disabled }) => (
    <Button variant={variant} disabled={disabled}>{label}</Button>
  ),
});

Props mappings use figma.string() for texts, figma.boolean() for toggles, figma.enum() for variants, figma.instance() for subcomponents, and figma.className() to map directly to Tailwind classes - handy with a v4 stack. Workflow is orchestrated in CLI:

``bash figma connect create figma connect publish

The new 2025 feature that lowers the barrier is Code Connect UI: you connect Figma to a GitHub repository from the interface, with AI suggestions to find the right file to map, without writing any config. I've long reserved Code Connect for platform teams; this version makes it viable for a one-person studio. Tools like Anima, Locofy.ai or Builder.io Visual Copilot generate a first draft of code from mock-ups, and they've gotten better - but to maintain synchronization over time, Code Connect remains the reliable piece. At the end of the pipeline, when a dev inspects a component in Dev Mode, he sees the project's real code. The Figma → React gap can't be bridged in a single jump: it's being bridged token by token, and now with half as much plumbing as a year ago.