remix-run/remix: Inside the Six Rules Behind Remix 3

Six Rules Printed Before Any Code in the README

The README opens by calling this repository the source for Remix 3, under active development, and points to a blog post, Wake Up Remix, as the explanation for why the team restarted. In place of a features list, it gives six numbered principles that every package must follow. Model-First Development asks that source code, documentation and tooling be optimized for large language models, and that applications built on Remix get their own abstractions for using models directly, not just for developing with model assistance. Build on Web APIs commits the project to the browser's own API surface rather than a framework-specific one, on the stated reasoning that sharing abstractions across the stack cuts down on context switching for people and for machines. The remaining four principles describe how the code itself has to be organized, and they show up directly in how the repository is structured.

Why AGENTS.md and CLAUDE.md Sit Next to the README

The top-level file listing shows AGENTS.md and CLAUDE.md as ordinary files at the repository root, alongside a .agents/ directory and a .codex/ directory. That is not incidental: it is Model-First Development, the first of the six principles, applied to the repository's own layout rather than left as a sentence in the README. The tree also lists a decisions/ directory at the root, separate from the docs/ directory that holds the project's general documentation, which points to design choices being written down and kept apart from day to day usage docs rather than left only in pull request discussion.

No Bundler Step: the Religiously Runtime Rule

Principle three, Religiously Runtime, rules out designing any package around a bundler, compiler or type generator, and the README states that every test in the repository has to run without bundling. The one exception it names is an --import loader for a simple source transform, with TypeScript and JSX given as the two cases that are allowed. The practical effect is that a package in this repository is expected to run as written in whatever JavaScript runtime loads it, rather than depend on a build step to become runnable. The README frames the alternative directly: designing for pre-runtime static analysis eventually produces an API that is shaped by the tooling instead of by the problem.

A Monorepo of Standalone Fetch API Packages

The repository's packages directory holds dozens of individually publishable packages rather than one framework, and the README recommends the umbrella remix package for most users while stating that every one of those packages works on its own. A few give a sense of the range: fetch-router is described as a minimal, composable router built on the web Fetch API; data-table is a typed, relational query toolkit with separate MySQL, PostgreSQL and SQLite backend packages; cop-middleware handles tokenless cross-origin protection for Fetch API servers. Dozens more, covering cookies, HTTP headers, multipart parsing, file storage and authentication, are listed in the README. The split between data-table and its three separate backend packages is itself a demonstration of principle five, Demand Composition: the query layer is one package, and MySQL, PostgreSQL and SQLite support are each a separate package rather than three drivers bundled into one, so a project that only ever touches SQLite does not pull in MySQL or Postgres client code it will never use. The portability claim behind all of them is specific: the README names Node.js, Bun, Deno and Cloudflare Workers as runtimes the packages run on without environment-specific adaptation, built by using the Web Streams API instead of node:stream, Uint8Array instead of Node's Buffer, the Web Crypto API instead of node:crypto, and Blob and File instead of a runtime-specific equivalent.

Installing Inside a pnpm Workspace Pinned to One Version

The repository's package.json pins packageManager to [email protected] and sets engines.node to >=24.3.0, so the first requirement is matching those versions rather than using whatever package manager happens to be on the machine. Installing dependencies through pnpm triggers the postinstall script defined in package.json, which runs node ./scripts/postinstall.ts automatically. From there, the repository's own scripts cover the rest of the workflow:

pnpm install
pnpm -r build
pnpm --recursive --workspace-concurrency=4 --stream run test

The build script runs pnpm -r build, applying the build step across every workspace package rather than a single entry point. The test script caps concurrency at four workspaces at a time and streams output as it runs, which matters in a repository with dozens of packages under packages/*. A separate typecheck script, pnpm -r typecheck, runs the same way across the workspace.

Releases Are Tagged Per Package, Not Per Remix Version

The three most recent releases in the repository are [email protected], [email protected] and [email protected], each published within the same minute on 2026-10-23. The list includes [email protected] for the umbrella package, but the other tags are for individual packages, each versioned independently. For a reader used to a framework shipping one version number, this means tracking remix-run/remix means watching the specific packages a project depends on, not a single changelog. The README's own fourth principle, Avoid Dependencies, adds a second maintenance wrinkle: it states the goal is zero third-party dependencies over time, with today's dependencies, including oxlint, oxfmt, oxc-parser and typescript in the root package.json, wrapped completely and expected to be replaced by the project's own packages eventually. Anyone depending on this repository should expect that dependency graph to keep shrinking rather than staying fixed.

Where Next.js Still Expects a Bundler

Next.js is the comparison most engineers evaluating Remix will already know, and the difference in approach follows from the README's third principle: Next.js is built around its own compiler and bundler pipeline as a core part of the framework, while Remix 3's Religiously Runtime principle rules out assuming any bundler or compiler exists at all, aside from the narrow TypeScript and JSX source transforms it permits. That is a difference in what each project assumes has to run before your code does, not a claim about which one performs better.

Editorial conclusion

remix-run/remix suits a team that wants small, standards-based HTTP building blocks they can adopt one package at a time, and that is comfortable pinning to pnpm 10.34.2 and Node 24.3.0 or newer while the project is still under active development. It is the wrong fit for anyone who needs a single stable version number to track: most releases are tagged per package, such as [email protected], with the umbrella package tagged separately as [email protected]. Before adopting any package from this repository, check that specific package's own changelog rather than assuming the monorepo as a whole has reached a stable release.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes