De Figma al código
Comprobar y actualizar
Qué hacer cuando cambia una variable en Figma: el ciclo de exportar, generar y comprobar. Qué vigila la comprobación automática, qué errores de diseño detecta y qué no puede ver.
Última revisión:
El código de los tokens se genera: nadie lo escribe a mano. Eso tiene una consecuencia práctica: cuando cambias algo en Figma, el código no cambia hasta que vuelves a generarlo, y conviene saber si el resultado es el esperado. En esta lección verás el ciclo de un cambio y qué comprueba DesignToken101 en cada vuelta.
En esta página
- El ciclo de un cambio
- Qué vigila la comprobación
- Los errores de diseño que detecta
- Lo que no puede ver
- Lo que te llevas
El ciclo de un cambio
- Cambiar la variable, En Figma, o el token de código en su archivo
- Exportar, Export modes de la colección
- Sustituir los archivos, La carpeta de esa colección
- Generar, npm run tokens
- Comprobar, npm run check:tokens
- Revisar y guardar, Los cambios del CSS, en un commit
- Cambiar la variable. En Figma, como siempre. Si el token es de código, en
tokens/code-only.tokens.jsony en la especificación del sistema; si es un estilo de texto, en la tabla de la especificación y entext-styles.css. - Exportar. Clic derecho en la colección y Export modes (Exportar los modos).
- Sustituir los archivos. Los de la carpeta de esa colección, enteros, sin editarlos.
- Generar. Un comando normaliza la exportación y genera las dos capas.
- Comprobar. Otro comando revisa el resultado y falla si algo no cuadra.
- Revisar y guardar. Mira qué ha cambiado en el CSS generado. Si cambiaste un alias, debería cambiar una línea; si cambian veinte, algo más se movió en Figma.
Recomendación
Exporta la colección entera, no un modo suelto, y sustituye la carpeta completa. Así los archivos siempre son una foto de Figma en un momento, y nunca una mezcla de dos exportaciones.
El paso 6 es el que más enseña a un diseñador: el cambio del CSS es el reflejo exacto de lo que cambiaste en Figma. Si no lo es, la diferencia te dice qué tocaste sin querer.
Qué vigila la comprobación
La comprobación compara lo generado con sus fuentes: la exportación de Figma, la especificación del sistema y Tailwind CSS. Son ocho grupos de reglas:
| Qué compara | Qué exige |
|---|---|
| El code syntax de cada variable de Figma | Que sea su ruta con guiones: var(--t101- + ruta + ), y que esa variable exista en el CSS |
| Las referencias del CSS | Que cada var(--t101-…) apunte a una variable que existe |
| Los bloques de modo | Que cada bloque Dark tenga exactamente los tokens de Semantic color, y el de Desktop, los de Layout |
| Los colores primitivos | Que el hexadecimal del CSS sea el de la exportación de Figma |
| Los tokens de código | Que sus valores sean los de la especificación. Y que los tres que pasaron de código a Figma estén en la exportación y den el mismo CSS que antes |
| Los estilos de texto | Que cada clase type-* tenga la familia, el tamaño, el interlineado y el peso de la tabla (Los estilos de texto en código) |
| Las clases de Tailwind CSS | Que existan las de los tokens, como bg-neutral-default o desktop:, y que no existan las del tema por defecto, como bg-red-500 o p-4 |
| Los componentes | Que no tengan valores arbitrarios, como p-[13px], salvo las excepciones con motivo, y que la sintaxis de variable entre paréntesis apunte a un token que existe (Los corchetes) |
La fila de las clases de Tailwind CSS vigila también los espacios de nombres por propiedad, que funcionan pero no están documentados (Un espacio de nombres por propiedad). Si una versión de Tailwind CSS deja de generar bg-neutral-default, la comprobación falla antes de publicar.
Nota
Una comprobación es tan buena como los errores que detecta. Cada regla se probó también en negativo: con una copia del proyecto, se introdujo el error a propósito y se comprobó que la regla fallaba.
Los errores de diseño que detecta
Varios errores que nacen en Figma, y que Figma no avisa, aparecen aquí:
- Renombrar una variable sin cambiar su code syntax. Al renombrar, Figma conserva los alias y los vínculos, pero no cambia el code syntax (Si tienes que renombrar). La variable CSS seguiría con el nombre viejo. La comprobación lo detecta porque el code syntax ya no es la ruta.
- Duplicar una variable y no cambiar su code syntax. Dos variables con el mismo nombre en CSS. Lo detecta la misma regla: el code syntax de la copia no es su ruta. Antes de que existiera esa regla, la comprobación miraba únicamente que el code syntax tuviera su variable en el CSS, y este error pasaba, porque el nombre copiado existe (prueba en negativo del 2026-10-04).
- Un valor que cambia por el camino. Cuando los fondos con transparencia pasaron de código a Figma, el CSS tenía que seguir igual. Sin corregir la opacidad en float32, no lo estaba, y la comprobación detectó el
e5(La opacidad en float32).
Aviso
El error más habitual al pasar de Figma al código es esperar que la exportación lo conserve todo: los alias, las unidades, los estilos de texto. No los conserva. Si tu cadena no tiene un paso que los recupere y una comprobación que lo vigile, el CSS puede parecer correcto y haber perdido la capa de alias.
Lo que no puede ver
La comprobación compara textos y valores. No mira el diseño:
- El contraste. Que un par de texto y fondo se lea bien en Light y en Dark se comprueba aparte; lo verás en el módulo Accesibilidad (Contraste de texto).
- El uso. No sabe si un componente usa
text-neutral-subtledonde debería usartext-neutral-default. - Dev Mode. No ve cómo muestra Figma el code syntax en el panel de inspección.
Por eso el paso 6 del ciclo, revisar el cambio, sigue siendo tuyo.
Desde la raíz del proyecto, después de sustituir los archivos de tokens/figma/:
npm run tokens
npm run check:tokensnpm run tokens ejecuta la normalización (node tools/figma-to-dtcg.mjs) y Terrazzo (tz build). npm run check:tokens ejecuta tools/check-tokens.mjs, que usa el compilador de Tailwind CSS para generar las clases que comprueba. Sin errores, termina así:
tokens.css: 155 en :root · 33 en [data-theme="dark"] · 33 en prefers-color-scheme · 9 en Desktop
theme.css: 89 variables de Tailwind
src/: 39 archivos · 8 valores arbitrarios (5 excepciones)
Sin errores.Con un error, lo nombra y termina con un código de salida distinto de cero, para que un proceso automático pueda pararse. Este es el resultado con el code syntax viejo de Si tienes que renombrar. En Figma, el code syntax es de la variable, no del modo, así que la reexportación lo trae igual en Light.tokens.json y en Dark.tokens.json:
6 error(es):
- Falta --t101-color-text-accent (code syntax de Figma) en :root
- color/text/accent/default: code syntax var(--t101-color-text-accent) ≠ var(--t101-color-text-accent-default) (ruta de la variable)
- Falta --t101-color-text-accent (code syntax de Figma) en :root
- color/text/accent/default: code syntax var(--t101-color-text-accent) ≠ var(--t101-color-text-accent-default) (ruta de la variable)
- El bloque darkAttr no coincide con Semantic color
- El bloque darkMedia no coincide con Semantic colorUn solo error de diseño da seis mensajes. Se leen así:
- Los dos primeros, repetidos: uno por cada archivo de modo. El primero dice que la variable del code syntax no existe en el CSS; el segundo, que el code syntax no es la ruta. El segundo es el que señala la causa.
- Los dos últimos: los bloques Dark del CSS ya no coinciden con la colección, porque la colección dice que tiene una variable con un nombre que el CSS no tiene. Son una consecuencia del mismo error.
Corregido el code syntax en Figma y reexportada la colección, desaparecen los seis. Lo comprobó la sesión de desarrollo el 2026-10-05, con el proyecto completo y la regla de Tailwind CSS incluida. La cuenta de theme.css incluye las dos variables de la familia por defecto, además de las 87 de los tokens.
El script está en el repositorio: tools/check-tokens.mjs.
Lo que te llevas
- Un cambio en Figma llega al código en un ciclo: exportar la colección, sustituir su carpeta, generar, comprobar y revisar.
- La comprobación compara lo generado con Figma, con la especificación y con Tailwind CSS, y detecta errores que Figma no avisa, como un code syntax viejo.
- No ve el diseño: el contraste y el uso de cada token se revisan aparte.