This document provides an overview of React Router's project governance, release processes, CI/CD infrastructure, and contribution guidelines. It explains the different release channels, versioning strategies, and automated workflows that support the project.
For detailed information about specific aspects:
React Router maintains a comprehensive list of contributors in contributors.yml1-476 This file serves as the single source of truth for all individuals who have contributed to the project and is automatically sorted alphabetically by the format workflow.
The project recognizes 476+ contributors spanning various aspects including code contributions, documentation, issue reporting, and community support. This contributor list is used for attribution in release notes and project documentation.
Sources: contributors.yml1-476
React Router supports four distinct release channels, each serving different use cases and stability guarantees. All releases are managed through a unified GitHub Actions workflow that uses npm Trusted Publishing for security.
Sources: .github/workflows/release.yml1-260
The stable release process is managed by Changesets and triggered by pushes to the release-next or release-v6 branches. The workflow performs two distinct operations:
The workflow uses specific node version 24 to ensure npm 11 is available for Trusted Publishing. Changesets is pinned to version 1.4.10 to avoid regressions in newer versions.
Sources: .github/workflows/release.yml41-116
Nightly releases occur automatically via cron schedule at 12AM PST daily. The process checks if changes have occurred since the last nightly release and only publishes if new commits exist:
| Step | Action | Script/Command |
|---|---|---|
| Version Check | Compare latest nightly tag with current HEAD | git tag -l v0.0.0-nightly-* |
| Version Format | Generate version: 0.0.0-nightly-{short-sha}-{yyyyMMdd} | Shell script |
| Branch Creation | Create branch: nightly/{version} | git checkout -b |
| Update Versions | Run version script across all packages | pnpm run version |
| Tag Push | Push tags to origin | git push origin --tags |
| Build | Build all packages | pnpm build |
| Publish | Publish with nightly tag | pnpm run publish |
Sources: .github/workflows/release.yml146-216
Experimental releases can be triggered manually via workflow_dispatch on any branch, useful for testing features or bug fixes before merging:
Sources: .github/workflows/release.yml217-260
The CI/CD infrastructure uses reusable GitHub Actions workflows to enable consistent testing across different environments while minimizing duplication.
Sources: .github/workflows/test.yml1-71 .github/workflows/integration-pr-ubuntu.yml1-36 .github/workflows/integration-pr-windows-macos.yml1-55 .github/workflows/integration-full.yml1-55 .github/workflows/shared-integration.yml1-70 .github/workflows/shared-build.yml1-39
| Workflow | Trigger | Operating Systems | Node Versions | Browsers |
|---|---|---|---|---|
test.yml | Push to main/dev or PR | ubuntu-latest | 20.18, 22 | N/A (unit tests only) |
integration-pr-ubuntu.yml | All PRs | ubuntu-latest | 22 | chromium |
integration-pr-windows-macos.yml | PRs touching @react-router/dev | ubuntu, windows, macos | 20.18 (ubuntu), 22 (all) | chromium, firefox, msedge, webkit |
integration-full.yml | Push to main/dev | ubuntu, windows, macos | 20.18, 22 | chromium, firefox, msedge, webkit |
The strategy minimizes CI costs while providing comprehensive coverage for critical changes. PRs touching core development tooling receive additional cross-platform testing.
Sources: .github/workflows/test.yml3-17 .github/workflows/integration-pr-ubuntu.yml5-16 .github/workflows/integration-pr-windows-macos.yml6-12 .github/workflows/integration-full.yml6-20
The shared integration workflow accepts matrix parameters for operating system, node version, and browser selection:
The browser and node_version inputs are stringified JSON arrays that are parsed using fromJSON() to create the test matrix. Timeouts are configurable per workflow (default 45 minutes, 90 minutes for Windows).
Sources: .github/workflows/shared-integration.yml1-70
Several automated workflows maintain code quality and consistency without manual intervention.
Runs on every push to main or dev branches:
Uses a personal access token (FORMAT_PAT) to bypass branch protection and push commits directly.
Sources: .github/workflows/format.yml1-55
Automatically deduplicates pnpm-lock.yaml on pushes to dev branch:
Sources: .github/workflows/deduplicate-lock-file.yml1-50
React Router uses a hybrid approach combining TypeDoc for API reference and custom JSDoc parsing for user-facing documentation.
Sources: .github/workflows/docs.yml1-68
The scripts/docs.ts script parses JSDoc comments from source files and generates markdown documentation with automatic cross-linking:
| Component | Purpose | Output |
|---|---|---|
dox | Parse JSDoc comments from TypeScript files | Structured comment objects |
| TypeDoc | Generate comprehensive API reference | public/dev/api.json |
scripts/docs.ts | Convert JSDoc to markdown with cross-links | docs/api/**/*.md |
| Prettier | Format generated markdown | Consistent formatting |
The script supports filtering by file path or specific API names and automatically resolves {@link} tags to either repository documentation or TypeDoc reference pages.
Sources: scripts/docs.ts1-769
The script builds two lookup tables:
docs/api/Resolution priority: unstable API docs → stable API docs → TypeDoc reference
Sources: scripts/docs.ts163-227 scripts/docs.ts731-768
Specific files are subject to strict JSDoc linting rules enforced by ESLint with the jsdoc plugin:
Custom JSDoc tags include:
@category: Groups APIs (Components, Hooks, Utils, RSC, etc.)@mode: Restricts API to specific usage modes (framework, data, declarative)@additionalExamples: Provides extended examples@name: Overrides the inferred API nameSources: .eslintrc28-93 scripts/docs.ts73-82
The project uses ESLint with the react-app preset and custom rules:
| Rule | Configuration | Purpose |
|---|---|---|
@typescript-eslint/consistent-type-imports | error | Enforce type-only imports |
import/first | off | Allow imports after comments |
jest/recommended | plugin | Test file best practices |
react-hooks/rules-of-hooks | off (integration/) | Allow hooks in fixtures |
jsdoc/* | various errors | Enforce documentation standards |
Sources: .eslintrc1-96
Tests run on multiple Node.js versions with comprehensive checks:
Integration tests use Playwright with project-specific configuration, supporting SPA, SSR, RSC, and prerender modes. See Testing and Quality Assurance for details.
Sources: .github/workflows/test.yml57-70
The contribution process involves several automated steps to ensure code quality and proper documentation:
Sources: .github/workflows/test.yml1-71 .github/workflows/format.yml1-55 .github/workflows/deduplicate-lock-file.yml1-50 .github/workflows/docs.yml1-68
Contributors use Changesets to document version impacts:
When a release branch receives commits, the Changesets Action aggregates all changesets, updates package versions, and generates consolidated changelogs.
Sources: .github/workflows/release.yml75-85
PRs touching @react-router/dev or pnpm-lock.yaml trigger extended testing across all operating systems and browsers to catch platform-specific issues before merge.
Sources: .github/workflows/integration-pr-windows-macos.yml6-12
The project specifies Node.js version requirements in multiple locations:
| File | Version | Purpose |
|---|---|---|
.nvmrc | 22 | Development environment |
test.yml matrix | 20.18, 22 | CI test coverage |
release.yml | 24 | npm 11 for Trusted Publishing |
| Integration workflows | 20.18, 22 | Cross-version compatibility |
Node 24 is required specifically for release workflows to ensure npm 11 is available for Trusted Publishing support.
Sources: .nvmrc1 .github/workflows/test.yml28-30 .github/workflows/release.yml64
Refresh this wiki