Usar Tailwind CSS en React con Vite: instalación y revisión

Para usar Tailwind CSS en React con Vite, añade el plugin de Tailwind para Vite, importa Tailwind en la hoja CSS y carga esa hoja desde la aplicación. Comprueba primero una utilidad estática visible; después revisa las variantes y la compilación de producción. Utiliza instrucciones coherentes con la versión instalada.

La guía utiliza una pantalla ficticia de preferencias de notificaciones, con un encabezado, una descripción breve y un botón Guardar preferencias. La pantalla y sus casos de aceptación son ejemplos propuestos. Buscamos establecer un recorrido de estilos fiable antes de adaptar un diseño completo o añadir comportamiento de aplicación ajeno a esta tarea.

Sigue el recorrido de los estilos

Que un componente React llegue al navegador es solo una parte de una interfaz con estilos. El proyecto también necesita una entrada CSS, la integración que procesa Tailwind y archivos donde puedan encontrarse los nombres de utilidades necesarios. Si la página aparece sin formato, inspecciona ese recorrido en orden en lugar de cambiar repetidamente el marcado del botón.

Empieza por el proyecto que realmente sirve la página. Anota su comando de gestor de paquetes, archivo de configuración de Vite, entrada React y hoja importada. En un repositorio con varias aplicaciones, el paquete editado puede ser distinto del que sirve la pestaña. Confirma la página visible con un pequeño cambio de texto antes de sacar conclusiones sobre CSS.

Consulta la guía de inicio de Vite para crear un proyecto React y comprobar los requisitos actuales del entorno si necesitas uno nuevo. En proyectos existentes, conserva la integración React que ya funciona. Añade Tailwind mediante un cambio pequeño y revisable para distinguir la configuración inicial de los ajustes visuales posteriores.

Elige una muestra estática evidente: un encabezado con text-2xl y una tarjeta blanca con p-6. Anota el tamaño de texto y espaciado esperados e inspecciona el resultado. Son utilidades propuestas para el diagnóstico. Un cambio visible acompañado de su regla en el navegador aporta más evidencia que encontrar el nombre de un paquete entre las dependencias.

Conecta el plugin de Vite y la hoja de estilos

La guía actual de instalación de Tailwind con Vite utiliza tailwindcss y @tailwindcss/vite, añade el plugin a Vite e importa Tailwind desde CSS. Sigue esta vía para la configuración actual de v4. Los comandos compactos de abajo describen una integración nueva; inspecciona primero un proyecto existente para evitar dos configuraciones que compitan.

Instala ambas dependencias, importa el plugin de Tailwind en vite.config.ts y añade tailwindcss() junto al plugin React existente. Conserva esa llamada de React y el resto de configuración que funciona. Añade la importación de Tailwind a la hoja principal y confirma que la entrada React importe exactamente esa hoja. Los nombres del ejemplo son convenciones, no requisitos.

En un proyecto nuevo, las piezas podrían ser vite.config.ts, src/index.css y src/main.tsx. Si la entrada importa src/app.css, editar una hoja index.css sin uso no cambiará la página. Abre el archivo enlazado desde la entrada y sigue esa referencia en lugar de asumir que un nombre conocido está activo.

La guía de actualización de Tailwind documenta los cambios respecto a integraciones anteriores. Evita mezclar inicializaciones y directivas de un tutorial v3 con la vía Vite de v4. Anota la versión principal instalada en la ficha de configuración. Si actualizas una aplicación madura, revisa la migración por separado, sin interpretar cada diferencia visual como un fallo de instalación.

npm install tailwindcss @tailwindcss/vite

// vite.config.ts: conserva el plugin React existente
import tailwindcss from "@tailwindcss/vite"
// Añade tailwindcss() al array de plugins existente.

/* src/index.css */
@import "tailwindcss";

// src/main.tsx: utiliza la entrada CSS real del proyecto
import "./index.css";

Conserva clases completas en las variantes de React

En JSX, aplica las utilidades mediante className. La guía de JSX de React explica ese nombre de atributo. Mantén explícita la primera muestra: un botón real con tipo, etiqueta visible y nombres completos de utilidades. Así resulta más fácil inspeccionar la relación entre el elemento seleccionado y su CSS que con una abstracción grande.

Después añade dos variantes visuales deliberadas, por ejemplo primary y quiet. La guía de detección de clases de Tailwind explica por qué los nombres deben aparecer completos en el código que se examina. Construirlos a partir de un prefijo parcial y un color recibido durante la ejecución puede impedir que se genere la utilidad. Utiliza un mapa de listas completas para variantes finitas.

En el botón propuesto, primary puede elegir bg-blue-600 text-white y quiet puede elegir bg-slate-100 text-slate-900. Prueba ambas ramas. Las dos listas pueden existir en el código aunque solo una esté visible en cada momento. Conserva espaciado y radio básicos en una cadena literal compartida para que una variante no cambie accidentalmente las dimensiones.

La guía de estilos con utilidades trata la composición y los conflictos. Si llegan dos utilidades de fondo al mismo elemento, inspecciona la regla calculada en vez de asumir que gana la última palabra de className. Prefiere una elección deliberada de fondo por variante. Recomendamos mantener pequeño este componente inicial hasta observar el resultado de cada opción.

Para dar significado visual a los estados del formulario después de configurar el proyecto, continúa con la guía de clases de color y estados de Tailwind. Aquí la aceptación es más concreta: ¿se detectaron, generaron y aplicaron al elemento correcto las clases completas previstas?

const appearance = {
  primary: "bg-blue-600 text-white",
  quiet: "bg-slate-100 text-slate-900",
};
// Usa una clave de variante validada por la API del componente.
// Combina appearance[variant] con las clases base literales.

Localiza la primera capa que falla

Parte de una observación, no de «Tailwind está roto». Si encabezado y tarjeta aparecen sin estilos, comprueba primero que se cargue y procese la hoja. Si la tarjeta funciona pero falla el botón quiet, compara sus clases literales y ubicación original. Son casos que apuntan a partes diferentes del mismo recorrido de estilos.

Si falta la clase prevista en el elemento, inspecciona la rama React y las propiedades recibidas. Si aparece la clase pero no existe una regla correspondiente, revisa detección y generación. Si existe la regla pero está tachada, inspecciona el estilo competidor y el valor calculado. Cambia una causa cada vez para conservar una explicación comprobable.

Los paquetes de componentes compartidos requieren atención especial. La documentación de detección explica las ubicaciones excluidas y el registro explícito de fuentes. Si no aparecen sus utilidades, identifica dónde están las cadenas de clases y si se incluyen esos archivos. Evita registrar todo el repositorio por reflejo: selecciona el origen concreto que utiliza realmente la aplicación.

Guarda una ficha breve con componente, variante seleccionada, clase esperada, regla observada y corrección. Por ejemplo: «La variante quiet mostraba su clase, pero no se examinaba el origen del paquete compartido». Repite ese caso tras corregirlo. Una reparación útil explica por qué reaparecieron los estilos, además de dejar una página que casualmente parece correcta.

Comprueba la compilación de producción por separado

La guía de compilación de producción de Vite describe el paquete generado y el tratamiento de rutas públicas base. Ejecuta el comando de compilación del proyecto e inspecciona la aplicación generada mediante su previsualización local. Que funcione una pestaña de desarrollo no demuestra que CSS y recursos se carguen desde la ubicación de despliegue prevista.

Abre la misma muestra de preferencias desde el resultado compilado. Comprueba encabezado, padding de tarjeta y ambas variantes del botón. Inspecciona de nuevo las peticiones de hojas y las reglas calculadas. Si la aplicación se sirve bajo una ruta pública anidada, contrasta esa configuración con el contrato de despliegue; una petición CSS que devuelve HTML no es una respuesta válida de hoja de estilos.

Anota los comandos realmente utilizados, la ruta pública asumida y los casos revisados. En una plantilla Vite habitual suelen ser npm run build y npm run preview, pero lee los scripts del paquete antes de copiarlos. La previsualización local ayuda a comprobar el resultado; la configuración del alojamiento de producción sigue siendo otra parte de la entrega.

Utiliza una tabla pequeña de aceptación para que otra persona repita la revisión. Exige las mismas observaciones en desarrollo y previsualización compilada. Si solo falla la segunda, conserva esa diferencia en la incidencia. Reinstalar paquetes sin identificar la petición fallida o regla ausente puede borrar evidencia útil y dejar sin resolver el problema de despliegue.

Utiliza una muestra EmviUI cuando funcionen los estilos

La imagen real de botones EmviUI que aparece debajo permite elegir una muestra visual para implementar. La web de EmviUI describe un kit de interfaz y sistema de diseño editables en Figma, basados en Tailwind. Empieza por un tratamiento e identifica su etiqueta, espaciado, radio y estado previsto antes de ajustar el componente React.

La imagen es una muestra de diseño, no evidencia de que tu proyecto Vite contenga un paquete funcional de botones. No demuestra detección de fuentes, salida CSS ni funcionamiento de disabled. Compara el control implementado con la muestra elegida mientras revisas su marcado y estilos calculados. Conserva como observaciones independientes la semejanza visual y el funcionamiento de la aplicación.

Para la pantalla ficticia de preferencias, acuerda una acción principal y un tratamiento secundario discreto. Diseño debe confirmar la apariencia elegida y desarrollo los nombres implementados de variantes. Reutiliza la tabla de aceptación cuando el componente compartido cambie de carpeta o paquete: ese movimiento puede modificar qué fuentes se examinan para detectar utilidades.

Cuando la configuración sea estable, el flujo de Figma a Tailwind permite ampliar el diseño hacia una interfaz mayor. Para el comportamiento del componente, utiliza la guía de aceptación de kits React. Establecer primero el recorrido de estilos ofrece un punto de partida fiable para esas comprobaciones posteriores de diseño e interacción.

Deja una ficha de configuración reproducible

Termina con un registro breve de versiones de dependencias, archivo Vite activo, entrada CSS importada, excepciones de registro de fuentes y comandos de verificación. Incluye las variantes elegidas y la ubicación de la muestra pequeña. Otra persona debería poder repetir la revisión sin reconstruir tu sesión de navegador ni adivinar qué aplicación has ejecutado.

Guarda la ficha junto a las instrucciones de desarrollo y actualízala cuando cambie la integración de compilación. La recomendación es pequeña: una muestra funcional, un recorrido CSS conocido y una compilación de producción comprobada. Ofrece una referencia concreta cuando el siguiente componente copiado aparezca sin estilos, sin convertir el diagnóstico de instalación en un rediseño de toda la aplicación.

Antes de entregar la configuración, utiliza la muestra para un ejercicio controlado. En un cambio temporal de revisión, elimina únicamente la importación CSS de la entrada React y observa qué falla. El atributo de clases del botón puede seguir presente aunque no estén disponibles las reglas previstas. Restaura la importación y comprueba que vuelvan los mismos valores calculados. Mantén este ejercicio fuera de la rama de producción aceptada.

Después selecciona quiet sin editar su lista de clases. Si se comporta de otra manera, compara el atributo y su regla antes de cambiar dependencias. Anota la diferencia: el primer ejercicio probaba que se alcanzaba la hoja; el segundo, la rama de variante. Finaliza restaurando la muestra aceptada y repitiendo las comprobaciones habituales de compilación.