Validador de DESIGN.md

El frontmatter en YAML, el color primario obligatorio, que los colores estén escritos en un formato de color (hex, rgb, hsl, oklch, un nombre de color y similares), los tamaños de fuente y los radios en px, em o rem, las propiedades tipográficas, las propiedades de los componentes y sus referencias a tokens (incluidas las referencias sin comillas, que YAML no lee como texto), la lista de secciones omitidas, las secciones duplicadas o fuera de orden y el contraste entre los colores de texto y de fondo de cada componente frente al mínimo de WCAG AA de 4.5:1. Los errores hacen que el archivo no sea válido; las advertencias señalan cosas que conviene corregir.

No. La validación se hace por completo en tu navegador: el texto que pegas o el archivo que eliges nunca se envía a nuestros servidores. Las únicas solicitudes que hace la vista previa son para las hojas de estilo de las fuentes: nuestro servidor las pide a Google Fonts, y solo llevan los nombres de las familias tipográficas de tus tokens de tipografía.

El formato DESIGN.md de Google tal como lo usa Stitch y como está publicado en el repositorio google-labs-code/design.md. El validador aplica las mismas reglas que usa Design Extractor para comprobar cada DESIGN.md que genera, más una comprobación de contraste en los colores de los componentes.

Una referencia como "{colors.brand}" tiene que nombrar un token que exista en el frontmatter, en este caso una entrada brand dentro de colors. Añade el token que falta o apunta la referencia a uno que exista. Mantén las referencias entre comillas: YAML lee un {colors.brand} sin comillas como un mapa, no como texto.

Sí. La herramienta de línea de comandos de código abierto de Google comprueba un archivo en tu pipeline: ejecuta npx @google/design.md lint DESIGN.md. Imprime un informe en JSON y termina con el código 1 cuando encuentra errores, así que el job falla si el archivo está roto. Sus reglas coinciden en parte con las de esta página, pero algunas severidades son distintas.