Depuis l'annonce de React Compiler 1.0 en octobre 2025, la question qui revient sans cesse est : comment savoir, avant de lancer un build, que ton code respecte les règles que le compilateur attend ? Jusqu'ici, la réponse passait par un plugin Babel qu'il fallait brancher à sa chaîne de build pour voir les diagnostics. Depuis 2026, l'équipe React a déplacé une bonne partie de cette intelligence directement dans eslint-plugin-react-hooks, qui est passé coup sur coup des versions 6 à 7.

Résultat concret : certaines erreurs qui ne se révélaient qu'à l'exécution, ou pire, qu'en production après une optimisation silencieuse du compilateur, s'affichent maintenant comme un simple soulignement rouge dans VS Code. Voici ce qui a changé, pourquoi ça compte, et comment migrer ton projet sans mauvaise surprise.

Ce déplacement n'est pas anecdotique. React Compiler fonctionne en mémoïsant automatiquement les composants et les valeurs calculées, à condition que ton code respecte certaines hypothèses : un rendu doit être idempotent, les props et l'état ne doivent jamais être mutés directement, et les effets de bord doivent rester dans des effets ou des gestionnaires d'événements. Tant que ces règles n'étaient vérifiées qu'au build, un développeur pouvait introduire une violation sans s'en apercevoir avant un rendu étrange en préproduction. En les faisant remonter dans l'éditeur, l'équipe React traite ces contraintes comme des erreurs de syntaxe plutôt que comme des bugs de comportement.

De la v6 à la v7 : une accélération en plusieurs étapes

Le chemin n'a pas été parfaitement linéaire. La version 6.0.0 a été publiée puis quasiment aussitôt dépréciée et retirée de npm suite à un problème de publication — la vraie première version de la série est donc la 6.1.0. Elle a apporté un changement structurant : la flat config (le format eslint.config.js introduit par ESLint 9) devient le preset recommended par défaut, reléguant l'ancien format .eslintrc à un preset recommended-legacy séparé.

La 6.1.0 a aussi ajouté deux nouvelles règles de détection classiques : une qui interdit d'appeler use à l'intérieur d'un bloc try/catch, et une autre qui repère les appels à des fonctions useEffectEvent depuis une closure arbitraire plutôt que depuis un gestionnaire d'événement direct. La 6.1.1, dans la foulée, a introduit le preset recommended-latest : un preset "bord de route" qui embarque, en plus des règles classiques, les diagnostics produits par le moteur d'analyse statique de React Compiler lui-même.

La v7.0.0 a ensuite fait le ménage : seulement deux presets restent, recommended et recommended-latest, et toutes les règles liées au compilateur y sont activées par défaut (plus besoin d'installer eslint-plugin-react-compiler à part). La 7.0.1 a corrigé un détail d'export pour les projets Node16 en ESM, et la version stable la plus récente disponible, la 7.1.1, date d'avril 2026.

Les règles qui comptent vraiment au quotidien

Le changement le plus visible n'est pas dans la tuyauterie des presets, mais dans ce que le linter attrape désormais. Voici les règles qui reviennent le plus souvent en pratique :

set-state-in-effect

Cette règle signale un appel synchrone à un setter d'état directement dans le corps d'un useEffect, sans dépendre d'un événement externe (listener, timer, callback réseau). C'est exactement le pattern qui déclenche un double rendu inutile — et que React Compiler ne peut pas optimiser correctement.

// ❌ Signalé par set-state-in-effect
function Profile({ userId }) {
  const [name, setName] = useState('');

  useEffect(() => {
    // dérive un état à partir des props : préfère le calculer au rendu
    setName(userId.toUpperCase());
  }, [userId]);

  return <p>{name}</p>;
}

// ✅ Correction : calcule la valeur pendant le rendu
function Profile({ userId }) {
  const name = userId.toUpperCase();
  return <p>{name}</p>;
}

immutability

Cette règle, directement issue du moteur d'analyse de React Compiler, détecte les mutations en place de valeurs qui doivent rester stables entre deux rendus : props, état, ou valeurs mémoïsées. Une mutation directe (props.items.push(x), une réassignation de propriété) casse les hypothèses que le compilateur utilise pour mémoïser automatiquement un composant.

// ❌ Signalé par immutability
function List({ items }) {
  function addItem(item) {
    items.push(item); // mutation directe d'une prop
  }
  // ...
}

// ✅ Correction : on recrée un nouveau tableau
function List({ items, onAdd }) {
  function addItem(item) {
    onAdd([...items, item]);
  }
  // ...
}

Autres règles à connaître

error-boundaries : vérifie que les erreurs possibles dans un composant mémoïsé par le compilateur restent correctement capturées par une error boundary.
component-hook-factories : repère les fonctions qui créent dynamiquement des composants ou des hooks (patterns incompatibles avec la mémoïsation statique du compilateur).
gating et config : liées aux options de déploiement progressif du compilateur (rollout par feature flag).
globals : signale l'accès à des variables globales mutables depuis un composant, un autre casse-tête pour la mémoïsation automatique.

Le point commun entre toutes ces règles : elles ne cherchent pas des bugs au sens classique, mais des violations des règles des composants React (idempotence du rendu, immutabilité des props et de l'état) que React Compiler suppose vraies pour pouvoir optimiser ton code sans risque.

Intégrer la vérification à la CI

Ces règles ne servent à rien si elles ne s'affichent que dans l'éditeur d'une partie de l'équipe. La bonne pratique consiste à faire échouer la CI dès qu'une violation apparaît, exactement comme pour n'importe quelle autre règle ESLint :

// package.json
{
  "scripts": {
    "lint": "eslint . --max-warnings=0"
  }
}

Le drapeau --max-warnings=0 est important : par défaut, ESLint n'échoue que sur les erreurs, pas sur les avertissements, et plusieurs règles du preset recommended-latest sont volontairement classées en warning plutôt qu'en error tant qu'elles sont jugées expérimentales. Sans ce drapeau, une équipe peut accumuler des dizaines de violations silencieuses pendant des mois avant de les remarquer.

Si ton projet utilise déjà Oxlint ou un autre linter Rust en complément d'ESLint pour la vitesse, garde en tête que ces outils tiers n'implémentent pas encore les diagnostics propres à React Compiler : ils vérifient la syntaxe et les patterns JavaScript génériques, pas les hypothèses de mémoïsation spécifiques à React. Pour l'instant, eslint-plugin-react-hooks reste la seule source fiable pour ces règles-là, donc le conserver dans la chaîne même si le reste du lint tourne sur un outil plus rapide.

Migrer ton projet sans douleur

Si ton projet est déjà sur ESLint 9 avec une flat config, la mise à jour est directe :

npm install -D eslint-plugin-react-hooks@latest

Puis dans eslint.config.js :

import reactHooks from 'eslint-plugin-react-hooks';

export default [
  // preset stable : règles historiques + règles compilateur validées
  reactHooks.configs['recommended'],

  // ou, si tu veux tester les diagnostics les plus récents du compilateur
  // reactHooks.configs['recommended-latest'],
];

Pour un projet encore sur l'ancien format .eslintrc, utilise recommended-legacy à la place de recommended — le preset bord de route équivalent, recommended-latest-legacy, existait jusqu'en v6 mais a été supprimé en v7 : il faut alors migrer vers la flat config pour continuer à profiter des dernières règles.

Faut-il activer recommended-latest dès maintenant ?

Le preset recommended-latest expose volontairement des règles encore expérimentales : elles peuvent produire des faux positifs ou changer de comportement d'une version mineure à l'autre. Si ton équipe découvre React Compiler, commence par recommended seul, corrige les violations une par une — elles pointent presque toujours vers un vrai problème de robustesse du composant — puis bascule sur recommended-latest une fois le code de base assaini. Activer les deux presets d'un coup sur un gros monorepo legacy revient à se noyer sous des centaines d'avertissements le même jour, ce qui décourage plus qu'autre chose.

Ce qu'il faut retenir

L'intérêt réel de cette évolution, ce n'est pas la nouveauté des règles en elles-mêmes — beaucoup existaient déjà sous une forme ou une autre dans le plugin Babel du compilateur. C'est leur déplacement vers l'éditeur, au moment où tu écris le code, plutôt qu'au moment où tu buildes ou, pire, en observant un bug en production. Si tu utilises déjà React Compiler ou que tu envisages de l'activer, mettre à jour eslint-plugin-react-hooks vers la 7.1.1 et basculer sur le preset recommended est désormais l'étape la moins coûteuse et la plus rentable pour sécuriser la transition.

ESLint-plugin-react-hooks v7 : le compilateur débarque dans le linter