React Router is shipping v7 and v8 on the same afternoon

Two major versions published seventeen minutes apart

The release history is the first thing to read, because it answers a question the project does not state in prose. The three newest tags are [email protected] on 2026-09-15 at 15:22 UTC, [email protected] on the same day seventeen minutes earlier, and [email protected] on 2026-08-28. Two major lines are therefore being cut from the same tree, and the patch line for the older major is not finished.

The documentation agrees. The README carries an Upgrade from v7 link, which places v8 as current, and a Previous Versions list pointing at v7 and v6 on reactrouter.com with v5 on a separate domain. What none of that includes is an end of support date for v7. For a team on the older major that is the open question: the upgrade path is documented, the reason to take it is not stated, and every week of v7 patches is a week of not deciding.

Nine packages, and the framework path needs more than one

The package list is the architecture in nine lines. There is react-router itself, then create-react-router and @react-router/dev for the framework path, then @react-router/fs-routes for filesystem routing, then four runtime adapters: @react-router/node, @react-router/serve, @react-router/express, @react-router/architect and @react-router/cloudflare.

Two consequences. The library route described as minimally as a library with your own architecture needs the single package, while the framework route adds a build-time package and commits you to one of the platform adapters, and that choice is not reversible cheaply because it decides how your server runs. And note what is absent: none of the nine is named react-router-dom, so the package name that older tutorials and most existing code refer to is not one this repository publishes.

The root package is a workspace, not something you install

The manifest at the repository root is not the thing you depend on. It is named @remix-run/react-router, it is marked private, and its build script fans out across the package directories rather than producing one artifact.

  "build": "pnpm run --filter=\"./packages/**/*\" build",
  "watch": "pnpm build && pnpm run --filter=\"./packages/**/*\" --parallel build --watch",

So a clone plus a build at the root produces all nine packages, and installing from the root gets you nothing, because a private package is never published. The root scripts are also mostly release engineering rather than application code, which tells you where the maintainers spend their tooling effort. Two clean scripts are worth noting before you run anything destructive: clean is git clean with the ignored-files flag, and clean:build is the same command with untracked files included and node_modules excluded.

An experimental publish path sits beside the stable one

There are two release mechanisms in the same manifest, and they are not the same mechanism.

    "experimental:version": "node ./scripts/experimental.ts version",
    "experimental:publish": "node ./scripts/experimental.ts publish",

Those two run a different script from the stable publishing path, which lives under scripts/changes. The practical effect is that the project can release work that is not part of the stable line, on its own cadence, and a version tag on its own does not tell you whether an experimental build exists for the same commit. For a consumer this matters in one specific place, which is pinning. Pinning to a stable tag gets you the stable line and says nothing about what was being tried alongside it, and the repository publishes no compatibility statement between the two.

The changelog is a build product, not a written record

A six-script family under scripts/changes manages what a release contains, and the root CHANGELOG.md is the output of that machinery.

    "changes:add": "node ./scripts/changes/add.ts",
    "changes:publish": "node ./scripts/changes/publish.ts",
    "changes:pr": "node ./scripts/changes/pr.ts",

Read that as a process: a change is added as a record, validated, given a version, and published, with a separate release-comments step. The consequence for you is that a bug fix in this project is partly a bookkeeping event, and the reasoning behind a version lives in those change records rather than in a hand-written changelog entry. When you are deciding whether to take a patch release, the artifact you want is the record that went into it, not the diff, and the changelog alone will not tell you which entries were generated together.

Integration cleanup rides on a post script

Unit and integration tests are separate systems, and the integration side cleans up after itself through a script lifecycle hook.

    "test:integration:run": "pnpm playwright:integration",
    "posttest:integration:run": "pnpm clean:integration",

The clean step calls a helper in the integration directory, so a completed run tidies up without being asked. That is convenient and it has one edge: the tidying happens because the post hook fired, so a run you interrupt, or a test run that hangs until you kill it, is the case where nothing tidies. There is no documented procedure for clearing a machine in that state, and the integration directory is where you would look first. Unit tests run through a different runner entirely, invoked with node flags for experimental module support and warning suppression, with a companion inspect script that breaks on the first line.

The README is 82 words and names no version requirement

The README fits on a screen: one sentence defining the project as a multi-strategy router for React that you can use maximally as a framework or minimally as a library, four links, nine package names, and the older version list. There is no install command in it. Both getting started paths, framework and library, are links to separate pages on reactrouter.com, and the two are described only by their titles.

What that leaves out matters for setup. The README names no Node version and no React peer version, yet the root carries an .nvmrc and a .browserslistrc, so both requirements exist as files you have to find yourself. A repository with a .agents directory, a playground, a decisions directory and four governance documents has clearly made decisions about how to work on it, and almost none of that reaches the page a new user reads first.

Editorial conclusion

React Router fits a team that has decided which of the two strategies it wants, a framework with a build-time package and a platform adapter, or a library wired into an architecture you already have. It does not fit someone who needs one package name and one install path, because the framework and library routes are documented separately and the runtime adapter is a four-way choice. Before you start, read the two getting started guides rather than the 82 word README, and decide whether you are on v8 or on the still-released v7 line, because the upgrade path from v7 is documented and no end of support date is.

Frequently asked questions

Official sources

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