Buenas prácticas con Tailwind CSS en proyectos grandes

Tailwind CSS ha revolucionado la forma de escribir estilos, pero cuando el proyecto crece y el equipo se multiplica, es fácil perder el control y acabar con clases dispersas y código difícil de mantener. En este artículo comparto algunas buenas prácticas que me han ayudado a escalar Tailwind sin perder la claridad ni la velocidad de desarrollo.

1. Organiza tu configuración desde el principio

El archivo tailwind.config.js es el corazón del proyecto. Define allí los colores, espaciados y tipografías que usará todo el equipo. Así, cualquier cambio futuro se centraliza y no hay valores mágicos en los componentes.

module.exports = {
  content: [
    "./src/**/.{js,jsx,ts,tsx,html}",
  ],
  theme: {
    extend: {
      colors: {
        primary: "#1e40af",
        secondary: "#f59e0b",
      },
      spacing: {
        128: "32rem",
        144: "36rem",
      },
    },
  },
  plugins: [],
};

Con esta configuración todos los componentes usarán bg-primary o p-128 en lugar de códigos hexadecimales o valores arbitrarios.

2. Usa `@apply` con moderación

La directiva @apply permite crear clases reutilizables en archivos CSS o SCSS, pero abusar de ella genera una capa extra que complica el árbol de utilidades. Reserva @apply para patrones que se repiten en varios lugares, como botones o tarjetas.

.btn-primary {
  @apply px-4 py-2 rounded bg-primary text-white hover:bg-primary/90 focus:outline-none focus:ring-2 focus:ring-primary;
}

.card {
  @apply p-6 bg-white rounded-lg shadow-md hover:shadow-lg transition-shadow;
}

De esta forma mantienes la velocidad de Tailwind y obtienes la claridad de una clase semántica.

3. Nombra tus utilities de forma coherente

Cuando necesitas crear variantes específicas, sigue una convención de nombres que indique su propósito. Por ejemplo, text-heading-1 para el encabezado principal o bg-alert-error para fondos de error. Evita nombres genéricos como bg-red-500 dentro del HTML; prefiera la clase descriptiva.

Ventaja: los revisores entienden rápidamente la intención.
Desventaja: si la convención cambia, tendrás que refactorizar, pero eso es mucho más sencillo que buscar valores de color sueltos.

4. Divide tu CSS en componentes

En proyectos grandes es útil crear una carpeta components/ con archivos CSS o SCSS por componente. Cada archivo exporta sus clases con @apply y se importa en el punto de entrada del proyecto (por ejemplo, index.css). Así, el scope está claramente definido.

/ src/components/button.css /
.btn {
  @apply font-medium rounded-md transition-colors;
}

/ src/components/card.css */
.card {
  @apply border border-gray-200 p-4 rounded-lg;
}

Esta organización facilita la localización de estilos y evita que una regla inesperada rompa otro componente.

5. Mantén el árbol de clases limpio

En los archivos JSX o HTML, revisa que no haya clases redundantes. Herramientas como tailwindcss-classnames o linters personalizados pueden detectar cuando una clase ya está cubierta por otra o cuando una utilidad está duplicada.

Ejemplo: bg-primary bg-primary/90 es contradictorio.
Solución: elimina la primera o usa bg-primary/90 directamente.

6. Usa herramientas de lint y auditoría

Integra stylelint con el plugin stylelint-config-tailwindcss en tu pipeline CI. Configura reglas que obliguen a usar las clases definidas en el config y a evitar !important. Además, ejecuta npm run build con la opción --purge para asegurarte de que el CSS final no contiene clases sin usar.

// .stylelintrc.json
{
  "extends": ["stylelint-config-standard", "stylelint-config-tailwindcss"],
  "rules": {
    "no-duplicate-selectors": true,
    "declaration-no-important": true
  }
}

Con estas reglas, cualquier commit que introduzca una clase no declarada o un !important fallará en el CI, manteniendo la base de código sana.

Conclusión

Escalar Tailwind CSS no tiene por qué ser una pesadilla. Definir una configuración central, crear clases semánticas, usar @apply solo donde aporta valor y apoyarse en linters son pilares que garantizan consistencia y velocidad. Aplica estas prácticas en tu próximo proyecto grande y verás cómo el equipo gana productividad sin sacrificar la calidad del código.