Validateur DESIGN.md

Le front matter YAML, la couleur primary obligatoire, l’écriture des couleurs dans un format de couleur (hex, rgb, hsl, oklch, un nom de couleur, etc.), les tailles de police et les rayons en px, em ou rem, les propriétés typographiques, les propriétés des composants et leurs références de tokens (y compris les références sans guillemets, que YAML ne lit pas comme du texte), la liste des sections omises, les sections en double ou dans le désordre, et le contraste entre les couleurs de texte et de fond de chaque composant par rapport au minimum WCAG AA de 4.5:1. Les erreurs rendent le fichier invalide ; les avertissements signalent ce qui mérite d’être corrigé.

Non. La validation s’exécute entièrement dans votre navigateur : le texte que vous collez ou le fichier que vous choisissez n’est jamais envoyé à nos serveurs. Les seules requêtes de l’aperçu concernent les feuilles de style des polices : notre serveur les récupère sur Google Fonts, et elles ne contiennent que les noms de familles de polices de vos tokens de typographie.

Le format DESIGN.md de Google, tel qu’utilisé par Stitch et publié dans le dépôt google-labs-code/design.md. Le validateur applique les mêmes règles que celles qu’utilise Design Extractor pour vérifier chaque DESIGN.md qu’il génère, plus une vérification du contraste des couleurs des composants.

Une référence comme "{colors.brand}" doit désigner un token qui existe dans le front matter, ici une entrée brand sous colors. Ajoutez le token manquant ou faites pointer la référence vers un token existant. Gardez les références entre guillemets : YAML lit un {colors.brand} sans guillemets comme un mapping, pas comme du texte.

Oui. L’outil en ligne de commande open source de Google vérifie un fichier dans votre pipeline : lancez npx @google/design.md lint DESIGN.md. Il affiche un rapport JSON et se termine avec le code 1 s’il trouve des erreurs, ce qui fait échouer le job sur un fichier cassé. Ses règles recoupent celles de cette page, mais certaines sévérités diffèrent.