DESIGN.md-Validator

Das YAML-Frontmatter, die erforderliche Primärfarbe, ob Farben in einem Farbformat angegeben sind (Hex, rgb, hsl, oklch, ein Farbname und Ähnliches), Schriftgrößen und Radien in px, em oder rem, Typografie-Eigenschaften, Komponenteneigenschaften und ihre Token-Referenzen (auch Referenzen ohne Anführungszeichen, die YAML nicht als Text liest), die omitted-Liste, doppelte oder falsch angeordnete Abschnitte sowie den Kontrast zwischen Text- und Hintergrundfarbe jeder Komponente gegen das WCAG-AA-Minimum von 4,5:1. Fehler machen die Datei ungültig; Warnungen weisen auf Dinge hin, die du beheben solltest.

Nein. Die Prüfung läuft komplett in deinem Browser: Der eingefügte Text oder die gewählte Datei wird nie an unsere Server gesendet. Die einzigen Anfragen der Vorschau betreffen Font-Stylesheets: Unser Server lädt sie von Google Fonts, und sie enthalten nur die Namen der Schriftfamilien aus deinen Typografie-Tokens.

Googles DESIGN.md-Format, wie es Stitch nutzt und wie es im Repository google-labs-code/design.md veröffentlicht ist. Der Validator wendet dieselben Regeln an, mit denen Design Extractor jede erzeugte DESIGN.md prüft, plus eine Kontrastprüfung der Komponentenfarben.

Eine Referenz wie "{colors.brand}" muss ein Token nennen, das im Frontmatter existiert, hier einen brand-Eintrag unter colors. Ergänze das fehlende Token oder lass die Referenz auf ein vorhandenes zeigen. Setze Referenzen in Anführungszeichen: YAML liest ein {colors.brand} ohne Anführungszeichen als Mapping, nicht als Text.

Ja. Googles Open-Source-Kommandozeilentool prüft eine Datei in deiner Pipeline: Führe npx @google/design.md lint DESIGN.md aus. Es gibt einen JSON-Bericht aus und endet mit Code 1, wenn es Fehler findet, sodass der Job bei einer fehlerhaften Datei fehlschlägt. Seine Regeln überschneiden sich mit dieser Seite, aber manche Schweregrade unterscheiden sich.