La v4 de Tailwind CSS est sortie fin 2024 et on a pris le temps de migrer entièrement le site du studio dessus. Voici ce qu'on a retenu après un mois d'utilisation quotidienne.
Fini le JavaScript de configuration
Le fichier tailwind.config.js n'existe plus. À la place, on déclare
tout dans du CSS, via les directives @theme et @source :
@import "tailwindcss";
@theme {
--color-ink: oklch(18% 0.02 260);
--color-accent: oklch(68% 0.2 40);
--font-display: "Instrument Serif", serif;
}
@source "../**/*.tsx";
Trois conséquences pratiques :
- Les tokens de design deviennent des variables CSS natives. Pas
besoin de plugin pour les exposer —
var(--color-ink)fonctionne partout. - L'IDE comprend mieux. Finies les surprises quand on renomme une couleur et que l'autocomplétion reste en retard pendant 3 s.
- Le build est quasi-instantané. Oxide (le nouveau moteur en Rust) scanne nos 200+ fichiers en < 50 ms.
OKLCH par défaut, enfin
Les couleurs sont exprimées en OKLCH plutôt qu'en HSL. Deux bénéfices immédiats :
- Les dégradés ne passent plus par des gris sales (le piège classique HSL → HSL quand on traverse la zone 180° ↔ 360°).
- La luminosité est perceptuellement uniforme — un
oklch(60% …)a la même "densité visuelle" quelle que soit la teinte.
Pour un studio qui produit du print et du digital, c'est la fin des écarts d'un support à l'autre.
Le piège du monorepo
Un détail qui nous a coûté deux heures : dans un monorepo pnpm avec un
package UI partagé, Tailwind v4 ne scanne pas automatiquement les
.tsx du package externe. Il faut lui dire explicitement :
/* Dans le globals.css du package UI */
@source "../**/*.tsx";
Sans ça, les classes utilisées dans le package sont purgées — le bouton
primaire arrive en p-0 au runtime, et vous cherchez longtemps.
Ce qui manque encore
- Pas de support officiel pour les variants de thème sombre basés sur
variables CSS (on se dépatouille avec
@media (prefers-color-scheme)manuellement). - Les plugins de l'écosystème v3 ne sont pas tous portés — vérifier la compatibilité avant de migrer un projet ancien.
Globalement, la migration vaut largement l'investissement. La vitesse de build à elle seule change l'expérience de développement.