React Router v8.0.0 erschien am 17. Juni 2026, gefolgt von einem v8.0.1-Patch am darauffolgenden Tag. Es ist das erste Major Release unter dem Open-Governance-Modell des Projekts und das erste in einem geplanten Jahresrhythmus, der bewusst auf das End-of-Life-Fenster von Node 20 abgestimmt ist. Node 22 selbst erreicht laut Plan etwa im Mai 2027 sein End of Life, was das Ziel ist, das das Team für v9 vorsieht. Die Hauptsache ist weniger ein einzelnes Feature als vielmehr eine Höherstufung: Die Aufgabe der API-Entwicklungsstrategie besteht darin, Major Releases langweilig zu machen, indem Breaking Changes früh hinter Future Flags gelandet werden, und v8 ist das Release, in dem jedes future.v8_*-Flag aus v7 zum Standard wird.
Future Flags werden zu Standardwerten hochgestuft
Wenn Sie in v7 alle aktiven Future Flags übernommen hatten, ist die API-Oberfläche von v8 weitgehend unverändert, da diese Flags entfernt oder auf Top-Level-Konfiguration gehoben werden und ihr Verhalten nun bedingungslos ist. Die hochgestuften Flags:
future.v8_trailingSlashAwareDataRequestsentfällt; Data-Request-URLs, die Trailing-Slashes beachten, sind der Standard.future.v8_passThroughRequestsentfällt; die eingehende roherequestwird nun immer anloaderundactiondurchgereicht. Verwenden Sie den Parameterurl, wenn Sie die normalisierte URL ohne React-Router-Interna wie.data-Suffixe und_routes-Search-Params möchten.future.v8_middlewareentfällt; Middleware läuft immer. Dercontext, der an Loader, Actions und Middleware übergeben wird, ist immer einRouterContextProvider,getLoadContextin einem eigenen Server muss einen solchen zurückgeben statt eines einfachen Objekts, der TypMiddlewareEnabledwird entfernt, und der Trick der Modul-Erweiterunginterface Future { v8_middleware: true }wird zum Typisieren voncontextim Data Mode nicht mehr benötigt.future.v8_viteEnvironmentApientfällt; der Build-Pfad über die Vite-Environment-API ist verpflichtend, was erklärt, warum v8 Vite 7+ voraussetzt und warum die alte Pre-Rendering-Implementierung durch den Vite-Preview-Server-Fluss ersetzt wurde.future.v8_splitRouteModuleswird zu einer Top-Level-KonfigurationsoptionsplitRouteModulesund ist standardmäßigtrue. Setzen Sie sie auffalse, um Route-Module in einem einzigen Chunk zu behalten, oder auf"enforce", um zu verlangen, dass jede Route splittbar ist.
Das Bild von der „Höherstufung" ist die eigentliche Geschichte. Future Flags erlauben dem Team, einen Breaking Change in einem v7-Minor zu landen, ihn von Nutzern übernehmen und Feedback geben zu lassen und dann in der Major den Standard umzuschalten, mit einem Jahr Validierung in Produktion im Rücken. v8 ist das Release, das diese Pipeline einlöst.
Neue Baselines: Node 22.22, React 19.2.7, Vite 7 und rein ESM
v8 legt eine neue Baseline-Politik fest, die sich genau zu lesen lohnt. React Router unterstützt nun offiziell alle Active-LTS-Node-Versionen sowie nur den neuesten Minor-Zweig von Maintenance-LTS, sodass es die Maintenance-LTS-Untergrenze schnell anheben kann, wenn ein Security-Patch erscheint (wie bei den Node.js-Security-Releases vom Juni 2026) und zurückportierte Active-LTS-Features übernehmen kann. Für den Start ist diese Untergrenze Node 22.22.0+, neben React 19.2.7+ und Vite 7+.
Um die Bibliothek zu modernisieren, ist jedes veröffentlichte Paket nun rein ESM und die target/lib-Felder des tsconfig wurden durchgehend von ES2020 auf ES2022 angehoben. Diese Entscheidung für rein ESM ist nicht kosmetisch: Sie hat die untenstehenden Adapter-Neuschreibungen erst ermöglicht, weil die Adapter nun direkt andere rein-ESM-Pakete konsumieren konnten.
react-router-dom ist weg, und mit ihm einige als veraltet markierte APIs
Die sichtbarste Entfernung ist react-router-dom. In v7 wurden die DOM-APIs in react-router/dom zusammengefasst, und react-router-dom wurde nur als Re-Export-Shim behalten, damit bestehende v6-Importe weiter funktionierten. Dieser Shim fällt in v8 weg. Jeder verbleibende react-router-dom-Import muss verschoben werden: RouterProvider und HydratedRouter stammen aus react-router/dom, alles andere aus react-router.
Drei weitere Entfernungen runden die Liste ab. Die als veraltet markierten data-Felder, die an die meta-Funktionen der Route-Module übergeben werden, entfallen; verwenden Sie stattdessen loaderData auf MetaArgs und auf jedem Eintrag in MetaArgs.matches (#14931). Der Cloudflare-Dev-Proxy unter @react-router/dev/vite/cloudflare wird zugunsten von @cloudflare/vite-plugin entfernt, was auch wrangler@3 als Peer-Dependency von @react-router/dev ablegt. Und das interne hasErrorBoundary-Feld, das auf router.routes injiziert wurde, entfällt; der Router leitet Error Boundaries nun direkt ab, und hasErrorBoundary wird weder auf RouteObject, DataRouteObject, den JSX-Props von <Route> noch in lazy-Route-Definitionen akzeptiert (#15074).
Adapter-Interna: nativer Fetch, node-fetch-server, tsdown, TypeScript 6
Die Adapter-Schicht erhielt eine leise Neuschreibung, die für jeden zählt, der React Router auf Node betreibt oder Apps mit create-react-router generiert. @react-router/node und @react-router/serve wechseln von @mjackson/node-fetch-server zu @remix-run/node-fetch-server, und create-react-router ersetzt @remix-run/web-fetch durch den nativen fetch von Node. Der praktische Nebeneffekt: create-react-router unterstützt die Umgebungsvariable HTTPS_PROXY, die der alte auf node-fetch basierende Polyfill honoriert hat, nicht mehr (#14929), was gut zu wissen ist, wenn Ihre CI hinter einem Unternehmens-Proxy sitzt.
Auf der Build-Seite ist der Paket-Build von tsup auf tsdown migriert und das TypeScript-Werkzeug auf TypeScript 6 umgestiegen, während einzelne Moduldateien in den veröffentlichten Artefakten erhalten blieben, sodass öffentliche APIs und dokumentierte Importpfade unverändert bleiben (#15092). @react-router/dev hat cookie und set-cookie-parser durch cookie-es ersetzt, die Abhängigkeit vite-node zugunsten der nativen Module-Runner-APIs von Vite entfernt und eine lange Reihe von Abhängigkeiten aktualisiert (Babel auf 7.29, react-refresh auf 0.18, es-module-lexer auf 2.1, chokidar auf 5). Der Express-Adapter benötigt nun Express ^4.22.2 || ^5, und @react-router/serve ist auf Express 5.2.1 umgestiegen.
Der Upgrade-Pfad
Für die meisten Teams ist das Upgrade mechanisch, wenn die Future Flags von v7 bereits aktiviert waren. Die Arbeit besteht darin: Node auf 22.22+, React auf 19.2.7+ und Vite auf 7+ anheben; verbleibende react-router-dom-Importe ersetzen; data in meta-Funktionen zu loaderData umbenennen; und sicherstellen, dass getLoadContext einen RouterContextProvider zurückgibt. Das v7.18.0-Release vom 16. Juni hat außerdem einen Fix der CSRF-Prüflogik geliefert, der hinter einem Reverse Proxy ein potenzieller „brechender Bugfix" ist: Die Prüfung liest nun den host aus der Request-URL statt aus HTTP-Headern, sodass @react-router/serve- oder @react-router/express-Apps ohne aktiviertes trust proxy den internen Host möglicherweise zu allowedActionOrigins hinzufügen müssen. Testen Sie Mutations-Requests im Rahmen des Upgrades.
v8.0.1 (18. Juni) ist ein einzelner Bereinigungs-Patch, der den veralteten AppLoadContext-Typ-Export entfernt, der aus v7 übrig geblieben war, da der Request-Context nun immer über RouterContextProvider läuft (#15207). Er erscheint einen Tag nach dem Major, das selbst in derselben Woche erscheint, in der vue-router seine v5-Linie erreicht. Der Jahresrhythmus und die Future-Flag-Pipeline sorgen dafür, dass das nächste Major diesem hier stark ähneln dürfte: Die meisten Brüche werden bereits in einem v8-Minor geliefert worden sein, und v9 wird im Wesentlichen die Standardwerte umschalten.
