Merge branch 'main' into release-next

brophdawg11 · brophdawg11 · commit 0f06c661f5df · 2025-11-10T12:15:10.000-05:00
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -379,7 +379,7 @@ Date: YYYY-MM-DD
 
 ## v7.9.5
 
-Date: 2025-10-27
+Date: 2025-10-29
 
 ### What's Changed
 
@@ -441,7 +441,7 @@ This release includes a new `unstable_useRoute()` hook that provides a type-safe
 ### Patch Changes
 
 - `@react-router/dev` - Update `valibot` dependency to `^1.1.0` ([#14379](https://github.com/remix-run/react-router/pull/14379))
-- `@react-router/node` - Validate format of incoming session ids ([#14426](https://github.com/remix-run/react-router/pull/14426))
+- `@react-router/node` - Validate format of incoming session ids in `createFileSessionStorage` ([#14426](https://github.com/remix-run/react-router/pull/14426))
 
 ### Unstable Changes
 
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
@@ -107,16 +107,17 @@ This table gives a high-level overview of the stages, but please see the individ
 ### Stage 1 — Consideration
 
 - A proposal enters **Stage 1 — Consideration** when 2 SC members indicate interest/support for the idea as a valuable addition to React Router
-- Upon entering this stage, a GitHub Issue will be created for the feature and added to the roadmap
 - These initial supporting SC members will be the champions for the feature and will be loosely responsible for shepherding the feature through the stages of the RFC process
 - At this stage, the proposal is eligible for a sample PR implementation from a core team or community member
 - The SC will indicate at this stage if this is a feature open to a community PR or something the core team would prefer to tackle
+- We will add the `accepting-prs` label to the RFC if we are open to community PRs
 - All PRs at this stage should implement the feature in an "unstable" fashion (usually using an `unstable_` prefix on the future flag or API)
 
 ### Stage 2 — Alpha
 
 - A proposal enters **Stage 2 — Alpha** once a PR has been opened implementing the feature in an `unstable_` state
 - At this stage, we should open an Issue for the Proposal and add it to the [Roadmap](https://github.com/orgs/remix-run/projects/5)
+- We will remove any `accepting-prs` label and add the `🗺️ Roadmap` label to indicate that this RFc is officially on the roadmap
 - At this stage, we are looking for early community testing _before_ merging any work to the React Router repo — so these PRs should provide a mechanism for community members to opt into to alpha testing
   - Maintainers can trigger an alpha release from the PR branch by adding the `alpha-release` label, which will kick off an experimental release and comment it back on the PR
   - Because the alpha release may contain other work committed to `dev` but not yet released in a stable version, it may not be ideal for testing in all cases
@@ -225,3 +226,24 @@ Matt Brophy, Bryan Ross (rossipedia), Mark Dalgleish, and Pedro Cattori discusse
 - Matt Brophy will try to pick up the [`<Link onPrefetch>`](https://github.com/remix-run/react-router/discussions/12375) task soon
 - Matt Brophy and Pedro Cattori will sync up offline to figure out what parts of the consolidated hook can be done better with typegen and decide on the requirements ([RFC](https://github.com/remix-run/react-router/issues/13073))
 </details>
+
+<details>
+  <summary>2025-11-04 Meeting Notes</summary>
+
+The SC reviewed items on the open Proposal for React Router v8
+
+- Confirmed the plan to drop CJS builds for ESM-only builds
+  - We will plan RR v8 for Q2 2026 which aligns nicely with the EOL for Node 20
+  - v8 will have a minimum Node version of 22.12 so that the `require(esm)` feature is not behind an [experimental flag](https://nodejs.org/docs/latest-v22.x/api/modules.html#loading-ecmascript-modules-using-require)
+- Going forward we will aim for a yearly major release in the same Q2 timeframe
+- We would like to try to get `useRouterState` into v8 as the other half of the `unstable_useRoute` coin
+- We think Subresource Integrity (SRI) is ready for stabilization but we would like to ping a few existing users and/or SME's to confirm the implementation is valid
+- Discussed the `unstable_optimizedDeps` feature, confirming it will remain unstable in V8 and then be pseudo-deprecated in favor of RollDown
+  - There are some concerns about RollDown's full bundle mode limiting scalability so we may need to wait until rolldown is ready for testing
+- Decided against making "type-safe matches" an immediate V8 necessity due to the API churn
+- RSC implementation will not have a stable API ready for V8 but will be released in a minor version later
+  - We will not be deprecating existing APIs at that time because not everyone should have to use RSC
+- `Vite environment API` and `split route modules` are nearing stabilization
+- Reviewed a new RFC to stop URL normalization in loaders
+
+</details>
diff --git a/contributors.yml b/contributors.yml
@@ -129,6 +129,7 @@
 - gaspard
 - gatzjames
 - gavriguy
+- gchang12
 - Geist5000
 - GeoffKarnov
 - gesposito
@@ -322,6 +323,7 @@
 - pruszel
 - pwdcd
 - pyitphyoaung
+- QzCurious
 - redabacha
 - refusado
 - remorses
diff --git a/docs/api/framework-conventions/entry.server.tsx.md b/docs/api/framework-conventions/entry.server.tsx.md
@@ -9,17 +9,18 @@ order: 5
 
 ## Summary
 
-<docs-info>
-This file is optional
-</docs-info>
-
 This file is the server-side entry point that controls how your React Router application generates HTTP responses on the server.
 
 This module should render the markup for the current page using a [`<ServerRouter>`][serverrouter] element with the `context` and `url` for the current request. This markup will (optionally) be re-hydrated once JavaScript loads in the browser using the [client entry module][client-entry].
 
+<docs-info>This file is optional if you are running on Node. If it is not present, a [default implementation][node-streaming-entry-server] will be used.
+<br/>
+<br/>
+If you are using another runtime (i.e., Cloudflare) then you need to include this file. You can find sample implementations in the [templates repository][templates-repo].</docs-info>
+
 ## Generating `entry.server.tsx`
 
-By default, React Router will handle generating the HTTP Response for you. You can reveal the default entry server file with the following:
+When running in Node, React Router will handle generating the HTTP Response for you. You can reveal the default entry server file with the following:
 
 ```shellscript nonumber
 npx react-router reveal
@@ -42,7 +43,7 @@ export default function handleRequest(
   request: Request,
   responseStatusCode: number,
   responseHeaders: Headers,
-  routerContext: EntryContext
+  routerContext: EntryContext,
 ) {
   return new Promise((resolve, reject) => {
     const { pipe, abort } = renderToPipeableStream(
@@ -62,15 +63,15 @@ export default function handleRequest(
             new Response(stream, {
               headers: responseHeaders,
               status: responseStatusCode,
-            })
+            }),
           );
 
           pipe(body);
         },
         onShellError(error: unknown) {
           reject(error);
         },
-      }
+      },
     );
   });
 }
@@ -113,7 +114,7 @@ export function handleDataRequest(
     request,
     params,
     context,
-  }: LoaderFunctionArgs | ActionFunctionArgs
+  }: LoaderFunctionArgs | ActionFunctionArgs,
 ) {
   response.headers.set("X-Custom-Header", "value");
   return response;
@@ -131,7 +132,7 @@ export function handleError(
     request,
     params,
     context,
-  }: LoaderFunctionArgs | ActionFunctionArgs
+  }: LoaderFunctionArgs | ActionFunctionArgs,
 ) {
   if (!request.signal.aborted) {
     sendErrorToErrorReportingService(error);
@@ -155,8 +156,9 @@ For an example, please refer to the default [`entry.server.tsx`][node-streaming-
 Note that this does not handle thrown `Response` instances from your `loader`/`action` functions. The intention of this handler is to find bugs in your code which result in unexpected thrown errors. If you are detecting a scenario and throwing a 401/404/etc. `Response` in your `loader`/`action` then it's an expected flow that is handled by your code. If you also wish to log, or send those to an external service, that should be done at the time you throw the response.
 
 [client-entry]: ./entry.client.tsx
-[serverrouter]: ../components/ServerRouter
-[streaming]: ../how-to/suspense
+[serverrouter]: ../framework-routers/ServerRouter
+[streaming]: ../../how-to/suspense
 [rendertopipeablestream]: https://react.dev/reference/react-dom/server/renderToPipeableStream
 [rendertoreadablestream]: https://react.dev/reference/react-dom/server/renderToReadableStream
 [node-streaming-entry-server]: https://github.com/remix-run/react-router/blob/dev/packages/react-router-dev/config/defaults/entry.server.node.tsx
+[templates-repo]: https://github.com/remix-run/react-router-templates
diff --git a/docs/how-to/error-boundary.md b/docs/how-to/error-boundary.md
@@ -21,7 +21,13 @@ All applications should at a minimum export a root error boundary. This one hand
 - Instances of errors with a stack trace
 - Randomly thrown values
 
-```tsx filename=root.tsx
+### Framework Mode
+
+[modes: framework]
+
+In [Framework Mode][picking-a-mode], errors are passed to the route-level error boundary as a prop (see [`Route.ErrorBoundaryProps`][type-safety]), so you don't need to use a hook to grab it:
+
+```tsx filename=root.tsx lines=[1,3-5]
 import { Route } from "./+types/root";
 
 export function ErrorBoundary({
@@ -51,8 +57,57 @@ export function ErrorBoundary({
 }
 ```
 
+### Data Mode
+
+[modes: data]
+
+In [Data Mode][picking-a-mode], the `ErrorBoundary` doesn't receive props, so you can access it via `useRouteError`:
+
+```tsx lines=[1,6,16]
+import { useRouteError } from "react-router";
+
+let router = createBrowserRouter([
+  {
+    path: "/",
+    ErrorBoundary: RootErrorBoundary,
+    Component: Root,
+  },
+]);
+
+function Root() {
+  /* ... */
+}
+
+function RootErrorBoundary() {
+  let error = useRouteError();
+  if (isRouteErrorResponse(error)) {
+    return (
+      <>
+        <h1>
+          {error.status} {error.statusText}
+        </h1>
+        <p>{error.data}</p>
+      </>
+    );
+  } else if (error instanceof Error) {
+    return (
+      <div>
+        <h1>Error</h1>
+        <p>{error.message}</p>
+        <p>The stack trace is:</p>
+        <pre>{error.stack}</pre>
+      </div>
+    );
+  } else {
+    return <h1>Unknown Error</h1>;
+  }
+}
+```
+
 ## 2. Write a bug
 
+[modes: framework,data]
+
 It's not recommended to intentionally throw errors to force the error boundary to render as a means of control flow. Error Boundaries are primarily for catching unintentional errors in your code.
 
 ```tsx
@@ -67,6 +122,8 @@ This is not just for loaders, but for all route module APIs: loaders, actions, c
 
 ## 3. Throw data in loaders/actions
 
+[modes: framework,data]
+
 There are exceptions to the rule in #2, especially 404s. You can intentionally `throw data()` (with a proper status code) to the closest error boundary when your loader can't find what it needs to render the page. Throw a 404 and move on.
 
 ```tsx
@@ -85,7 +142,13 @@ This will render the `isRouteErrorResponse` branch of the UI from step 1.
 
 ## 4. Nested error boundaries
 
-When an error is thrown, the "closest error boundary" will be rendered. Consider these nested routes:
+When an error is thrown, the "closest error boundary" will be rendered.
+
+### Framework Mode
+
+[modes: framework]
+
+Consider these nested routes:
 
 ```tsx filename="routes.ts"
 // ✅ has error boundary
@@ -110,10 +173,59 @@ The following table shows which error boundary will render given the origin of t
 | invoice-page.tsx | invoice-page.tsx  |
 | payments.tsx     | invoice-page.tsx  |
 
+### Data Mode
+
+[modes: data]
+
+In Data Mode, the equivalent route tree might look like:
+
+```tsx
+let router = createBrowserRouter([
+  {
+    path: "/app",
+    Component: App,
+    ErrorBoundary: AppErrorBoundary, // ✅ has error boundary
+    children: [
+      {
+        path: "invoices",
+        Component: Invoices, // ❌ no error boundary
+        children: [
+          {
+            path: ":id",
+            Component: Invoice,
+            ErrorBoundary: InvoiceErrorBoundary, // ✅ has error boundary
+            children: [
+              {
+                path: "payments",
+                Component: Payments, // ❌ no error boundary
+              },
+            ],
+          },
+        ],
+      },
+    ],
+  },
+]);
+```
+
+The following table shows which error boundary will render given the origin of the error:
+
+| error origin | rendered boundary      |
+| ------------ | ---------------------- |
+| `App`        | `AppErrorBoundary`     |
+| `Invoices`   | `AppErrorBoundary`     |
+| `Invoice`    | `InvoiceErrorBoundary` |
+| `Payments`   | `InvoiceErrorBoundary` |
+
 ## Error Sanitization
 
-In production mode, any errors that happen on the server are automatically sanitized before being sent to the browser to prevent leaking any sensitive server information (like stack traces).
+[modes: framework]
+
+In Framework Mode when building for production, any errors that happen on the server are automatically sanitized before being sent to the browser to prevent leaking any sensitive server information (like stack traces).
 
 This means that a thrown `Error` will have a generic message and no stack trace in production in the browser. The original error is untouched on the server.
 
 Also note that data sent with `throw data(yourData)` is not sanitized as the data there is intended to be rendered.
+
+[picking-a-mode]: ../start/modes
+[type-safety]: ../explanation/type-safety
diff --git a/docs/start/framework/data-loading.md b/docs/start/framework/data-loading.md
@@ -106,7 +106,7 @@ export default function Product({
 }
 ```
 
-The URLs to pre-render are specified in react-router.config.ts:
+The URLs to pre-render are specified in `react-router.config.ts`:
 
 ```ts filename=react-router.config.ts
 import type { Config } from "@react-router/dev/config";
diff --git a/docs/start/framework/route-module.md b/docs/start/framework/route-module.md
@@ -480,7 +480,7 @@ The meta of the last matching route is used, allowing you to override parent rou
 
 ## `shouldRevalidate`
 
-In framework mode with SSR, route loaders are automatically revalidated after all navigations and form submissions (this is different from [Data Mode][data-mode-should-revalidate]). This enables middleware and loaders to share a request context and optimize in different ways than then they would be in Data Mode.
+In framework mode with SSR, route loaders are automatically revalidated after all navigations and form submissions (this is different from [Data Mode][data-mode-should-revalidate]). This enables middleware and loaders to share a request context and optimize in different ways than they would in Data Mode.
 
 Defining this function allows you to opt out of revalidation for a route loader for navigations and form submissions.
 
diff --git a/packages/react-router-node/CHANGELOG.md b/packages/react-router-node/CHANGELOG.md
@@ -11,7 +11,7 @@
 
 ### Patch Changes
 
-- Validate format of incoming session ids ([#14426](https://github.com/remix-run/react-router/pull/14426))
+- Validate format of incoming session ids in `createFileSessionStorage` ([#14426](https://github.com/remix-run/react-router/pull/14426))
 - Updated dependencies:
   - `react-router@7.9.4`
 

Original file line number	Diff line number	Diff line change
`@@ -106,7 +106,7 @@ export default function Product({`
`106`	`106`	`}`
`107`	`107`	```
`108`	`108`
`109`		`-The URLs to pre-render are specified in react-router.config.ts:`
	`109`	+The URLs to pre-render are specified in `react-router.config.ts`:
`110`	`110`
`111`	`111`	```ts filename=react-router.config.ts
`112`	`112`	`import type { Config } from "@react-router/dev/config";`