react-native-website: the monorepo behind reactnative.dev

Guides come from docs while architecture pages come from website

This repository holds the source of reactnative.dev, a static site produced by Docusaurus. At its root sits a package.json named react-native-website-monorepo, marked private, with the workspaces website, packages/* and plugins/*, so the docs site, the shared packages and the remark plugins move together in one tree. Two doc sources feed it. Docs at the root of the repo supply the Guides, Components and APIs tabs, and those are versioned, while website/architecture and website/contributing supply the Architecture and Contribution tabs and are not.

That split decides how a contribution travels. An API reference edit goes through the versioned pipeline and gets copied into a snapshot at the next version cut; an architecture page does not. People who want the React Native documentation offline, or who want to fix a page they found broken, work in this repo. Everyone else reads the same text at https://reactnative.dev. Note also that the primary language of the repo is MDX, not plain markdown, so a page can carry React components alongside prose.

Contributors need Node 22 and Yarn Classic 1 to build

Four things are required before the site will run: Git, Node at version 22 or greater, Yarn Classic at version 1, and a fork and clone of the repo for any contribution. The Yarn requirement is the strict one, because the workspaces list in the root package.json and the root yarn.lock assume the Classic client, and the README never mentions Yarn 2, 3 or 4.

cd react-native-website
yarn
yarn start

That block moves into the project root, installs the workspace dependencies, and starts the Docusaurus development server. Open http://localhost:3000/ in a browser and your edits appear as you save. Every root script forwards into the website workspace, so the same work can be driven from that directory instead:

"start": "yarn --cwd website start",
"build": "yarn --cwd website build",
"build:fast": "yarn --cwd website build:fast",
"serve": "yarn --cwd website serve",
"lint:website": "eslint ./website ./docs",

For a single typo on one page this is a heavy path: a fork, a clone, a Classic 1 install on Node 22, a branch, and a pull request. The last push landed on 2026-09-27, so the pipeline it runs against is current.

Versioned docs freeze old APIs and edits never travel forward

Snapshots live in website/versioned_docs and website/versioned_sidebars, and Docusaurus reads the list of them from website/versions.json, which has to stay in reverse chronological order. Whenever a new React Native version ships, the current contents of the docs folder and website/sidebars.ts are copied into those two snapshot directories.

A note inside the repository states that cost plainly: the generated files should not be edited, because a change made to an older snapshot is not carried forward into newer versions of the docs. One site with a version switcher would instead keep a single set of files and move superseded pages out of the way, which removes the duplication but gives up the ability to show a reader exactly what shipped with a given version. This site picked duplication on purpose. A reader on version 0.81 sees the page as it stood at that cut, and the bill arrives later, when someone fixes a typo in an old snapshot and watches it stay put in the wrong place.

Cutting a version starts with the linter's own package.json

The order here runs against most people's expectations. Before a new React Native version is final, the website already lints and typechecks the documents written for the next version, and the React Native version that linter uses has to be moved forward first. The documented method is to update the package.json and the configuration files in script/lint-examples the same way a React Native application would be updated, then read the diff with a tool such as React Native Upgrade Helper.

Only once the version is out does the cut happen, from the website directory:

cd react-native-website
cd website
yarn version:cut <newVersion>

An example in the repository uses 0.81, and the result is opened as a pull request carrying the message Cut branch <newVersion>. Two details in that procedure do not line up. The README writes the lint example directory as script/lint-examples, while the repository root contains scripts and the root package.json reaches the same code through the workspace @react-native-website/lint-examples. The Upgrade Helper link sitting in the same paragraph still runs from 0.70.6 to 0.71.0, far behind the 0.81 example beside it. Follow that link literally and you are diffing against versions the site no longer documents.

Sidebars are hand-kept id lists bound to each frontmatter

Navigation here is not derived from the file system. The sidebar files in website, sidebars.ts, sidebarsArchitecture.ts, sidebarsCommunity.ts and sidebarsContributing.ts, each hold a list of document ids, and every id has to match the id written into the header metadata of the markdown file it points at. Adding a page or reordering one means editing the markdown and the sidebar list together, because an id in the list and an id in the frontmatter are two halves of the same reference and nothing reconciles them for you.

The community sidebar is the odd one out. The section on documentation sources names sidebars.ts, sidebarsArchitecture.ts and sidebarsContributing.ts as the files to touch when a doc is added or reordered, yet the directory listing also carries sidebarsCommunity.ts. Copying sidebars.ts into website/versioned_sidebars is all that the version cut does, which leaves the other sidebar files outside the snapshot machinery entirely. So a change to the community navigation is the one the snapshot process does not cover.

Swizzled theme components in src/theme carry the custom look

The visual layer sits in three places under website. The core directory holds the JavaScript and React components that make up the site, src/pages holds the non-documentation React components such as the homepage, and src/theme holds components swizzled out of the Docusaurus theme. website/docusaurus.config.ts drives the build itself, and the repository is unusually blunt about that file: edits to it are rarely necessary.

The trade-off in swizzling is that a swizzled component is a copy of upstream code that nobody upstream is obliged to keep stable, and this repository does not record which components have been copied or when. Neither does the README, which names the directory only as swizzled components from the Docusaurus theme. A contributor who needs to know what has been overridden opens src/theme and reads it, and a Docusaurus upgrade is the moment that inventory stops being obvious.

Lint, alex and case-police police the prose as well as the code

Lint here covers more than the code. yarn lint runs eslint across the whole tree, and lint:website targets the website and docs directories directly. Two dev dependencies exist purely to police writing: alex, pinned at ^11.0.1, checks wording, and case-police, pinned at 2.2.1, forces product names to be spelled a particular way. Then come the remark plugins, each its own workspace, reached by one script:

"lint:plugins": "yarn workspace @react-native-website/remark-codeblock-language-as-title lint && yarn workspace @react-native-website/remark-lint-no-broken-external-links lint && yarn workspace @react-native-website/remark-snackplayer lint && yarn workspace @react-native-website/remark-lint-no-broken-external-links test && yarn workspace @react-native-website/remark-snackplayer test",

That one line runs three plugins and two test suites. Code fences must carry a language, outbound links have to resolve, and SnackPlayer embeds are validated, with two of those plugins also covering themselves. Root package.json sets the module type and a prepare script that runs husky, so those git hooks install during yarn install rather than as a separate setup step. For a documentation repository this matters more than it would elsewhere: a paragraph can be rejected for phrasing or a dead link, not for anything a compiler would notice. The same file also carries check-dependencies, which runs manypkg check across the three workspace groups, and update-lock, which runs npx yarn-deduplicate.

netlify.toml and vercel.json split the build into two pipelines

Two hosting configurations sit at the repository root, netlify.toml and vercel.json, and the scripts mirror that split. build, build:fast and serve all forward to the website workspace, while build:vercel, build:vercel:fast and dev:vercel target the other host, with dev:vercel running vercel dev. Redirects are handled by a script that is not host neutral: sync-redirects:vercel runs node scripts/src/sync-vercel-redirects.ts. So yarn start locally is not what either host executes, and anyone touching routing has to know which of the two configs they are editing.

A one repository, two targets pattern shows up again in the branch layout. The source of the previous React Native Archive website is not a separate repository but the archive branch of this one, which is a cut rather than a migration, and edits made there are not part of what the current site build reads. The README does not date that split, so treat the archive branch as a copy kept for reading rather than a site still being worked on.

Editorial conclusion

react-native-website is the right repository for anyone changing reactnative.dev and the wrong one for anyone hoping to patch a React Native API reference on the spot, because the guides you read there are snapshots copied at each version cut. Node 22, Yarn Classic 1 and a fork are the price of a local build. Before opening a pull request, check yarn version:cut, website/versions.json and the ordering inside website/versioned_docs, and edit sidebars.ts rather than any file that a version cut has already generated.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. react/react-native-website on GitHub
5. README