Style Dictionary vs. direkter Export

Zwei Token-Setups, nebeneinander. Das erste ist ein Repository mit einem build/-Verzeichnis: eine Style-Dictionary-Konfiguration, eine Liste eigener Transforms, eine npm-Abhängigkeit mit eigenen Release Notes und Output-Ziele für Web, iOS, Android und eine Dokumentationsseite. Das zweite ist ein Generator, dessen Export-Panel CSS, ein Tailwind-Theme und Figma Variables direkt schreibt, wobei die Tokens-Datei neben dem Code committet wird und es überhaupt keinen Build-Schritt gibt. Kein Team macht es falsch — sie haben nur unterschiedlich geformte Probleme.

Style Dictionary ist eine Transform-Pipeline: Es nimmt eine Token-Quelldatei und schickt sie durch konfigurierbare Transforms und Formate, um jedes beliebige Ziel auszugeben, das du definierst. Direkter Export bedeutet, dass das erzeugende Tool die gängigen Formate selbst ausgibt — ohne Pipeline, die konfiguriert werden muss. Die Pipeline ist der richtige Weg, wenn du viele oder maßgeschneiderte Ziele hast; der direkte Export ist der richtige Weg, wenn die üblichen Web-Ziele dich abdecken — und weil eine kanonische DTCG-Datei später eine Pipeline speisen kann, sperrt die Entscheidung für direkten Export heute die Pipeline morgen nicht aus.

Das ist das Tooling-Kapitel unseres Design-Tokens-Leitfadens: was jeder Weg tatsächlich ist, ein ehrlicher Vergleich und derselbe Token auf beiden Wegen verfolgt.

Was ist Style Dictionary?

Das kategoriedefinierende Open-Source-Tool für Token-Transformation, dokumentiert unter styledictionary.com — wenn Token-Build-Pipelines zur Sprache kommen, ist es meist der Bezugspunkt, und es ist eher ergänzende Infrastruktur als ein Konkurrent zu irgendeinem Generator. Es ist kein Design-Tool: Es hat keine Meinung dazu, wie deine Werte aussehen sollten, und keine Oberfläche, um sie zu entscheiden. Es konsumiert eine Token-Quelle, schickt jeden Token durch Transforms — Umbenennen in die Schreibweise einer Plattform, Umrechnen von Einheiten, Neuformatieren von Farben für die Syntax des Ziels — und übergibt die Ergebnisse an Formate, die die Zieldateien schreiben: CSS Custom Properties, Sass-Maps, Swift-Konstanten, Android-Ressourcen-XML, JSON für eine Doku-Seite. Jede Fuge ist konfigurierbar, und eigene Transforms sind ganz normaler Code, den du schreibst und besitzt.

Diese Form macht sein Heimatterrain deutlich: viele Ziele, plattformspezifische Namensregeln, eine bestehende Build-Pipeline, in die es sich einfügt. Es läuft als Build-Schritt, und Plattform-Teams behandeln es auch so.

Was ist direkter Export?

Das Tool, das das System erzeugt hat, schreibt auch die Consumer-Formate. Der Scale Composer arbeitet so: Er leitet Schrift, Abstände, Farbrampen und helle/dunkle semantische Rollen aus einer gemeinsamen Skala ab und exportiert dann eine kanonische DTCG-Tokens-Datei zusammen mit CSS Custom Properties, einem Tailwind-v4-@theme-Block und Figma Variables, wobei hex neben dem OKLCH mitgeführt wird — keine Konfiguration, keine Build-Abhängigkeit, nichts zu pflegen außer dem Output selbst.

Die ehrliche Grenze ist die Speisekarte: Der direkte Export deckt die Formate ab, die er abdeckt. Für die meisten Web-Produkte — ein Stylesheet, ein Utility-Theme, eine Design-Datei — ist die Speisekarte die ganze Mahlzeit. Aber ein Ziel, das nicht auf der Speisekarte steht, lässt sich nicht per Konfiguration hinzufügen, weil es keine Konfiguration gibt; genau dort beginnt das Territorium der Pipeline.

Wie schneiden die beiden Wege im Vergleich ab?

Die Tabelle ist in beide Richtungen ehrlich. „Jedes Ziel” ist echte Macht, die echte Verantwortung kostet — die Konfiguration, die Transforms und die Abhängigkeits-Updates gehören jemandem in deinem Team. „Kein Setup” ist eine echte Ersparnis, die eine feste Speisekarte erkauft. Keine Spalte dominiert; die entscheidende Zeile ist meist die unterste.

Öffne die direkten Exporte nebeneinander im Scale Composer — ein erzeugtes System, gleichzeitig gerendert als DTCG-Datei, CSS Custom Properties, Tailwind-Theme und Figma Variables.

Musst du dich entscheiden?

Oft nicht — und das ist der zentrale Punkt dieses Artikels: Weil der kanonische Output des Scale Composer standardkonformes DTCG ist, ist die Datei, die der direkte Export erzeugt, eine gültige Quelle für eine Transform-Pipeline. Nutze den direkten Export für den Alltags-Loop — entscheiden, exportieren, committen, konsumieren. An dem Tag, an dem eine native App auf der Roadmap landet, richtest du die Quelle von Style Dictionary auf dieselbe committete Datei und fügst die neuen Ziele hinzu; nichts wird neu geschrieben und der Alltags-Loop ändert sich nicht. Das Austauschformat ist es, das die beiden Wege kombinierbar statt exklusiv macht — der Lohn dafür, sich auf DTCG zu standardisieren statt auf den privaten Dialekt irgendeines Tools.

Lock-in scheitert in beide Richtungen. Verlässt du den Generator, bleibt die DTCG-Datei ein gültiger Pipeline-Input. Führst du den Generator spät ein, importiert er eine bestehende DTCG-Datei und bewahrt die Abschnitte, die er nicht selbst erzeugt über den Round-Trip hinweg.

Wann bist du dem direkten Export allein entwachsen?

Drei Signale — jedes einzelne davon reicht aus:

1. Ein Ziel, das die Eingebauten nicht abdecken. Native App-Ressourcen, Variablen für E-Mail-Templates, eine gethemte Doku-Seite — alles, was eine Dateiform braucht, die die Export-Speisekarte nicht bietet.
2. Namens-Transforms pro Plattform. Das Web will --color-accent, Android will color_accent, iOS will colorAccent — systematisches Umbenennen pro Ziel ist die definierende Aufgabe der Pipeline.
3. Dokumentations-Generierung. Wenn die Tokens-Datei auch Referenzseiten erzeugen soll, sind die Docs nur ein weiteres Format-Ziel.

Beachte die Form des Schritts, wenn ein Signal eintritt: Hinzufügen, nicht Migrieren. Die Pipeline konsumiert die Datei, die der Alltags-Loop ohnehin schon erzeugt.

Wie sieht derselbe Token auf jedem Weg aus?

Nimm eine semantische Entscheidung — accent referenziert brand-600, worin #2563eb, oklch(0.546 0.215 262.9) gespeichert ist.

Direkter Weg. Der CSS-Export schreibt die aufgelöste Custom Property:

:root {
  --accent: #2563eb; /* semantic.accent → color.brand.600 */
}

Pipeline-Weg. Eine Konfiguration — hier nur in ihrer Form skizziert; die genaue API steht in der Doku des Tools — zeigt auf dieselbe kanonische Datei und fragt nach einem Ziel der Android-Klasse:

// Style-Dictionary-Konfiguration, Form nicht wortgetreu
{
  source: ["design-tokens.json"],   // kanonischer Export des Scale Composer
  platforms: {
    android: {
      transforms: ["name → snake_case", "color → #AARRGGBB"],
      files: [{ format: "android/resources", destination: "colors.xml" }]
    }
  }
}

und gibt eine Ressource der colors.xml-Klasse aus:

<color name="semantic_accent">#FF2563EB</color>

Dieselbe Entscheidung, zwei Renderings: Aus Punkten wurden Bindestriche und eine Custom Property auf dem einen Weg, snake_case und Alpha-first-hex auf dem anderen. Der Wert ist auf beiden identisch, weil beide Wege dieselbe Quelle lesen — das ganze Argument, sichtbar in drei Zeilen Output.

Beginne bei der Datei, die beide Wege teilen

Welcher Weg heute auch passt — er beginnt beim selben Artefakt. Exportiere die kanonische DTCG-Tokens-Datei aus dem Scale Composer — die direkten Exporte daneben für den Alltags-Loop, und die Datei selbst bereit, an dem Tag zur Quelle einer Pipeline zu werden, an dem ein neues Ziel auftaucht.