Tailwind v4 : tout ce qui change et pourquoi c'est important

Tailwind CSS v4 n'est pas une simple mise à jour. C'est une réécriture fondamentale du framework, avec un nouveau moteur, une nouvelle architecture et des changements qui impactent la façon dont on pense le CSS utilitaire. Après des mois en beta, la version stable est sortie et l'écosystème commence à migrer massivement.

Dans cet article, on passe en revue tout ce qui change, pourquoi ces changements ont été faits, et comment migrer vos projets existants.

Un nouveau moteur écrit en Rust

Le changement le plus fondamental est invisible pour l'utilisateur final : le moteur de Tailwind a été entièrement réécrit. Là où v3 utilisait PostCSS et un système de plugins JavaScript, v4 s'appuie sur un moteur natif écrit en Rust (via le projet Oxide).

Les résultats en termes de performance sont spectaculaires :

• Build initial : jusqu'à 10x plus rapide que v3.
• Rebuilds incrémentaux : jusqu'à 100x plus rapides en mode watch.
• Empreinte mémoire : drastiquement réduite.

En pratique, cela signifie que même les plus gros projets compilent en quelques millisecondes. Le hot reload est quasiment instantané.

La configuration passe en CSS

C'est probablement le changement le plus visible : le fichier tailwind.config.js disparaît. Toute la configuration se fait désormais directement en CSS, via la directive @theme :

/* Avant (v3) - tailwind.config.js */
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: '#6366f1',
      },
      fontFamily: {
        sans: ['Inter', 'sans-serif'],
      },
    },
  },
};

/* Après (v4) - votre fichier CSS */
@import "tailwindcss";

@theme {
  --color-brand: #6366f1;
  --font-sans: 'Inter', sans-serif;
  --breakpoint-sm: 640px;
  --breakpoint-md: 768px;
  --breakpoint-lg: 1024px;
}

La directive @theme définit les design tokens de votre projet. Ces tokens sont automatiquement convertis en classes utilitaires. Un --color-brand génère bg-brand, text-brand, border-brand, etc.

La configuration en CSS est un changement philosophique important. Tailwind embrasse désormais pleinement les custom properties CSS natives au lieu de les abstraire derrière du JavaScript.

Import simplifié

Fini les trois directives séparées. Un seul import suffit :

/* Avant (v3) */
@tailwind base;
@tailwind components;
@tailwind utilities;

/* Après (v4) */
@import "tailwindcss";

Simple, propre, élégant. Les layers CSS (@layer) sont utilisés sous le capot pour gérer l'ordre de priorité.

Détection automatique du contenu

En v3, vous deviez spécifier les chemins des fichiers à scanner dans la configuration :

/* v3 - tailwind.config.js */
module.exports = {
  content: [
    './src/**/*.{html,js,jsx,ts,tsx}',
    './public/index.html',
  ],
};

En v4, Tailwind détecte automatiquement les fichiers à scanner. Il parcourt votre projet, identifie les fichiers pertinents et extrait les classes. Plus besoin de configurer quoi que ce soit dans la majorité des cas.

Si vous avez besoin de personnaliser la détection, vous pouvez toujours le faire via la directive @source :

@import "tailwindcss";
@source "../node_modules/my-ui-lib/src";

Nouvelles fonctionnalités

Container queries natives

Les container queries, longtemps gérées via un plugin, sont maintenant intégrées nativement :

<div class="@container">
  <div class="@sm:flex @lg:grid @lg:grid-cols-3">
    ...
  </div>
</div>

Variantes 3D transforms

<div class="rotate-x-45 rotate-y-12 perspective-800">
  Élément en 3D
</div>

Valeurs composées avec des variables

Tailwind v4 gère nativement les valeurs composées en utilisant les custom properties :

<div class="bg-brand/50">
  <!-- background-color: oklch(from var(--color-brand) l c h / 0.5) -->
</div>

Gradients améliorés

<div class="bg-linear-to-r from-indigo-500 via-purple-500 to-pink-500">
  Gradient linéaire
</div>

<div class="bg-conic from-red-500 via-yellow-500 to-green-500">
  Gradient conique
</div>

Les breaking changes

Toute réécriture majeure implique des changements incompatibles. Voici les plus importants :

Espacement mis à jour

L'échelle d'espacement par défaut a été ajustée pour mieux correspondre aux standards de design modernes. Certaines valeurs ont changé :

• p-4 est maintenant 16px (inchangé).
• Les valeurs fractionnaires (p-0.5, p-1.5) utilisent désormais des calculs plus précis.
• L'échelle au-delà de 96 a été étendue.

Couleurs en OKLCH

La palette de couleurs par défaut utilise désormais l'espace couleur OKLCH au lieu de sRGB. Les couleurs sont perceptuellement plus uniformes et les gradients plus naturels.

/* v3 : hex/rgb */
--color-blue-500: #3b82f6;

/* v4 : oklch */
--color-blue-500: oklch(0.623 0.214 259.815);

Suppression de classes dépréciées

• decoration-slice et decoration-clone deviennent box-decoration-slice et box-decoration-clone.
• flex-grow-* et flex-shrink-* deviennent grow-* et shrink-*.
• overflow-ellipsis devient text-ellipsis.
• Les préfixes backdrop- sont simplifiés.

Guide de migration

Tailwind fournit un outil de migration automatique qui gère la majorité des changements :

npx @tailwindcss/upgrade

Cet outil effectue les actions suivantes :

1. Convertit votre tailwind.config.js en directives @theme CSS.
2. Met à jour les classes dépréciées dans vos fichiers source.
3. Ajuste les imports CSS.
4. Génère un rapport des changements manuels nécessaires.

Pour les projets simples, la migration est quasi automatique. Pour les projets avec beaucoup de configuration personnalisée ou de plugins, prévoyez quelques heures de travail manuel.

Plugins et compatibilité

Le système de plugins a été réécrit. Les plugins v3 ne sont pas compatibles directement, mais la plupart des plugins populaires ont été mis à jour. Vérifiez la compatibilité de vos plugins avant de migrer :

• @tailwindcss/typography : mis à jour, intégré au core.
• @tailwindcss/forms : mis à jour.
• @tailwindcss/container-queries : intégré au core, plus besoin du plugin.
• daisyUI : v5 compatible avec Tailwind v4.

Faut-il migrer maintenant ?

La réponse dépend de votre situation :

• Nouveaux projets : utilisez v4 sans hésiter. L'expérience de développement est nettement meilleure.
• Projets en maintenance : migrez progressivement. La v3 continuera à recevoir des correctifs de sécurité pendant au moins un an.
• Projets avec beaucoup de plugins custom : attendez que vos plugins soient compatibles.

Tailwind v4 est le futur du framework. La question n'est pas de savoir si vous allez migrer, mais quand. Plus tôt vous commencez, plus tôt vous bénéficierez des améliorations de performance et des nouvelles fonctionnalités.

Conclusion

Tailwind v4 est une version ambitieuse et aboutie. Le nouveau moteur en Rust offre des performances inégalées, la configuration en CSS est plus intuitive, et les nouvelles fonctionnalités comblent des lacunes de longue date. Les breaking changes sont gérables grâce à l'outil de migration automatique.

C'est aussi un signal fort de maturité pour le framework. En embrassant les standards CSS natifs (custom properties, OKLCH, layers), Tailwind montre qu'il évolue avec la plateforme web plutôt que contre elle. Et c'est de bon augure pour l'avenir du CSS utilitaire.