remix 3.0.0-rc.3 → 3.0.0-rc.4

package/INDEX.md

@@ -13,7 +13,14 @@ Search this generated index by task, export name, or description. Use the guides
 | [Interactivity](guides/05-interactivity.md) | How server-rendered UI hydrates, handles events, connects components to application models, navigates, and cancels stale work. |
 | [Streaming UI with Frames](guides/06-streaming-ui-with-frames.md) | How to stream and reload route-owned UI with Frame, fallbacks, and server and browser frame resolvers. |
 | [Animation](guides/07-animation.md) | The CSS-first animation model and Remix UI helpers for motion that respects rendering state. |
+| [Data and Validation](guides/08-data-and-validation.md) | How Remix validates inputs, defines relational data, queries databases, and runs SQL migrations. |
+| [Forms and Mutations](guides/09-forms-and-mutations.md) | How native forms, action responses, validation failures, redirects, and enhanced mutations fit together. |
+| [Auth, Sessions, and Security](guides/10-auth-sessions-security.md) | How Remix stores per-browser state, resolves identity, protects routes, and defends browser request boundaries. |
+| [Files and Assets](guides/11-files-and-assets.md) | How Remix serves static files and source assets, accepts bounded uploads, stores files, and returns HTTP file responses. |
+| [Errors and Cancellation](guides/12-errors-and-cancellation.md) | How expected HTTP failures, uncaught server errors, rendering failures, client runtime errors, and aborted work propagate through Remix. |
 | [Testing](guides/13-testing.md) | How to choose a test boundary and test Remix routes, stateful request flows, components, and end-to-end behavior. |
+| [CLI and Tooling](guides/14-cli-and-tooling.md) | The Remix command-line workflow for creating, inspecting, testing, checking, and running TypeScript projects. |
+| [Production](guides/15-production.md) | How to configure, start, cache, observe, and shut down a Remix application in production. |
 
 ## Package APIs
 

package/dist/fetch-router.d.ts

@@ -1,7 +1,5 @@
+import type { RouterTypes as RemixRouterTypes } from './index.ts';
 export * from '@remix-run/fetch-router';
-export interface RouterTypes {
-}
-type RemixRouterTypes = RouterTypes;
 declare module '@remix-run/fetch-router' {
     interface RouterTypes extends RemixRouterTypes {
     }

package/dist/fetch-router.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"fetch-router.d.ts","sourceRoot":"","sources":["../src/fetch-router.ts"],"names":[],"mappings":"AACA,cAAc,yBAAyB,CAAA;AAEvC,MAAM,WAAW,WAAW;CAAG;AAC/B,KAAK,gBAAgB,GAAG,WAAW,CAAA;AAEnC,OAAO,QAAQ,yBAAyB,CAAC;IACvC,UAAU,WAAY,SAAQ,gBAAgB;KAAG;CAClD"}
+{"version":3,"file":"fetch-router.d.ts","sourceRoot":"","sources":["../src/fetch-router.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,WAAW,IAAI,gBAAgB,EAAE,MAAM,YAAY,CAAA;AACjE,cAAc,yBAAyB,CAAA;AAEvC,OAAO,QAAQ,yBAAyB,CAAC;IACvC,UAAU,WAAY,SAAQ,gBAAgB;KAAG;CAClD"}

package/dist/fetch-router.js

@@ -1,2 +1 @@
-// IMPORTANT: This file is auto-generated, please do not edit manually.
 export * from '@remix-run/fetch-router';

package/dist/index.d.ts

@@ -0,0 +1,18 @@
+// IMPORTANT: This file is auto-generated, please do not edit manually.
+/**
+ * Ambient router type configuration for application-wide defaults.
+ *
+ * Apps may augment this interface to define the default request context used by
+ * `createAction()`, `createController()`, and `getContext()`.
+ * Apps with multiple routers should pass explicit context types instead.
+ *
+ * @example
+ * ```ts
+ * declare module 'remix' {
+ *   interface RouterTypes {
+ *     context: AppContext
+ *   }
+ * }
+ * ```
+ */
+export interface RouterTypes {}

package/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AACA;;;;;;;;;;;;;;;GAeG;AACH,MAAM,WAAW,WAAW;CAAG"}

package/dist/index.js

@@ -0,0 +1 @@
+export {};

package/guides/01-start-here.md

@@ -13,7 +13,7 @@ These APIs ship together through focused subpath imports from the `remix` packag
 
 The design of Remix comes from six core principles:
 
-1. **Agent-First Development.** Remix optimizes source code, documentation, tooling, and abstractions for LLMs, and provides primitives for using models inside the products you build.
+1. **Model-First Development.** Remix optimizes source code, documentation, tooling, and abstractions for LLMs, and provides primitives for using models inside the products you build.
 2. **Build on Web APIs.** Remix builds on `Request`, `Response`, `URL`, `FormData`, headers, cookies, and JavaScript because shared platform APIs reduce context switching across the full stack while keeping your application portable.
 3. **Religiously Runtime.** Remix APIs do not depend on bundlers, type generation, or static analysis. Routes, middleware, controllers, and tests should run as ordinary runtime code.
 4. **Avoid Dependencies.** Remix chooses dependencies carefully, wraps them behind its own boundaries, and works toward replacing them with focused packages when the framework needs long-term control.
@@ -78,6 +78,7 @@ my-remix-app/
     ├── router.ts              # middleware, routes, and controller mapping
     ├── middleware/            # request middleware and context providers
     ├── actions/               # controllers, route actions, and route-local UI
+    │   ├── controller.tsx     # root route controller
     │   ├── document.tsx       # app document shell
     │   └── public/
     │       └── entry.ts       # starts the browser runtime
@@ -93,9 +94,7 @@ import { createRequestListener } from "remix/node-fetch-server";
 
 import { router } from "./app/router.ts";
 
-const requestListener = createRequestListener(async (request) => {
-  return await router.fetch(request);
-});
+const requestListener = createRequestListener(router.fetch);
 const server = http.createServer(requestListener);
 
 server.listen(44100, () => {
@@ -549,7 +548,7 @@ export const router = createRouter({
 
 export type AppContext = RouterContext<typeof router>;
 
-declare module "remix/router" {
+declare module "remix" {
   interface RouterTypes {
     context: AppContext;
   }

package/guides/02-routing-and-controllers.md

@@ -46,7 +46,7 @@ Path variables are one part of Remix's route pattern syntax. Patterns can also i
 // matches /docs/v2/guides/routing/route-maps.html?preview=1
 ```
 
-You do not need to memorize Remix's route pattern syntax to follow this guide. The [`route-pattern` overview](https://api.remix.run/api/remix/route-pattern/overview/) covers the full grammar and the lower-level `remix/route-pattern/href` and `remix/route-pattern/match` APIs.
+You do not need to memorize Remix's route pattern syntax to follow this guide. The [`route-pattern` overview](../src/route-pattern/README.md) covers the full grammar and the lower-level `remix/route-pattern/href` and `remix/route-pattern/match` APIs.
 
 Finally, the `edit` branch has two leaves at the same URL: `index` handles `GET` and `action` handles `POST`.
 
@@ -148,7 +148,7 @@ export const routes = route({
 // routes.albums.create -> POST   /albums
 ```
 
-These helpers produce ordinary route maps and leaves, so you can nest them with hand-written definitions. Pass a map to `createController(...)`, then register it with `router.map(...)` just as you would a hand-written map. The [`remix/router` overview](https://api.remix.run/api/remix/router/overview/) covers the full route builder API.
+These helpers produce ordinary route maps and leaves, so you can nest them with hand-written definitions. Pass a map to `createController(...)`, then register it with `router.map(...)` just as you would a hand-written map. The [`remix/router` overview](../src/fetch-router/README.md) covers the full route builder API.
 
 ## Controllers and actions
 
@@ -226,7 +226,7 @@ return context.render(<AlbumPage album={album} />);
 
 The result is still an ordinary Web `Response`. An action can render a page, return text or JSON, redirect the browser, send a file, or return an error response.
 
-Expected outcomes such as invalid input, conflicts, and missing records should also return a `Response` with the appropriate status. Reserve thrown errors for unexpected failures. If an action or middleware throws, `router.fetch(...)` rejects so the server boundary can log the error and return a `500` response. The [Errors and Error Boundaries](/errors-and-error-boundaries/) chapter covers that path in detail.
+Expected outcomes such as invalid input, conflicts, and missing records should also return a `Response` with the appropriate status. Reserve thrown errors for unexpected failures. If an action or middleware throws, `router.fetch(...)` rejects so the server boundary can log the error and return a `500` response. The [Errors and Cancellation](/errors-and-cancellation/) chapter covers that path in detail.
 
 A text response can be as simple as:
 

package/guides/03-request-handling.md

@@ -50,19 +50,7 @@ import { router } from "./app/router.ts";
 
 const port = process.env.PORT ? Number.parseInt(process.env.PORT, 10) : 44100;
 
-const server = http.createServer(
-  createRequestListener(async (request) => {
-    try {
-      return await router.fetch(request);
-    } catch (error) {
-      if (!(request.signal.aborted && error === request.signal.reason)) {
-        console.error(error);
-      }
-
-      return new Response("Internal Server Error", { status: 500 });
-    }
-  }),
-);
+const server = http.createServer(createRequestListener(router.fetch));
 
 server.listen(port, () => {
   console.log(`Server listening on http://localhost:${port}`);
@@ -83,7 +71,7 @@ Keep that boundary narrow. Code that only needs a URL, headers, cookies, a body,
 - passes the request to your Fetch handler; and
 - writes the returned response status, headers, and streamed body through Node.
 
-The same listener works with `node:http`, `node:https`, and Node's HTTP/2 compatibility API. Most apps only need to pass `router.fetch(...)` through a small error boundary, as shown above. `createRequestListener(...)` also has a default error handler, but handling router errors in `server.ts` lets the app decide what to log and return.
+The same listener works with `node:http`, `node:https`, and Node's HTTP/2 compatibility API. `createRequestListener(...)` logs errors and returns a generic `500` response by default.
 
 The listener accepts a few options when the server boundary needs more information:
 
@@ -97,7 +85,7 @@ The listener accepts a few options when the server boundary needs more informati
 For example, a Node server behind a trusted reverse proxy can let the listener recover the public protocol and host:
 
 ```ts filename=server.ts
-const requestListener = createRequestListener((request) => router.fetch(request), {
+const requestListener = createRequestListener(router.fetch, {
   trustProxy: true,
   onError(error) {
     console.error(error);
@@ -143,9 +131,7 @@ Deno uses the handler in `Deno.serve(...)`:
 ```ts filename=server.ts
 import { router } from "./app/router.ts";
 
-Deno.serve({ port: 44100 }, (request) => {
-  return router.fetch(request);
-});
+Deno.serve({ port: 44100 }, router.fetch);
 ```
 
 A Cloudflare Worker exports an object with a `fetch` method:
@@ -233,7 +219,7 @@ export const router = createRouter({
 
 export type AppContext = RouterContext<typeof router>;
 
-declare module "remix/router" {
+declare module "remix" {
   interface RouterTypes {
     context: AppContext;
   }