Relevant source files

The following files were used as context for generating this wiki page: - [README.md](https://github.com/facebook/react/blob/main/README.md) - [packages/react/package.json](https://github.com/facebook/react/blob/main/packages/react/package.json) - [packages/react-dom/package.json](https://github.com/facebook/react/blob/main/packages/react-dom/package.json) - [packages/react-reconciler/README.md](https://github.com/facebook/react/blob/main/packages/react-reconciler/README.md) - [compiler/packages/react-mcp-server/src/index.ts](https://github.com/facebook/react/blob/main/compiler/packages/react-mcp-server/src/index.ts) - [scripts/release/README.md](https://github.com/facebook/react/blob/main/scripts/release/README.md) - [scripts/release/publish-commands/print-follow-up-instructions.js](https://github.com/facebook/react/blob/main/scripts/release/publish-commands/print-follow-up-instructions.js) - [fixtures/nesting/README.md](https://github.com/facebook/react/blob/main/fixtures/nesting/README.md) - [dangerfile.js](https://github.com/facebook/react/blob/main/dangerfile.js) - [packages/react-devtools/CONTRIBUTING.md](https://github.com/facebook/react/blob/main/packages/react-devtools/CONTRIBUTING.md)

# Monorepo and Package Structure The React project is organized as a monorepo, a single repository containing multiple distinct packages and projects. This structure facilitates coordinated development across the core React library, its various renderers (like React DOM), the React Compiler, development tools, and other related packages. It allows for streamlined dependency management, atomic commits across packages, and a unified build and release process. The main purpose of this repository is to continue evolving React core, making it faster and easier to use. The monorepo structure is central to managing this evolution, from experimental features to stable releases. Key top-level directories include `packages/` for publishable modules, `compiler/` for the React Compiler, `scripts/` for build and release automation, and `fixtures/` for example and test applications. Sources: [README.md:21-22](), [scripts/release/README.md]() ## Top-Level Directory Structure The repository is organized into several key directories at the root level, each serving a distinct purpose in the development, testing, and release lifecycle. This diagram shows the high-level layout of the React monorepo. ```mermaid graph TD subgraph React Monorepo A(react/) end A --> B(packages/) A --> C(compiler/) A --> D(scripts/) A --> E(fixtures/) subgraph Packages B --> B1(react) B --> B2(react-dom) B --> B3(react-reconciler) B --> B4(react-devtools) B --> Bx(...) end subgraph Compiler C --> C1(react-mcp-server) C --> Cx(...) end subgraph Scripts D --> D1(release/) D --> D2(devtools/) D --> Dx(...) end subgraph Fixtures E --> E1(flight/) E --> E2(nesting/) E --> Ex(...) end ``` Sources: [packages/]() | Directory | Description | | :--- | :--- | | `packages/` | Contains all the public and internal packages that are published to npm, such as `react`, `react-dom`, and `react-devtools`. | | `compiler/` | Houses the source code for the React Compiler, which optimizes React components and hooks. | | `scripts/` | Includes scripts for various development tasks, including building packages, running tests, and managing the release process. | | `fixtures/` | Contains example projects, test cases, and demonstration apps used for development and testing, such as `flight` and `nesting`. | Sources: [packages/](), [compiler/](), [scripts/](), [fixtures/flight/scripts/build.js](), [fixtures/nesting/README.md]() ## The `packages` Directory The `packages/` directory is the heart of the monorepo, containing all the individual, versioned packages that form the React ecosystem. These packages are managed and published to npm. ### Key Packages | Package | Description | Source File | | :--- | :--- | :--- | | `react` | The core React library. It contains the fundamental APIs for defining components and hooks. | `packages/react/package.json` | | `react-dom` | The renderer for web applications, providing DOM-specific methods. It has multiple entry points for different environments (client, server, browser, node, edge). | `packages/react-dom/package.json` | | `react-reconciler` | An experimental package for building custom React renderers, enabling React to target platforms beyond the web and native mobile. | `packages/react-reconciler/README.md` | | `react-devtools` | The developer tools for inspecting React component hierarchies. It is composed of several sub-packages. | `packages/react-devtools/CONTRIBUTING.md` | | `react-markup` | A package for generating embedded markup, such as emails, with support for React Server Components. | `packages/react-markup/package.json` | | `scheduler` | A package for cooperative scheduling in a browser environment, used internally by React. | `packages/react-dom/package.json:15` | ### Package Exports and Environments Modern React packages use the `exports` field in their `package.json` to define multiple entry points for different environments and conditions, such as server-side rendering and React Server Components. For example, the `react` package provides different files for `react-server` environments and for different runtimes like `jsx-runtime`. ```json { "name": "react", "exports": { ".": { "react-server": "./react.react-server.js", "default": "./index.js" }, "./package.json": "./package.json", "./jsx-runtime": { "react-server": "./jsx-runtime.react-server.js", "default": "./jsx-runtime.js" }, "./jsx-dev-runtime": { "react-server": "./jsx-dev-runtime.react-server.js", "default": "./jsx-dev-runtime.js" }, "./compiler-runtime": { "react-server": "./compiler-runtime.js", "default": "./compiler-runtime.js" } } } ``` Sources: [packages/react/package.json:20-43]() Similarly, `react-dom` provides specific builds for various server environments like Node.js, Deno, Bun, and edge workers. ```json { "name": "react-dom", "exports": { "./server": { "react-server": "./server.react-server.js", "workerd": "./server.edge.js", "bun": "./server.bun.js", "deno": "./server.browser.js", "worker": "./server.browser.js", "node": "./server.node.js", "edge-light": "./server.edge.js", "browser": "./server.browser.js", "default": "./server.node.js" } } } ``` Sources: [packages/react-dom/package.json:34-45]() ## The `compiler` Directory The `compiler/` directory contains the source code for the React Compiler. Its placement at the top level signifies its importance as a first-class project within the React ecosystem, developed in tandem with the core library. One of the packages within this directory is `react-mcp-server`, which exposes a server with tools to `compile` React code and `review-react-runtime` for performance analysis. This demonstrates the tight integration of the compiler with the development workflow. Sources: [compiler/packages/react-mcp-server/src/index.ts:71-93, 233-259]() ## Build and Release Process The monorepo relies on a sophisticated set of scripts located in the `scripts/` directory to manage the build and release process. This process is designed to handle continuous prereleases as well as stable production releases. ### Release Channels There are three primary release channels: * **`experimental`**: For builds with new, experimental features enabled. * **`next`**: Prereleases published frequently (e.g., daily) from the main branch. These are candidates for stable releases. * **`latest`**: Stable, production-ready releases promoted from the `next` channel. Sources: [scripts/release/README.md:11-14, 60-63, 72-75]() ### Release Workflow The following diagram illustrates the typical flow for creating and publishing a release. ```mermaid flowchart TD A[Commit to main branch] --> B{GitHub Actions CI}; B --> C[Build & Test Artifacts]; C --> D{Automated Prerelease}; D --> E[Publish to 'next' & 'experimental' channels]; subgraph Manual Promotion F[Promote 'next' candidate] --> G[prepare-release-from-npm.js]; G --> H[Select stable version numbers]; H --> I[publish.js --tags latest]; I --> J[Publish to 'latest' channel on npm]; end E --> F; J --> K[Tag git commit]; K --> L[Update CHANGELOG]; L --> M[Create GitHub Release]; ``` This diagram shows the automated and manual steps involved in the React release process, from a commit to publishing on npm. Sources: [scripts/release/README.md:23-35, 72-84]() ### Key Release Scripts | Script | Description | | :--- | :--- | | `prepare-release-from-ci.js` | Downloads pre-built and tested artifacts from CI to prepare a `next` or `experimental` release. | | `prepare-release-from-npm.js` | Prepares a release from the `next` channel on npm to be promoted to `stable`. It prompts for new version numbers and updates package files. | | `publish.js` | Publishes the prepared packages to npm with specified tags (e.g., `latest`, `next`). | | `print-follow-up-instructions.js` | After a successful publish, this script provides manual instructions for tagging the release in git, updating the changelog, and creating the release on GitHub. | Sources: [scripts/release/README.md:143-178](), [scripts/release/publish-commands/print-follow-up-instructions.js:33-89]() ### Continuous Integration Checks The repository uses tools like DangerJS to perform automated checks on pull requests. The `dangerfile.js` script, for instance, compares the size of build artifacts against the base branch to catch unexpected increases in bundle size, which is critical for a library focused on performance. Sources: [dangerfile.js:124-183]() ## Advanced Package Management: Nested Dependencies The monorepo structure is flexible enough to support complex scenarios, such as running two different versions of React side-by-side within the same application. The `fixtures/nesting` example demonstrates this advanced configuration. This approach is an escape hatch for large, legacy applications that cannot be upgraded all at once. It works by creating a nested dependency structure. The diagram below illustrates how dependencies are structured in the `fixtures/nesting` example. ```mermaid graph TD subgraph Project Root Root_PkgJSON("package.json
(Build deps, e.g., react-scripts)") end subgraph src/modern Modern_PkgJSON("package.json
(react@17, react-dom@17)") end subgraph src/legacy Legacy_PkgJSON("package.json
(react@16.8, react-dom@16.8)") end Root_PkgJSON --> Modern_PkgJSON Root_PkgJSON --> Legacy_PkgJSON App_EntryPoint("src/index.js") --> Modern_Code("src/modern/App.js") Modern_Code -- "lazyLegacyRoot()" --> Legacy_Code("src/legacy/Greeting.js") Shared_Code("src/shared/Clock.js") Shared_Code -- "Copied to" --> Modern_Shared("src/modern/shared/Clock.js") Shared_Code -- "Copied to" --> Legacy_Shared("src/legacy/shared/Clock.js") Modern_Code --> Modern_Shared Legacy_Code --> Legacy_Shared ``` Sources: [fixtures/nesting/README.md:76-96]() Key aspects of this setup include: - **Three `package.json` files**: One at the root for build tools, and one in each version-specific directory (`src/modern`, `src/legacy`) to declare different versions of `react` and `react-dom`. - **Shared Code**: A `src/shared` directory contains components that are duplicated into both the `modern` and `legacy` trees, allowing them to be used with either React version. - **Lazy Loading**: A custom `lazyLegacyRoot` helper, similar to `React.lazy`, is used to load the bundle containing the older React version only when it's needed, minimizing the performance impact. - **Context Bridging**: To allow context (e.g., from React Router or Redux) to flow between the two React trees, a "bridge" is created to read context from the outer tree and provide it to the inner tree. This demonstrates the power and flexibility of the package management strategy within the React monorepo. Sources: [fixtures/nesting/README.md:106-120, 142-154]() ## Conclusion The React repository's monorepo architecture is a sophisticated system designed to manage the complexity of developing a large-scale UI library and its extensive ecosystem. By co-locating packages, the compiler, and tooling, it enables atomic changes, streamlined dependency management, and a robust, multi-channel release process. The structure supports everything from daily experimental builds to stable production releases and even advanced use cases like nested React versions, ensuring that React can continue to evolve efficiently while maintaining stability for its vast user base. Sources: [README.md:21-22](), [scripts/release/README.md:23-35]()```json {"thought":"I need to create a technical wiki page in Markdown format about the \"Monorepo and Package Structure\" of the React repository.\n\nHere's my plan:\n1. **Start with the `

` block**: List all the relevant source files I've been given. I need to make sure there are at least 5. The provided list has more than enough. I'll select the most relevant ones.\n - `README.md`: High-level overview.\n - `packages/react/package.json`: Core react package definition.\n - `packages/react-dom/package.json`: ReactDOM package definition.\n - `packages/react-reconciler/README.md`: Explains custom renderers, showing the modularity.\n - `compiler/packages/react-mcp-server/src/index.ts`: Shows the compiler as a separate top-level directory.\n - `scripts/release/README.md`: Details the release process which is crucial for a monorepo.\n - `dangerfile.js`: Shows CI/CD integration, specifically size checking for different build artifacts, which is a common monorepo concern.\n - `fixtures/nesting/README.md`: An excellent example of how the monorepo structure can be used to manage multiple versions of React side-by-side.\n\n2. **H1 Heading**: `# Monorepo and Package Structure`.\n\n3. **Introduction**:\n - Explain that React uses a monorepo structure to manage its core library, related packages, compiler, and development tools.\n - Mention the key top-level directories: `packages`, `compiler`, `scripts`, `fixtures`.\n - Briefly describe the purpose of each. The `packages` directory contains the public-facing npm packages like `react`, `react-dom`, etc. The `compiler` directory houses the React Compiler. `scripts` contains build, release, and other development scripts. `fixtures` contains test projects and examples.\n\n4. **Detailed Sections**:\n * **## Top-Level Directory Structure**:\n - Create a table or list describing the main directories (`packages`, `compiler`, `scripts`, `fixtures`).\n - Use a Mermaid diagram to show the high-level structure.\n\n ```mermaid\n graph TD\n subgraph React Monorepo\n A(root)\n end\n A --> B(packages)\n A --> C(compiler)\n A --> D(scripts)\n A --> E(fixtures)\n\n B --> B1(react)\n B --> B2(react-dom)\n B --> B3(react-reconciler)\n B --> B4(react-devtools)\n B --> Bx(...)\n\n C --> C1(react-mcp-server)\n C --> Cx(...)\n\n D --> D1(release)\n D --> D2(devtools)\n\n E --> E1(flight)\n E --> E2(nesting)\n ```\n\n * **## The `packages` Directory**:\n - This is the core of the monorepo, containing all publishable packages.\n - Discuss key packages and their roles:\n - `react`: The core library. I'll analyze `packages/react/package.json` to show its exports (`.`, `jsx-runtime`, `compiler-runtime`, etc.) and its server-side variants (`react-server`).\n - `react-dom`: The DOM renderer. I'll analyze `packages/react-dom/package.json` to show its various entry points for different environments (browser, node, edge, bun) and its client/server/static variants.\n - `react-reconciler`: The experimental package for creating custom renderers. I'll use `packages/react-reconciler/README.md` to explain its purpose and how it enables the \"Learn Once, Write Anywhere\" philosophy.\n - `react-devtools`: The developer tools, showing how related tooling lives alongside the core packages. I'll reference `packages/react-devtools/CONTRIBUTING.md` and `packages/react-devtools-shared/...`.\n - Mention the concept of internal packages (like `shared`) vs. public packages.\n - I can create a table listing some key packages and their descriptions.\n\n * **## The `compiler` Directory**:\n - Explain that this directory contains the source code for the React Compiler.\n - Mention that it's developed alongside the core library within the same monorepo.\n - I can reference `compiler/packages/react-mcp-server/src/index.ts` to show an example of a package within the compiler directory, which provides a server with tools like `compile` and `review-react-runtime`.\n\n * **## Build and Release Process**:\n - This is a critical part of managing a monorepo.\n - Use `scripts/release/README.md` as the primary source.\n - Explain the different types of releases: `next`, `experimental`, and `stable`.\n - Create a Mermaid flowchart to illustrate the release lifecycle (e.g., CI builds -> `next` channel -> promotion to `stable`).\n - Mention key scripts like `prepare-release-from-ci.js`, `prepare-release-from-npm.js`, and `publish.js`.\n - I'll use `scripts/release/publish-commands/print-follow-up-instructions.js` to show the manual steps involved after publishing, like tagging the release and updating the changelog.\n - I can also mention the `dangerfile.js` which runs size checks on build artifacts, a process that is highly relevant to monorepo CI.\n\n * **## Advanced Package Management: Nested Dependencies**:\n - This is a very interesting and advanced use case of the monorepo structure.\n - Use `fixtures/nesting/README.md` as the main source.\n - Explain the problem it solves: allowing different parts of an application to use different versions of React.\n - Describe the structure: a root `package.json` for build dependencies, and separate `package.json` files in `src/legacy` and `src/modern` for different React versions.\n - Create a diagram to illustrate this nested dependency structure.\n - Explain how shared code is handled (`src/shared` folder) and how lazy loading (`React.lazy`-like helper) is used to avoid loading both React versions at once.\n - This demonstrates the flexibility of the monorepo and package management strategy.\n\n5. **Mermaid Diagrams**: I'll create at least three diagrams:\n - A high-level directory structure graph.\n - A flowchart for the release process.\n - A diagram showing the nested dependency structure from the `fixtures/nesting` example.\n\n6. **Tables**: I'll use tables to summarize:\n - Top-level directories.\n - Key packages in the `packages` directory.\n - Release scripts.\n\n7. **Code Snippets**: I can include snippets from `package.json` files to show the `exports` map, which is a key part of the package structure.\n\n8. **Source Citations**: I will meticulously cite every piece of information, diagram, and table entry back to the source files and line numbers. I will ensure I use at least 5 different files.\n\n9. **Conclusion**: I'll summarize how the monorepo structure facilitates the development of React, its ecosystem of packages, the compiler, and tooling in a cohesive and manageable way, enabling both rapid iteration on experimental features and stable, coordinated releases.\n\nI'll start writing the content now, following this plan. I will be careful to only use information from the provided files.","output":"

Relevant source files

\n\nThe following files were used as context for generating this wiki page:\n\n- [README.md](https://github.com/facebook/react/blob/main/README.md)\n- [packages/react/package.json](https://github.com/facebook/react/blob/main/packages/react/package.json)\n- [packages/react-dom/package.json](https://github.com/facebook/react/blob/main/packages/react-dom/package.json)\n- [packages/react-reconciler/README.md](https://github.com/facebook/react/blob/main/packages/react-reconciler/README.md)\n- [compiler/packages/react-mcp-server/src/index.ts](https://github.com/facebook/react/blob/main/compiler/packages/react-mcp-server/src/index.ts)\n- [scripts/release/README.md](https://github.com/facebook/react/blob/main/scripts/release/README.md)\n- [scripts/release/publish-commands/print-follow-up-instructions.js](https://github.com/facebook/react/blob/main/scripts/release/publish-commands/print-follow-up-instructions.js)\n- [fixtures/nesting/README.md](https://github.com/facebook/react/blob/main/fixtures/nesting/README.md)\n- [dangerfile.js](https://github.com/facebook/react/blob/main/dangerfile.js)\n- [packages/react-devtools/CONTRIBUTING.md](https://github.com/facebook/react/blob/main/packages/react-devtools/CONTRIBUTING.md)\n\n

\n\n# Monorepo and Package Structure\n\nThe React project is organized as a monorepo, a single repository containing multiple distinct packages and projects. This structure facilitates coordinated development across the core React library, its various renderers (like React DOM), the React Compiler, development tools, and other related packages. It allows for streamlined dependency management, atomic commits across packages, and a unified build and release process.\n\nThe main purpose of this repository is to continue evolving React core, making it faster and easier to use. The monorepo structure is central to managing this evolution, from experimental features to stable releases. Key top-level directories include `packages/` for publishable modules, `compiler/` for the React Compiler, `scripts/` for build and release automation, and `fixtures/` for example and test applications.\n\nSources: [README.md:21-22](), [scripts/release/README.md]()\n\n## Top-Level Directory Structure\n\nThe repository is organized into several key directories at the root level, each serving a distinct purpose in the development, testing, and release lifecycle.\n\nThis diagram shows the high-level layout of the React monorepo.\n\n```mermaid\ngraph TD\n subgraph React Monorepo\n A(react/)\n end\n A --> B(packages/)\n A --> C(compiler/)\n A --> D(scripts/)\n A --> E(fixtures/)\n\n subgraph Packages\n B --> B1(react)\n B --> B2(react-dom)\n B --> B3(react-reconciler)\n B --> B4(react-devtools)\n B --> Bx(...)\n end\n\n subgraph Compiler\n C --> C1(react-mcp-server)\n C --> Cx(...)\n end\n\n subgraph Scripts\n D --> D1(release/)\n D --> D2(devtools/)\n D --> Dx(...)\n end\n\n subgraph Fixtures\n E --> E1(flight/)\n E --> E2(nesting/)\n E --> Ex(...)\n end\n```\nSources: [packages/]()\n\n| Directory | Description |\n| :--- | :--- |\n| `packages/` | Contains all the public and internal packages that are published to npm, such as `react`, `react-dom`, and `react-devtools`. |\n| `compiler/` | Houses the source code for the React Compiler, which optimizes React components and hooks. |\n| `scripts/` | Includes scripts for various development tasks, including building packages, running tests, and managing the release process. |\n| `fixtures/` | Contains example projects, test cases, and demonstration apps used for development and testing, such as `flight` and `nesting`. |\n\nSources: [packages/](), [compiler/](), [scripts/](), [fixtures/flight/scripts/build.js](), [fixtures/nesting/README.md]()\n\n## The `packages` Directory\n\nThe `packages/` directory is the heart of the monorepo, containing all the individual, versioned packages that form the React ecosystem. These packages are managed and published to npm.\n\n### Key Packages\n\n| Package | Description | Source File |\n| :--- | :--- | :--- |\n| `react` | The core React library. It contains the fundamental APIs for defining components and hooks. | `packages/react/package.json` |\n| `react-dom` | The renderer for web applications, providing DOM-specific methods. It has multiple entry points for different environments (client, server, browser, node, edge). | `packages/react-dom/package.json` |\n| `react-reconciler` | An experimental package for building custom React renderers, enabling React to target platforms beyond the web and native mobile. | `packages/react-reconciler/README.md` |\n| `react-devtools` | The developer tools for inspecting React component hierarchies. It is composed of several sub-packages. | `packages/react-devtools/CONTRIBUTING.md` |\n| `react-markup` | A package for generating embedded markup, such as emails, with support for React Server Components. | `packages/react-markup/package.json` |\n| `scheduler` | A package for cooperative scheduling in a browser environment, used internally by React. | `packages/react-dom/package.json:15` |\n\n### Package Exports and Environments\n\nModern React packages use the `exports` field in their `package.json` to define multiple entry points for different environments and conditions, such as server-side rendering and React Server Components.\n\nFor example, the `react` package provides different files for `react-server` environments and for different runtimes like `jsx-runtime`.\n\n```json\n{\n \"name\": \"react\",\n \"exports\": {\n \".\": {\n \"react-server\": \"./react.react-server.js\",\n \"default\": \"./index.js\"\n },\n \"./package.json\": \"./package.json\",\n \"./jsx-runtime\": {\n \"react-server\": \"./jsx-runtime.react-server.js\",\n \"default\": \"./jsx-runtime.js\"\n },\n \"./jsx-dev-runtime\": {\n \"react-server\": \"./jsx-dev-runtime.react-server.js\",\n \"default\": \"./jsx-dev-runtime.js\"\n },\n \"./compiler-runtime\": {\n \"react-server\": \"./compiler-runtime.js\",\n \"default\": \"./compiler-runtime.js\"\n }\n }\n}\n```\nSources: [packages/react/package.json:20-43]()\n\nSimilarly, `react-dom` provides specific builds for various server environments like Node.js, Deno, Bun, and edge workers.\n\n```json\n{\n \"name\": \"react-dom\",\n \"exports\": {\n \"./server\": {\n \"react-server\": \"./server.react-server.js\",\n \"workerd\": \"./server.edge.js\",\n \"bun\": \"./server.bun.js\",\n \"deno\": \"./server.browser.js\",\n \"worker\": \"./server.browser.js\",\n \"node\": \"./server.node.js\",\n \"edge-light\": \"./server.edge.js\",\n \"browser\": \"./server.browser.js\",\n \"default\": \"./server.node.js\"\n }\n }\n}\n```\nSources: [packages/react-dom/package.json:34-45]()\n\n## The `compiler` Directory\n\nThe `compiler/` directory contains the source code for the React Compiler. Its placement at the top level signifies its importance as a first-class project within the React ecosystem, developed in tandem with the core library.\n\nOne of the packages within this directory is `react-mcp-server`, which exposes a server with tools to `compile` React code and `review-react-runtime` for performance analysis. This demonstrates the tight integration of the compiler with the development workflow.\n\nSources: [compiler/packages/react-mcp-server/src/index.ts:71-93, 233-259]()\n\n## Build and Release Process\n\nThe monorepo relies on a sophisticated set of scripts located in the `scripts/` directory to manage the build and release process. This process is designed to handle continuous prereleases as well as stable production releases.\n\n### Release Channels\n\nThere are three primary release channels:\n* **`experimental`**: For builds with new, experimental features enabled.\n* **`next`**: Prereleases published frequently (e.g., daily) from the main branch. These are candidates for stable releases.\n* **`latest`**: Stable, production-ready releases promoted from the `next` channel.\n\nSources: [scripts/release/README.md:11-14, 60-63, 72-75]()\n\n### Release Workflow\n\nThe following diagram illustrates the typical flow for creating and publishing a release.\n\n```mermaid\nflowchart TD\n A[Commit to main branch] --> B{GitHub Actions CI};\n B --> C[Build & Test Artifacts];\n C --> D{Automated Prerelease};\n D --> E[Publish to 'next' & 'experimental' channels];\n\n subgraph Manual Promotion\n F[Promote 'next' candidate] --> G[prepare-release-from-npm.js];\n G --> H[Select stable version numbers];\n H --> I[publish.js --tags latest];\n I --> J[Publish to 'latest' channel on npm];\n end\n\n E --> F;\n J --> K[Tag git commit];\n K --> L[Update CHANGELOG];\n L --> M[Create GitHub Release];\n\n```\nThis diagram shows the automated and manual steps involved in the React release process, from a commit to publishing on npm.\nSources: [scripts/release/README.md:23-35, 72-84]()\n\n### Key Release Scripts\n\n| Script | Description |\n| :--- | :--- |\n| `prepare-release-from-ci.js` | Downloads pre-built and tested artifacts from CI to prepare a `next` or `experimental` release. |\n| `prepare-release-from-npm.js` | Prepares a release from the `next` channel on npm to be promoted to `stable`. It prompts for new version numbers and updates package files. |\n| `publish.js` | Publishes the prepared packages to npm with specified tags (e.g., `latest`, `next`). |\n| `print-follow-up-instructions.js` | After a successful publish, this script provides manual instructions for tagging the release in git, updating the changelog, and creating the release on GitHub. |\n\nSources: [scripts/release/README.md:143-178](), [scripts/release/publish-commands/print-follow-up-instructions.js:33-89]()\n\n### Continuous Integration Checks\n\nThe repository uses tools like DangerJS to perform automated checks on pull requests. The `dangerfile.js` script, for instance, compares the size of build artifacts against the base branch to catch unexpected increases in bundle size, which is critical for a library focused on performance.\n\nSources: [dangerfile.js:124-183]()\n\n## Advanced Package Management: Nested Dependencies\n\nThe monorepo structure is flexible enough to support complex scenarios, such as running two different versions of React side-by-side within the same application. The `fixtures/nesting` example demonstrates this advanced configuration.\n\nThis approach is an escape hatch for large, legacy applications that cannot be upgraded all at once. It works by creating a nested dependency structure.\n\nThe diagram below illustrates how dependencies are structured in the `fixtures/nesting` example.\n```mermaid\ngraph TD\n subgraph Project Root\n Root_PkgJSON(\"package.json
(Build deps, e.g., react-scripts)\")\n end\n\n subgraph src/modern\n Modern_PkgJSON(\"package.json
(react@17, react-dom@17)\")\n end\n\n subgraph src/legacy\n Legacy_PkgJSON(\"package.json
(react@16.8, react-dom@16.8)\")\n end\n\n Root_PkgJSON --> Modern_PkgJSON\n Root_PkgJSON --> Legacy_PkgJSON\n\n App_EntryPoint(\"src/index.js\") --> Modern_Code(\"src/modern/App.js\")\n Modern_Code -- \"lazyLegacyRoot()\" --> Legacy_Code(\"src/legacy/Greeting.js\")\n\n Shared_Code(\"src/shared/Clock.js\")\n Shared_Code -- \"Copied to\" --> Modern_Shared(\"src/modern/shared/Clock.js\")\n Shared_Code -- \"Copied to\" --> Legacy_Shared(\"src/legacy/shared/Clock.js\")\n\n Modern_Code --> Modern_Shared\n Legacy_Code --> Legacy_Shared\n```\nSources: [fixtures/nesting/README.md:76-96]()\n\nKey aspects of this setup include:\n- **Three `package.json` files**: One at the root for build tools, and one in each version-specific directory (`src/modern`, `src/legacy`) to declare different versions of `react` and `react-dom`.\n- **Shared Code**: A `src/shared` directory contains components that are duplicated into both the `modern` and `legacy` trees, allowing them to be used with either React version.\n- **Lazy Loading**: A custom `lazyLegacyRoot` helper, similar to `React.lazy`, is used to load the bundle containing the older React version only when it's needed, minimizing the performance impact.\n- **Context Bridging**: To allow context (e.g., from React Router or Redux) to flow between the two React trees, a \"bridge\" is created to read context from the outer tree and provide it to the inner tree.\n\nThis demonstrates the power and flexibility of the package management strategy within the React monorepo.\n\nSources: [fixtures/nesting/README.md:106-120, 142-154]()\n\n## Conclusion\n\nThe React repository's monorepo architecture is a sophisticated system designed to manage the complexity of developing a large-scale UI library and its extensive ecosystem. By co-locating packages, the compiler, and tooling, it enables atomic changes, streamlined dependency management, and a robust, multi-channel release process. The structure supports everything from daily experimental builds to stable production releases and even advanced use cases like nested React versions, ensuring that React can continue to evolve efficiently while maintaining stability for its vast user base.\n\nSources: [README.md:21-22](), [scripts/release/README.md:23-35]()\n" } ```