Bestehende Tokens importieren, ohne etwas zu verlieren
Bevor du irgendeinem Token-Tool eine Datei anvertraust, die dir wichtig ist, mach ein Experiment: Importiere die Datei, ändere nichts, exportiere sie und vergleiche das Ergebnis per Diff mit dem Original. Der ganze Test dauert etwa fünf Minuten, und das Diff ist das Führungszeugnis des Tools — es zeigt genau, was das Tool als sein Eigenes betrachtet und was es stillschweigend umschreibt.
Design Tokens ohne Verlust zu importieren, läuft auf eine einzige Eigenschaft hinaus: Ein gut erzogenes Tool besitzt die Abschnitte, die es selbst erzeugt, und bewahrt alles andere, sodass Speichern→Laden→Speichern ein Fixpunkt ist — die Datei, die herauskommt, ist die Datei, die hineinging, außer dort, wo du eine Änderung angefordert hast. Ein Tool mit dieser Eigenschaft lässt sich schrittweise einführen; ein Tool ohne sie erzwingt eine Alles-oder-nichts-Migration. Dieser Artikel behandelt die Datei-Mechanik von Import und Re-Export; die weiteren Grundlagen findest du in unserem Leitfaden zu Design Tokens.
Warum ist der Import von Tokens beängstigend?
Weil eine echte Tokens-Datei selten nur das ist, was ein einziges Tool erzeugt
hat. Lass eine Datei ein Jahr in Produktion laufen, und sie sammelt
handgebaute Arbeit an: Component-Tokens, die jemand für eine echte Ausnahme
hinzugefügt hat, $extensions-Blöcke mit Plattform-Metadaten, die
Animations-Timings einer Kollegin, für die kein Generator ein Modell hat. Diese
Ansammlung ist die Datei bei ihrer Arbeit — eine Quelle, die mit dem System
wächst.
Das Angstszenario ist ein naives Tool, das auf diese Datei trifft. Ein naiver Import liest die Teile, die das Tool versteht; ein naiver Export erzeugt die ganze Datei neu aus dem, was gelesen wurde. Import → Export → die halbe Datei ist weg: der Animations-Abschnitt, die Extensions, die von Hand ergänzten Ausnahmen — alles, was das Tool nicht modelliert hat, gelöscht aus Versäumnis statt aus Absicht. Teams, die das einmal durchgemacht haben, lernen, das Tool von der echten Datei fernzuhalten und Tokens von Hand zu pflegen — was stillschweigend den Großteil dessen aufgibt, wozu das Tooling da war.
Was ist der Round-Trip-Vertrag?
Drei Klauseln. Erstens, Eigentum ist abschnittsweise: Das Tool erklärt, welche Teile der Datei es erzeugt — die Farbrampen, die Schriftgrößenskala, die semantischen Ebenen — und behandelt alles andere als fremdes Terrain. Zweitens, Bewahrung ist wörtlich: Fremde Abschnitte gehen unverändert durch, nicht „neu serialisiert, aber äquivalent”. Drittens, die Ausgabe ist kanonisch: Das Tool schreibt seine eigenen Abschnitte in einer stabilen Form und Reihenfolge, sodass sich zwei Exporte nur dort unterscheiden, wo sich Entscheidungen unterscheiden, und Diffs überprüfbar bleiben.
Das Eingangs-Experiment prüft alle drei auf einmal. Speichern→Laden→Speichern sollte ein Fixpunkt sein — ein Zustand, den die Operation auf sich selbst abbildet, im Sinne der Mathematik (Fixpunkt) — und der Round-Trip von Scale Composer ist genau darauf getestet: Eine importierte Datei wird wieder exportiert, wobei unangetastete Abschnitte intakt bleiben, und die kanonische Reihenfolge hält jedes nachfolgende Diff minimal.
Wie sieht ein bewahrter Abschnitt nach einem echten Zyklus aus?
Nimm eine Datei mit einem erzeugten Abschnitt und einem von Hand ergänzten:
{
"color": {
"brand": {
"600": { "$type": "color", "$value": "#2563eb" }
}
},
"motion": {
"duration-fast": { "$type": "duration", "$value": "150ms" },
"duration-slow": { "$type": "duration", "$value": "400ms" }
}
}Der color-Abschnitt ist Generator-Terrain; motion ist die handgebaute
Arbeit einer Kollegin — ein Farb-und-Skalen-Tool hat kein Konzept von Dauern.
Importiere die Datei, leite die Palette neu her
aus einer neuen Ausgangsfarbe, exportiere. Die color.brand-Einträge ändern
sich: brand-600 behält seinen Namen und speichert einen neuen Wert anstelle
des alten #2563eb — oklch(0.546 0.215 262.9) — mit der drumherum neu
hergeleiteten Rampe, und das Diff enthält genau diese Zeilen und nichts sonst.
motion kommt unverändert zurück, beide Timings intakt, immer noch an seinem
Platz.
Führe diesen Zyklus an einer importierten Datei in Scale Composer aus — lade eine DTCG-Datei, die Abschnitte enthält, die das Tool nicht erzeugt, passe die Ausgangsfarbe an und exportiere: Die Farbabschnitte werden neu hergeleitet, während die von Hand ergänzten Abschnitte unangetastet durchlaufen.
Was solltest du prüfen, bevor du einem Tool deine Datei anvertraust?
Vier Prüfungen, geordnet nach dem, was sie aufdecken:
- Der leere Round-Trip. Importieren, nichts ändern, exportieren, Diff. Akzeptable Unterschiede liegen nur in den Abschnitten, die das Tool erzeugt (kanonische Neu-Serialisierung); ein Diff, das irgendetwas anderes berührt, ist das Tool, das dir verrät, was es irgendwann verschlingen wird.
$extensionsüberleben. Der vom DTCG-Format vorgesehene Ort für Tool- und plattformspezifische Metadaten ist genau der Inhalt, den ein unachtsamer Importer verwirft. Prüfe, dass deine intakt durchgekommen sind.- Kommentare — ehrlich gesagt gibt es keine zu verlieren. DTCG ist JSON,
und JSON hat keine Kommentar-Syntax; Notizen, die zählen, gehören in
$description-Felder, die Teil des Formats sind und jedes konforme Tool überstehen. Falls dein Workflow Anmerkungen bisher an einem fragilen Ort aufbewahrt hat, ist der Import ein guter Moment, sie dorthin zu migrieren. - Stabilität der Reihenfolge. Exportiere zweimal, dann exportiere nach einer trivialen Änderung. Wenn die Schlüssel-Reihenfolge sich zwischen den Durchläufen umsortiert, begräbt jedes künftige Diff die echte Änderung unter Phantom-Änderungen, und das Überprüfen von Token-Änderungen wird zur Archäologie, solange die Datei lebt.
Wie macht Bewahrung die Einführung schrittweise?
Weil ein bewahrendes Tool nicht die ganze Datei verlangt. Ein Team kann ihm zuerst die Farbabschnitte übergeben — importieren, neu herleiten, exportieren, ein Diff überprüfen, das nur Farbe berührt — während Abstände und Typografie in derselben Datei von Hand gepflegt bleiben. Nächstes Quartal die Abstände. Das Tool wächst Abschnitt für Abschnitt in die Datei hinein, jeder Schritt eine kleine, überprüfbare Änderung statt eines Migrations-Ereignisses.
Das ist die praktische Auszahlung der Fixpunkt-Eigenschaft und der intuitive Grund, warum sie zählt: Vertrauen entsteht durch einen begrenzten Wirkungsradius. Ein Tool, das nur alles umschreiben kann, verlangt am ersten Tag totales Vertrauen; ein Tool, das bewahrt, verlangt Vertrauen nur für die Abschnitte, die du ihm übergibst, und die Abschnitte, die es sich noch nicht verdient hat, waren nie in Gefahr. „Token-Tool wechseln” ist keine Entscheidung mehr, sondern wird zu einer Reihe billiger, umkehrbarer Experimente.
Mach den Test, bevor du dem Tool vertrauen musst
Die Prüfung ist keine hypothetische Arbeit — sie sind fünf Minuten und ein Diff. Mach den Speichern→Laden→Speichern-Test in Scale Composer — importiere eine Tokens-Datei, exportiere sie unverändert und vergleiche; dann mach eine bewusste Änderung und bestätige, dass das Diff genau diese Änderung ist und nichts weiter.