Validador de DESIGN.md

O front matter em YAML, a cor primary obrigatória, se as cores estão escritas em um formato de cor (hex, rgb, hsl, oklch, um nome de cor e afins), tamanhos de fonte e raios em px, em ou rem, as propriedades de tipografia, as propriedades dos componentes e as referências de tokens deles (inclusive referências sem aspas, que o YAML não lê como texto), a lista de omitidos, seções duplicadas ou fora de ordem e o contraste entre as cores de texto e de fundo de cada componente, comparado ao mínimo de 4.5:1 do WCAG AA. Erros tornam o arquivo inválido; avisos apontam coisas que vale a pena corrigir.

Não. A validação roda inteiramente no seu navegador: o texto que você cola ou o arquivo que você escolhe nunca é enviado para os nossos servidores. As únicas requisições que a prévia faz são para as folhas de estilo das fontes: o nosso servidor busca essas folhas no Google Fonts, e elas levam apenas os nomes das famílias tipográficas dos seus tokens de tipografia.

O formato DESIGN.md do Google, usado pelo Stitch e publicado no repositório google-labs-code/design.md. O validador aplica as mesmas regras que o Design Extractor usa para verificar cada DESIGN.md que gera, mais uma verificação de contraste nas cores dos componentes.

Uma referência como "{colors.brand}" precisa apontar para um token que existe no front matter, neste caso uma entrada brand dentro de colors. Adicione o token que falta ou aponte a referência para um que exista. Mantenha as referências entre aspas: o YAML lê um {colors.brand} sem aspas como um mapeamento, não como texto.

Sim. A ferramenta de linha de comando open source do Google verifica um arquivo no seu pipeline: rode npx @google/design.md lint DESIGN.md. Ela imprime um relatório em JSON e termina com o código 1 quando encontra erros, então o job falha com um arquivo quebrado. As regras dela coincidem em parte com as desta página, mas algumas severidades são diferentes.