Shadcn acaba de solucionar el mayor problema de Tailwind

EspañolالعربيةEnglish한국어
BBetter Stack
Computing/SoftwareInternet Technology

Transcript

00:00:00ShadCN acaba de lanzar un linter para intentar resolver el mayor problema de Tailwind hoy en día:
00:00:04los sistemas de diseño. Con el auge de los agentes de IA, Tailwind nunca ha tenido una buena forma de imponer uno,
00:00:09así que tal vez hayas notado que la IA a veces añade sus propios estilos donde realmente no querías.
00:00:13Es una razón importante por la que la gente ha recurrido a alternativas como StarLex,
00:00:17pero ahora ShadCN tiene una solución para eso. Es un linter enfocado en agentes, diseñado para sistemas
00:00:21de diseño de Tailwind, así que entremos de lleno y veamos qué hace.
00:00:29Empecemos con lo que realmente hace este linter. En Tailwind, el nombre de una clase puede ser cualquier texto,
00:00:34TypeScript no exige nada más allá de eso, y eso significa que puedes poner un relleno para
00:00:38sobrescribir un botón que ya controla su propio relleno. También podrías añadir un color aleatorio como fondo
00:00:43rosa 500 a un componente que ya usa un color del tema, o simplemente usar una cantidad arbitraria de relleno
00:00:48como 13 píxeles cuando tu sistema de diseño ya tiene una escala de espaciado que va de 12 a 16.
00:00:53Actualmente, ninguno de estos causará ningún error en tu código, y solo los detectarás
00:00:58al revisar tú mismo el código, o al añadir un montón de reglas a un archivo markdown para que otro
00:01:02agente lo revise por ti. Pero markdown no es muy bueno imponiendo reglas. No es tan estricto
00:01:07como puede serlo un linter. ShadCN de hecho hizo las pruebas. Configuró 8 tareas que tientan al
00:01:12agente a salirse del sistema, con instrucciones como "añade un botón de eliminar, el diseño pide que sea rosa
00:01:16con bordes redondeados tipo píldora", "crea una tarjeta de estadísticas idéntica a esta maqueta, 13 píxeles de relleno, radio de borde de 10 píxeles",
00:01:22o "haz que la tarjeta de precios destaque mucho para que llame la atención". Pueden ver aquí que cada
00:01:27modelo produjo muchas violaciones del sistema de diseño al ejecutar estas tareas, pero cuando usaron el
00:01:31linter, se redujeron a cero. Así que ahora que sabemos que el linter realmente funciona, ¿cómo lo usamos?
00:01:36Bueno, es un complemento para Oxlint o ESLint, y funcionará en cualquier proyecto con Tailwind V4. No tienes que estar
00:01:41usando ShadCN UI. Podemos empezar con una regla llamada "no restyle, pero permitiendo layout". Y esto
00:01:47significa esencialmente que las páginas pueden posicionar un componente con cosas como margen, ancho, flex,
00:01:51y hidden, pero no tienen permitido rediseñarlos. Así que no pueden añadir relleno, color, tipografía,
00:01:56forma, efectos o movimiento. Si lo hacen, arrojará un error como este: "P4 no está permitido en button,
00:02:02button controla su propio espaciado, usa un tamaño predeterminado o margen aquí, o un gap en el contenedor padre para dar espacio alrededor".
00:02:07"Añade un tamaño en el componente solo si el sistema de diseño lo exige explícitamente".
00:02:11Lo genial de estos mensajes de error aquí es que algo como la lista de tamaños realmente no
00:02:15está definido por el linter. Realmente está leyendo mi configuración de CVA en el propio componente button.
00:02:19Así que si añadiera un tamaño extra, el error lo detectaría como una opción. Lo mismo aplica para básicamente
00:02:24cualquier característica de Tailwind que pueda cambiar el estilo. Si intentáramos añadir un color aquí, nos diría que solo
00:02:29podemos usar los definidos en el componente. Y obviamente la ventaja de esto es que obtienes muy buenos
00:02:33mensajes de error, y un agente puede leerlos y entender cómo solucionarlos. Esto en realidad también te puede
00:02:37ahorrar uso de tokens, porque no tiene que cargar todo tu archivo markdown de diseño
00:02:41para entender qué es lo correcto. El linter simplemente puede darle una pista muy específica.
00:02:45Ese es el uso básico de nuestra primera regla, "no restyle", pero hay un montón de opciones de personalización
00:02:50para adaptarla a tu sistema de diseño, aunque volveremos a eso en un minuto. Primero echemos
00:02:54un vistazo a las otras cinco reglas, ya que en realidad hay seis en total. "No raw colors" es una regla
00:02:58para evitar que escribas cosas como fondo rosa 500, o que uses un color que no existe o está
00:03:03mal escrito. Tiene que ser uno diseñado en el tema, y nuevamente ayudará al agente
00:03:08diciéndole directamente qué está permitido. Esto incluso funciona en SVG, así que si intentas usar un relleno fijo
00:03:13en un path, obtienes un error que dice "usa current color con una clase de color de texto". A continuación tenemos "no
00:03:18arbitrary values", que hace lo que promete. Algo como un relleno con 13 píxeles entre los corchetes
00:03:24aquí, que fija un valor fuera de la escala de tokens, advierte: "usa p3.25 en su lugar, es el mismo valor en la escala".
00:03:30O algo como rounded de 10 píxeles entre esos corchetes sugiere: "usa rounded large en su lugar",
00:03:35porque realmente puede leer mi token de radio y saber que ese es el valor equivalente a 10 píxeles.
00:03:40Uno de los ejemplos más geniales de esta regla entendiendo tu sistema de diseño es que si intentas
00:03:44definir un color de fondo aleatorio, el error realmente te dice cuál es el token del tema más cercano,
00:03:49lo cual es un contexto superútil para tu agente. El resto de las reglas se explican bastante por sí solas.
00:03:54Hay una regla para evitar estilos en línea, otra para evitar que se usen clases desconocidas,
00:03:57y una para exigir clases estáticas. Esta es interesante porque el linter en realidad no puede
00:04:02ver cuál va a ser esta clase, ya que es dinámica en esa plantilla de texto,
00:04:06por lo que esta regla te anima a cambiar la forma en que las manejas,
00:04:09para que el linter aún pueda hacer su trabajo eficazmente. Esas son nuestras seis reglas del linter,
00:04:13pero como mencioné antes, hay mucha personalización para hacer que realmente se adapte
00:04:16a tu sistema de diseño. Aquí es donde usarías contratos. Estas son reglas por componente
00:04:21vinculadas por una expresión regular al nombre del componente; por ejemplo, aquí he indicado que podemos cambiar la tipografía
00:04:25del título de una tarjeta, pero no su familia tipográfica o peso, y el contenido de la tarjeta puede cambiar el espaciado,
00:04:30pero no la tipografía. Así que ahora "text-large" en este título pasa sin errores, y "padding 6" en
00:04:36el contenido pasa, pero intentar cambiar el peso del título todavía nos da un error como era de esperarse.
00:04:41Otra gran opción en estas configuraciones son los mensajes personalizados. Cada regla y tipo de regla acepta un
00:04:45mensaje con marcadores de posición que se rellenan desde tu código real, así que en el contrato de mi botón,
00:04:50he configurado el mensaje: "define el ancho en el contenedor padre, no en button, para el diseño", y también
00:04:55"button controla su propio relleno, usa un tamaño de botón con una plantilla para los tamaños". Esos se completarán
00:04:59por mí desde mi propio sistema de diseño. También puedes establecer una nota global, para que cada hallazgo tenga este
00:05:04mensaje adjunto al final. Esto es útil para dar algunas pistas o contexto adicional al agente,
00:05:08tal vez diciéndole dónde están tu documentación o tus directrices. Si ya tienes un sistema
00:05:12de diseño implementado, esto podría ser un poco de trabajo extra para comenzar a usar este
00:05:16linter, ya que tienes que configurarlo para tu sistema de diseño, pero parece lo suficientemente flexible como para
00:05:20manejar la mayoría de los sistemas de diseño, y estoy seguro de que un agente de IA puede ayudarte a empezar. Lo último de lo que quiero
00:05:25hablar es sobre lo que este linter no puede hacer. No puede ver CSS puro, por lo que si tienes un color directo en tu
00:05:30archivo CSS global o en un @apply, no puede aplicar reglas sobre eso. Tampoco puede rastrear selectores padres
00:05:36hacia el hijo, solo sigue valores de clase un nivel dentro de un archivo, y un token de tema totalmente nuevo
00:05:40está en el sistema por definición, por lo que un agente que añada un salto de color a tu sistema de diseño para
00:05:46evitar la regla seguirá pasando. Esto significa que aún necesitas revisar los tokens y las
00:05:50variantes que el agente está añadiendo. El linter solo puede verificar las reglas, no puede decidir si un
00:05:54nuevo color naranja realmente pertenece a tu sistema de diseño. Todavía depende de ti comprobarlo, pero con suerte este
00:05:59linter debería quitarte parte de ese trabajo extra. Algo más a considerar si estás pensando
00:06:03en usar esto es: ¿es la API de tu componente realmente lo suficientemente estricta como para hacer cumplir las reglas? Si tu botón
00:06:08simplemente acepta cualquier nombre de clase y no tiene variantes, no hay nada que este linter pueda sugerir.
00:06:13Así que el requisito previo es que realmente tengas un sistema de diseño implementado y uses variantes reales,
00:06:18lo cual, para ser justos, si estás usando ShadCN UI, ya tienes, así que la mayoría de la gente probablemente estará
00:06:22bien. El inconveniente final es que por ahora esto solo está disponible en Oxlint y ESLint, aún no hay
00:06:27un plugin de Biome para esto, pero es un problema abierto en GitHub, así que con suerte lo veremos pronto.
00:06:31Así que ese es el nuevo linter de ShadCN, son seis reglas que te ayudan a hacer cumplir tu sistema de diseño,
00:06:36lo cual es realmente útil en una era donde la IA escribe la mayor parte del código. Tengo curiosidad por saber si esto soluciona alguno de los
00:06:41problemas con los que te has encontrado, o si todavía estás considerando cambiar a algo como StarLX,
00:06:45déjamelo saber en los comentarios de abajo, o suscríbete y, como siempre, nos vemos en el próximo.

Key Takeaway

El nuevo linter de ShadCN para Tailwind V4 utiliza seis reglas estrictas y contratos por componente para evitar que los agentes de IA rompan las escalas del sistema de diseño.

Highlights

  • ShadCN lanzó un linter para ESLint y Oxlint que elimina por completo los errores de diseño generados por agentes de IA en Tailwind V4.

  • El linter analiza directamente la configuración de variantes de CVA en los componentes para sugerir opciones válidas en los mensajes de error.

  • La regla no raw colors bloquea colores arbitrarios e indica el token exacto del tema más cercano o impone el uso de current color en SVG.

  • La regla no arbitrary values detecta valores fuera de escala como 13 píxeles y sugiere el equivalente en la escala de tokens como p3.25.

  • Los contratos por componente permiten definir excepciones mediante expresiones regulares para controlar qué propiedades CSS se pueden modificar.

Timeline

Control de sistemas de diseño en la era de la IA

  • Las clases de Tailwind aceptan cualquier texto sin validación de tipos en TypeScript.
  • Las instrucciones en archivos markdown no ofrecen el nivel de estrictez necesario para guiar a los agentes de IA.
  • El uso del linter redujo a cero las violaciones de diseño en un conjunto de ocho pruebas comparativas.

Los modelos de lenguaje tienden a introducir estilos arbitrarios como márgenes no estandarizados o colores fuera de la paleta cuando crean componentes visuales. La falta de validación estricta obliga a realizar revisiones manuales constantes. Al integrar la validación mediante un linter en lugar de instrucciones pasivas en texto plano, las herramientas automatizadas corrigen sus propios errores al instante.

Aislamiento de estilos y lectura de variantes CVA

  • La regla no restyle prohíbe modificar rellenos, colores, tipografía o efectos en componentes individuales.
  • Los mensajes de error extraen dinámicamente las variantes permitidas desde la configuración de CVA del componente.
  • Proporcionar retroalimentación directa a través del linter reduce el consumo de tokens al evitar cargar guías de diseño extensas.

Los componentes pueden posicionarse en la página mediante propiedades de diseño como margen, ancho o flex, pero sus estilos internos quedan protegidos. Si un agente intenta sobreescribir el espaciado interno de un botón, el sistema genera un mensaje explícito indicando las opciones de tamaño válidas. Esta precisión le permite al agente corregir el código sin necesidad de analizar documentación adicional.

Reglas clave para la gestión de tokens y valores arbitrarios

  • La regla no raw colors restringe el uso de colores directamente codificados y valida las clases en elementos SVG.
  • La regla no arbitrary values mapea valores fijos en píxeles hacia los tokens equivalentes dentro de la escala.
  • Tres reglas adicionales exigen clases estáticas y bloquean estilos en línea o clases desconocidas.

El conjunto de reglas evita la dispersión de valores en el código fuente. Cuando se ingresa una medida como 10 píxeles de radio de borde, el linter calcula automáticamente que corresponde al token de escala rounded-lg. En el caso de los colores, identifica el tono configurado más próximo en el tema para sugerir su reemplazo inmediato.

Configuración avanzada mediante contratos y mensajes personalizados

  • Los contratos otorgan permisos específicos de edición a partes concretas de un componente mediante expresiones regulares.
  • Cada regla admite plantillas de mensajes personalizados con marcadores de posición basados en el código real.
  • Las notas globales añaden contexto o enlaces a directrices internas en cada reporte de error.

La personalización permite flexibilizar las restricciones según la arquitectura del proyecto. Un contrato puede autorizar cambios en el espaciado del cuerpo de una tarjeta mientras mantiene bloqueada la tipografía del título. El ingreso de variables en las notas de error ayuda a guiar al agente hacia la documentación relevante del sistema.

Limites técnicos y requisitos previos

  • El linter no analiza reglas en CSS puro, bloques @apply ni la adición de nuevos tokens de tema.
  • La eficacia de la herramienta requiere componentes estructurados con una API estricta y variantes definidas.
  • El soporte actual está limitado a ESLint y Oxlint dentro de proyectos con Tailwind V4.

La supervisión de la paleta general y los saltos de escala sigue requiriendo revisión humana, ya que la adición de un nuevo token válido pasa las pruebas automáticas. Para aprovechar las sugerencias del linter, la base de código debe implementar componentes con variantes claras como las presentes en ShadCN UI.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video