React Router v8.0.0 est sorti le 17 juin 2026, suivi d'un correctif v8.0.1 le lendemain. C'est la première version majeure sous le modèle de gouvernance ouverte du projet et la première d'un rythme annuel planifié, délibérément calée sur la fenêtre de fin de vie de Node 20. Node 22 lui-même est prévu pour atteindre sa fin de vie autour de mai 2027, ce qui est la cible que l'équipe fixe pour la v9. L'élément principal n'est pas tant une fonctionnalité unique qu'une promotion : le travail de la stratégie de développement des API est de rendre les versions majeures ennuyeuses en livrant les changements cassants tôt derrière des Future Flags, et la v8 est la version où chaque indicateur future.v8_* de la v7 devient la valeur par défaut.
Les Future Flags sont promues en valeurs par défaut
Si vous aviez adopté tous les indicateurs futurs actifs en v7, la surface d'API de la v8 est largement inchangée, parce que ces indicateurs sont supprimés ou promus en configuration de premier niveau et que leur comportement est désormais inconditionnel. Les indicateurs qui ont été promus :
future.v8_trailingSlashAwareDataRequestsdisparaît ; les URL de requêtes de données sensibles au slash final sont la valeur par défaut.future.v8_passThroughRequestsdisparaît ; larequestentrante brute est désormais toujours transmise àloaderetaction. Utilisez le paramètreurlquand vous voulez l'URL normalisée sans les détails internes de React Router comme les suffixes.dataet les paramètres de recherche_routes.future.v8_middlewaredisparaît ; le middleware s'exécute toujours. Lecontextpassé aux loaders, actions et middlewares est toujours unRouterContextProvider,getLoadContextdans un serveur personnalisé doit en retourner un plutôt qu'un objet simple, le typeMiddlewareEnabledest supprimé, et l'astuce d'augmentationinterface Future { v8_middleware: true }n'est plus nécessaire pour typercontexten Data Mode.future.v8_viteEnvironmentApidisparaît ; le chemin de build via l'API Vite Environment est obligatoire, ce qui explique pourquoi la v8 requiert Vite 7+ et pourquoi l'ancienne implémentation de pré-rendu a été remplacée par le flux du serveur de prévisualisation Vite.future.v8_splitRouteModulesdevient une option de configuration de premier niveausplitRouteModuleset vauttruepar défaut. Mettez-la àfalsepour garder les modules de route dans un seul chunk, ou à"enforce"pour exiger que chaque route soit découplable.
L'idée de « promotion » est la véritable histoire. Les future flags permettent à l'équipe de livrer un changement cassant dans une mineure de v7, de laisser les utilisateurs l'adopter et faire remonter leurs retours, puis de basculer la valeur par défaut dans la majeure avec un an de validation en production derrière elle. La v8 est la version qui concrétise ce pipeline.
Nouvelles bases minimales : Node 22.22, React 19.2.7, Vite 7 et ESM uniquement
La v8 fixe une nouvelle politique de base minimale qu'il vaut la peine de lire en détail. React Router prend désormais officiellement en charge toutes les versions Active LTS de Node et uniquement la dernière branche mineure de Maintenance LTS, ce qui lui permet de relever rapidement le plancher Maintenance LTS quand un correctif de sécurité paraît (comme lors des versions de sécurité Node.js de juin 2026) et d'adopter les fonctionnalités Active LTS qui sont rétroportées. Pour le lancement, ce plancher est Node 22.22.0+, aux côtés de React 19.2.7+ et Vite 7+.
Pour moderniser la bibliothèque, tous les paquets publiés sont désormais en ESM uniquement et les champs target/lib du tsconfig sont passés de ES2020 à ES2022 partout. Cette décision ESM uniquement n'est pas cosmétique : c'est elle qui a débloqué les réécritures d'adaptateurs ci-dessous, parce que les adaptateurs pouvaient enfin consommer directement d'autres paquets en ESM uniquement.
react-router-dom disparaît, ainsi que quelques API dépréciées
La suppression la plus visible est react-router-dom. En v7, les API DOM avaient été regroupées dans react-router/dom, et react-router-dom n'était conservé que comme couche de réexportation pour que les importations existantes de v6 continuent de fonctionner. La couche disparaît en v8. Toute importation restante de react-router-dom doit être déplacée : RouterProvider et HydratedRouter proviennent de react-router/dom, tout le reste de react-router.
Trois autres suppressions complètent la liste. Les champs data dépréciés passés aux fonctions meta des modules de route disparaissent ; utilisez loaderData à la place sur MetaArgs et sur chaque élément de MetaArgs.matches (#14931). Le proxy de développement Cloudflare à @react-router/dev/vite/cloudflare est supprimé au profit de @cloudflare/vite-plugin, ce qui abandonne aussi wrangler@3 comme dépendance de paire de @react-router/dev. Et le champ interne hasErrorBoundary injecté sur router.routes disparaît ; le routeur déduit désormais les limites d'erreur directement, et hasErrorBoundary n'est plus accepté sur RouteObject, DataRouteObject, les props JSX de <Route>, ni les définitions de route lazy (#15074).
Internes des adaptateurs : fetch natif, node-fetch-server, tsdown, TypeScript 6
La couche d'adaptateurs a reçu une réécriture discrète qui compte pour quiconque fait tourner React Router sur Node ou génère des applications avec create-react-router. @react-router/node et @react-router/serve passent de @mjackson/node-fetch-server à @remix-run/node-fetch-server, et create-react-router remplace @remix-run/web-fetch par le fetch natif de Node. L'effet de bord pratique : create-react-router ne prend plus en charge la variable d'environnement HTTPS_PROXY que l'ancien polyfill basé sur node-fetch honorait (#14929), ce qu'il est bon de savoir si votre CI se trouve derrière un proxy d'entreprise.
Côté build, le build des paquets a migré de tsup vers tsdown et l'outillage TypeScript est passé à TypeScript 6, tout en préservant les fichiers de modules individuels dans les artefacts publiés afin que les API publiques et les chemins d'import documentés restent inchangés (#15092). @react-router/dev a remplacé cookie et set-cookie-parser par cookie-es, supprimé la dépendance vite-node au profit des API natives de module runner de Vite, et mis à jour une longue traîne de dépendances (Babel en 7.29, react-refresh en 0.18, es-module-lexer en 2.1, chokidar en 5). L'adaptateur Express requiert désormais Express ^4.22.2 || ^5, et @react-router/serve est passé à Express 5.2.1.
Le chemin de mise à jour
Pour la plupart des équipes, la mise à jour est mécanique si les future flags de v7 étaient déjà activées. Le travail consiste à : monter Node en 22.22+, React en 19.2.7+ et Vite en 7+ ; remplacer toute importation persistante de react-router-dom ; renommer data en loaderData dans les fonctions meta ; et s'assurer que getLoadContext retourne un RouterContextProvider. La version v7.18.0 du 16 juin a également livré un correctif de logique de vérification CSRF qui constitue un potentiel « correctif cassant » derrière un reverse proxy : la vérification lit désormais le host depuis l'URL de la requête plutôt que depuis les en-têtes HTTP, donc les applications @react-router/serve ou @react-router/express sans trust proxy activé peuvent avoir besoin d'ajouter l'hôte interne à allowedActionOrigins. Testez les requêtes de mutation dans le cadre de la mise à jour.
La v8.0.1 (18 juin) est un correctif de nettoyage unique qui supprime l'export de type AppLoadContext obsolète hérité de v7, maintenant que le contexte de requête passe toujours par RouterContextProvider (#15207). Elle arrive un jour après la majeure, qui elle-même arrive la même semaine que vue-router atteint sa branche v5. Le rythme annuel et le pipeline des future flags font que la prochaine majeure devrait ressembler beaucoup à celle-ci : la plupart des ruptures auront déjà été livrées dans une mineure de v8, et la v9 se contentera essentiellement de basculer les valeurs par défaut.
