react-router 8.0.0-pre.1 → 8.0.1

package/docs/how-to/middleware.md

@@ -91,24 +91,18 @@ export default function Dashboard({
 }
 ```
 
-### 3. Update your `getLoadContext` function (if applicable)
+### 3. Add a `getLoadContext` function (if applicable)
 
-If you're using a custom server and a `getLoadContext` function, you will need to update your implementation to return an instance of [`RouterContextProvider`][RouterContextProvider], instead of a JavaScript object:
+If you're using a custom server, you can use a `getLoadContext` function to pass information to into the react router handlers:
 
-```diff
-+import {
-+  createContext,
-+  RouterContextProvider,
-+} from "react-router";
-import { createDb } from "./db";
-
-+const dbContext = createContext<Database>();
+```tsx
+import { RouterContextProvider } from "react-router";
+import { dbContext, createDb } from "./db";
 
 function getLoadContext(req, res) {
--  return { db: createDb() };
-+  const context = new RouterContextProvider();
-+  context.set(dbContext, createDb());
-+  return context;
+  const context = new RouterContextProvider();
+  context.set(dbContext, createDb());
+  return context;
 }
 ```
 
@@ -341,7 +335,7 @@ Client middleware is simpler because since we are already on the client and are
 
 ### Context API
 
-The new context system provides type safety and prevents naming conflicts and allows you to provide data to nested middlewares and `action`/`loader` functions. In Framework Mode, this replaces the previous `AppLoadContext` API.
+The context system provides type safety, prevents naming conflicts, and allows you to provide data to nested middlewares and `action`/`loader` functions.
 
 ```ts
 // ✅ Type-safe
@@ -474,72 +468,6 @@ export const middleware: Route.MiddlewareFunction[] = [
 
 Which `ErrorBoundary` is rendered will differ based on whether your middleware threw _before_ or _after_ calling then `next()` function. If it throws _after_ then it will bubble up from the throwing route just like a normal loader error because we've already run the loaders and have the appropriate `loaderData` to render in the route components. However, if an error is thrown _before_ calling `next()`, then we haven't called any loaders yet and there is no `loaderData` available. When this happens, we must bubble up to the highest route with a `loader` and start looking for an `ErrorBoundary` there. We cannot render any route components at that level or below without any `loaderData`.
 
-## Changes to `getLoadContext`/`AppLoadContext`
-
-<docs-info>This only applies if you are using a custom server and a custom `getLoadContext` function</docs-info>
-
-Middleware introduces a breaking change to the `context` parameter generated by `getLoadContext` and passed to your `action`s and `loader`s. The current approach of a module-augmented `AppLoadContext` isn't really type-safe and instead just sort of tells TypeScript to "trust me".
-
-Middleware needs an equivalent `context` on the client for `clientMiddleware`, but we didn't want to duplicate this pattern from the server that we already weren't thrilled with, so we decided to introduce a new API where we could tackle type-safety.
-
-When opting into middleware, the `context` parameter changes to an instance of [`RouterContextProvider`][RouterContextProvider]:
-
-```ts
-let dbContext = createContext<Database>();
-let context = new RouterContextProvider();
-context.set(dbContext, getDb());
-//                     ^ type-safe
-let db = context.get(dbContext);
-//  ^ Database
-```
-
-If you're using a custom server and a `getLoadContext` function, you will need to update your implementation to return an instance of [`RouterContextProvider`][RouterContextProvider], instead of a plain JavaScript object:
-
-```diff
-+import {
-+  createContext,
-+  RouterContextProvider,
-+} from "react-router";
-import { createDb } from "./db";
-
-+const dbContext = createContext<Database>();
-
-function getLoadContext(req, res) {
--  return { db: createDb() };
-+  const context = new RouterContextProvider();
-+  context.set(dbContext, createDb());
-+  return context;
-}
-```
-
-### Migration from `AppLoadContext`
-
-If you're currently using `AppLoadContext`, you can migrate incrementally by using your existing module augmentation to augment [`RouterContextProvider`][RouterContextProvider] instead of `AppLoadContext`. Then, update your `getLoadContext` function to return an instance of [`RouterContextProvider`][RouterContextProvider]:
-
-```diff
-declare module "react-router" {
--  interface AppLoadContext {
-+  interface RouterContextProvider {
-    db: Database;
-    user: User;
-  }
-}
-
-function getLoadContext() {
-  const loadContext = {...};
--  return loadContext;
-+  let context = new RouterContextProvider();
-+  Object.assign(context, loadContext);
-+  return context;
-}
-```
-
-This allows you to leave your `action`s/`loader`s untouched during initial adoption of middleware, since they can still read values directly (i.e., `context.db`).
-
-<docs-warning>This approach is only intended to be used as a migration strategy when adopting middleware in React Router v7, allowing you to incrementally migrate to `context.set`/`context.get`. It is not safe to assume this approach will work in the next major version of React Router.</docs-warning>
-
-<docs-warning>The [`RouterContextProvider`][RouterContextProvider] class is also used for the client-side `context` parameter via `<HydratedRouter getContext>` and `<RouterProvider getContext>`. Since `AppLoadContext` is primarily intended as a hand-off from your HTTP server into the React Router handlers, you need to be aware that these augmented fields will not be available in `clientMiddleware`, `clientLoader`, or `clientAction` functions even thought TypeScript will tell you they are (unless, of course, you provide the fields via `getContext` on the client).</docs-warning>
-
 ## Common Patterns
 
 ### Authentication
@@ -700,24 +628,15 @@ export async function loader({
 }
 ```
 
-[future-flags]: ../upgrading/future
 [Response]: https://developer.mozilla.org/en-US/docs/Web/API/Response
 [common-patterns]: #common-patterns
 [server-client]: #server-vs-client-middleware
-[create-browser-router]: ../api/data-routers/createBrowserRouter
-[create-hash-router]: ../api/data-routers/createHashRouter
-[create-memory-router]: ../api/data-routers/createMemoryRouter
-[create-static-handler]: ../api/data-routers/createStaticHandler
 [framework-action]: ../start/framework/route-module#action
 [framework-loader]: ../start/framework/route-module#loader
-[getloadcontext]: #changes-to-getloadcontextapploadcontext
 [datastrategy]: ../api/data-routers/createBrowserRouter#optsdatastrategy
 [cms-redirect]: #cms-redirect-on-404
 [createContext]: ../api/utils/createContext
-[RouterContextProvider]: ../api/utils/RouterContextProvider
 [getContext]: ../api/data-routers/createBrowserRouter#optsgetContext
-[window]: https://developer.mozilla.org/en-US/docs/Web/API/Window
-[document]: https://developer.mozilla.org/en-US/docs/Web/API/Document
 [request]: https://developer.mozilla.org/en-US/docs/Web/API/Request
 [data-action]: ../start/data/route-object#action
 [data-loader]: ../start/data/route-object#loader

package/docs/how-to/route-module-type-safety.md

@@ -50,22 +50,7 @@ If you want to run type checking as its own command — for example, as part of
 }
 ```
 
-## 4. Typing `AppLoadContext`
-
-## Extending app `Context` types
-
-To define your app's `context` type, add the following in a `.ts` or `.d.ts` file within your project:
-
-```typescript
-import "react-router";
-declare module "react-router" {
-  interface AppLoadContext {
-    // add context properties here
-  }
-}
-```
-
-## 5. Type-only auto-imports (optional)
+## 4. Type-only auto-imports (optional)
 
 When auto-importing the `Route` type helper, TypeScript will generate:
 

package/docs/how-to/status.md

@@ -54,7 +54,7 @@ export async function loader({ params }: Route.ActionArgs) {
   let project = await fakeDb.getProject(params.id);
   if (!project) {
     // throw to ErrorBoundary
-    throw data(null, { status: 404 });
+    throw data("Not Found", { status: 404 });
   }
   return project;
 }

package/docs/index.md

@@ -5,7 +5,7 @@ order: 1
 
 # React Router Home
 
-React Router is a multi-strategy router for React bridging the gap from React 18 to React 19. You can use it maximally as a React framework or as minimally as you want.
+React Router is a multi-strategy router for React. You can use it maximally as a React framework or as minimally as you want.
 
 ## Getting Started
 
@@ -29,11 +29,8 @@ These icons indicate which mode the content is relevant to.
 
 Additional auto-generated reference documentation is available:
 
-[Autogenerated Reference Docs ↗](https://api.reactrouter.com/v7/)
+[Autogenerated Reference Docs ↗](https://api.reactrouter.com/v8/)
 
 ## Upgrading
 
-If you are caught up on future flags, upgrading from React Router v6 or Remix v2 is generally non-breaking. Remix v2 apps are encouraged to upgrade to React Router v7.
-
-- [Upgrade from v6](./upgrading/v6)
-- [Upgrade from Remix](./upgrading/remix)
+If you are caught up on future flags, [upgrading from React Router v7](./upgrading/v7) is generally non-breaking.

package/docs/start/framework/deploying.md

@@ -97,4 +97,4 @@ EdgeOne Pages maintains their own template for React Router. Checkout the [EdgeO
 
 ### DeployHQ
 
-DeployHQ maintains their own guide for deploying React Router v7 to your own server. Checkout the [DeployHQ Guide](https://www.deployhq.com/guides/deploy-react-router-from-github) for more information.
+DeployHQ maintains their own guide for deploying React Router to your own server. Checkout the [DeployHQ Guide](https://www.deployhq.com/guides/deploy-react-router-from-github) for more information.

package/docs/start/modes.md

@@ -98,7 +98,6 @@ Every mode supports any architecture and deployment target, so the question isn'
 - are considering Next.js, Solid Start, SvelteKit, Astro, TanStack Start, etc. and want to compare
 - just want to build something with React
 - might want to server render, might not
-- are coming from Remix (React Router v7 is the "next version" after Remix v2)
 - are migrating from Next.js
 
 [→ Get Started with Framework Mode](./framework/installation).
@@ -113,7 +112,7 @@ Every mode supports any architecture and deployment target, so the question isn'
 **Use Declarative Mode if you:**
 
 - want to use React Router as simply as possible
-- are coming from v6 and are happy with the `<BrowserRouter>`
+- are coming from earlier React Router versions and are happy with the `<BrowserRouter>`
 - have a data layer that either skips pending states (like local first, background data replication/sync) or has its own abstractions for them
 - are coming from Create React App (you may want to consider framework mode though)
 

package/docs/upgrading/component-routes.md

@@ -28,8 +28,8 @@ The initial setup requires the most work. However, once complete, you can adopt
 
 To use the Vite plugin, your project requires:
 
-- Node.js 20+ (if using Node as your runtime)
-- Vite 5+
+- Node.js 22.22.0+
+- Vite 7+ or Vite 8+
 
 ## 1. Install the Vite plugin
 

package/docs/upgrading/future.md

@@ -1,31 +1,78 @@
 ---
-title: Future Flags
+title: Future Changes
 order: 1
 ---
 
-# Future Flags and Deprecations
+# Future Changes
 
-This guide walks you through the process of adopting future flags in your React Router app. By following this strategy, you will be able to upgrade to the next major version of React Router with minimal changes. To read more about future flags see [API Development Strategy][api-development-strategy].
+We try our best to keep major version upgrades simple and boring through the use of opt-in APIs and [Future Flags][api-development-strategy]. Future flags are used to gate breaking changes that don't otherwise have a good call-site opt-in strategy. By adopting all opt-in APIs and future flags, you should be able to upgrade to the next major version of React Router with minimal changes.
+
+We plan to ship new major versions roughly once a year as described in our [Open Governance Model][governance], so this guide will continue to track future changes you can adopt ahead of the next major release. v9 is currently estimated for mid-2027 when Node 22 reaches EOL.
 
 We highly recommend you make a commit after each step and ship it instead of doing everything all at once. Most flags can be adopted in any order, with exceptions noted below.
 
-## Update to latest v7.x
+<docs-info>This is an evolving document that will be updated throughout the duration of v8</docs-info>
+
+## Minimum Versions
+
+[MODES: framework, data, declarative]
+
+<br/>
+<br/>
+
+React Router v9 will require the following minimum versions (as of now). You can prepare for the upgrade by updating them while still on v8:
+
+- `node@24+`
 
-First update to the latest minor version of v7.x to have the latest future flags. You may see a number of deprecation warnings as you upgrade, which we'll cover below.
+## Update to latest v8.x
 
-👉 Update to latest v7
+Before adopting any future flags or call-site opt-in changes, you should update to the latest minor version of v8.x to make sure you have access to the latest flags. You may see a number of deprecation warnings as you upgrade, which we'll cover below.
+
+👉 Update to latest v8
 
 ```sh
-npm install react-router@7 @react-router/{dev,node,etc.}@7
+npm install react-router@8 @react-router/{dev,node,etc.}@8
 ```
 
+## Future Flags
+
+_No future flags yet_
+
+## Other Planned Breaking Changes
+
+_No known planned breaking changes yet_
+
 ## Unstable Future Flags (Optional)
 
-We document some [unstable] flags here as a reference for folks contributing to the project via beta testing, but they are not generally recommended for production use and may having breaking changes patch/minor releases - adopt with caution!
+We document some [unstable] flags here as a reference for folks contributing to the project via beta testing, but they are not generally recommended for production use and may have breaking changes in patch or minor releases - adopt with caution!
+
+### `future.unstable_optimizeDeps`
+
+[MODES: framework]
+
+<br/>
+<br/>
+
+**Background**
+
+This flag lets React Router provide Vite's dependency optimizer with the client entry file and route module files. This can improve dependency optimization in development, but the behavior is still experimental.
+
+👉 **Enable the Flag**
+
+```ts filename=react-router.config.ts
+import type { Config } from "@react-router/dev/config";
+
+export default {
+  future: {
+    unstable_optimizeDeps: true,
+  },
+} satisfies Config;
+```
+
+**Update your Code**
 
-_No current unstable flags to document_
+No code changes are required. If you run into dependency optimization issues after enabling this flag, remove the flag and restart the dev server.
 
 [api-development-strategy]: ../community/api-development-strategy
+[governance]: https://github.com/remix-run/react-router/blob/main/GOVERNANCE.md#design-goals
 [unstable]: ../community/api-development-strategy#unstable-flags
-[observability]: ../how-to/instrumentation
-[vite-environment]: https://vite.dev/guide/api-environment

package/docs/upgrading/router-provider.md

@@ -26,8 +26,8 @@ The initial setup requires the most work. However, once complete, you can adopt
 
 To use the Vite plugin, your project requires:
 
-- Node.js 20+ (if using Node as your runtime)
-- Vite 5+
+- Node.js 22.22.0+
+- Vite 7+ or Vite 8+
 
 ## 1. Move route definitions into route modules
 
@@ -276,7 +276,10 @@ If your current `src/main.tsx` looks like this:
 ```tsx filename=src/main.tsx
 import React from "react";
 import ReactDOM from "react-dom/client";
-import { BrowserRouter } from "react-router";
+import {
+  createBrowserRouter,
+  RouterProvider,
+} from "react-router";
 import App from "./App";
 
 const router = createBrowserRouter([