The vite-plugin-react readme is eighty-five words and points at three others

The root document is three links and a licence

Here is the whole readme, in substance. Three headings, each pointing at a package document: the main React plugin, the SWC variant, and the RSC plugin. Then a table listing the three packages with links to their individual changelogs. Then the word MIT with a link to the licence file. The repository description carries the claims the project makes about itself: Fast Refresh, JSX and TSX support, SWC transforms, and what it calls an opinionated React plugin experience. None of that is explained on the root page. The layout makes the shape of the project clear even with no prose, because the packages table is the index and everything else is delegated. It also means the three packages can be documented at different levels of completeness without anyone noticing, which is the usual fate of a monorepo readme that is only a link farm.

Three packages, one repository, independent versions

The private root manifest is named as a monorepo and the published packages are scoped under the Vite organisation. The first is the default React integration. The second is the SWC variant, a separate package rather than an option inside the first, which is the decision most users will have to make: whether you take the default transform or the one built on a different compiler. The third is the RSC plugin, for React Server Components, which is a different feature area again. The release list shows the consequence of splitting them. The three newest releases are not three versions of one thing: the RSC package at 0.5.35 published on September 16, 2026, then the main plugin at 6.1.1 on August 28 and 6.1.0 on August 20. So the most recent tag in the repository belongs to a package most people will never install, and the main plugin's line has a completely independent numbering scheme at version six while the RSC package sits at zero point five.

The typecheck names one of the three packages

The type checking script is short enough to read in one go, and it is a list of three project directories:

"typecheck": "tsc -p scripts && tsc -p playground && tsc -p packages/plugin-react"

The scripts directory, the playground, and the main plugin. Neither the SWC package nor the RSC package appears in it, even though both are published from this repository and both are written in TypeScript. That is not necessarily an oversight: the type check may be a fast gate on the package whose types ripple into everyone else's build, with the full check happening in continuous integration. But it is the sort of asymmetry worth knowing about if you contribute to the SWC or RSC packages, because the command you would reach for locally does not cover them. Compare it with the unit test script, which is the opposite shape, filtering recursively over every package directory rather than naming one.

Two test passes, two debug switches, one shared config

The test story is where the project is most explicit, and it is worth reading as a design. The umbrella test command chains four things: unit tests across every package, a serve pass, a build pass, and then the SWC package's own tests. Both of the middle passes use the same end-to-end configuration file from the playground directory, and they differ by a single environment variable, with the build pass setting a test-build flag. Then there are two debug commands built on the same pair: a serve debug that sets a debug flag, and a build debug that sets both the build flag and a flag to preserve build artefacts, which is what you want when you need to inspect what was produced rather than have it cleaned up. The shape implies a specific testing philosophy: the playground is the fixture, and the same scenarios are exercised twice, once against the dev server and once against a real build, because those two paths fail differently.

pnpm is enforced before install, git hooks after

Two package lifecycle hooks define the contributor's environment:

"preinstall": "npx only-allow pnpm",
"postinstall": "simple-git-hooks"

The first means an install with another package manager fails immediately, before dependencies are resolved, and it does it by fetching a helper through the runner rather than by a shell script. For a repository whose whole dependency graph is expressed in a workspace file with a lockfile, refusing the other package managers is defensible: two lockfiles would be worse than an error message. The second installs git hooks as a side effect of installing, which is how the format and lint rules get attached to commits. The root also carries a lockfile and a workspace file, an npmrc, an editor configuration, an attributes file and a blame-ignore file. That last one is a small signal about how the repository treats history: commits that only reformat code are marked so they can be excluded from blame.

override-vite7 rewrites the workspace file with yq

The most interesting script in the manifest is a compatibility test expressed as a one-line shell command:

"override-vite7": "yq -i '.overrides.vite = \"^7\"' pnpm-workspace.yaml && yq -i '.overrides.\"@vitejs/plugin-react\" = \"^5\"' pnpm-workspace.yaml && yq -i '.packages += [\"!packages/plugin-react\"]' pnpm-workspace.yaml"

It edits the workspace file three times in place. It pins the Vite override to the next major. It pins the plugin override to the previous major line, so the repository can be tested against a future Vite while running an older plugin. And it excludes the local plugin-react package from the workspace, so the pinned published version is used instead of the source in this repository. That last step is the clever one: it lets one checkout test both the current pairing and the forward-looking one. A companion script overrides React itself. The cost is that both need a POSIX shell and a YAML command line tool, so this path is not portable to Windows without a shell, which is worth knowing if you are on the one platform the rest of the toolchain does not assume.

Editorial conclusion

This fits a React team that already uses Vite and only needs the default integration, where the only decision is whether you take the SWC variant, and where the RSC plugin is something you will read about rather than install today. It does not fit someone who wants one page explaining the tradeoffs, because the root readme is a table of links and the comparison lives in three separate package documents. Four things to check before you depend on it: which package you actually want, since the SWC variant exists as a separate release line rather than a flag; which version you are on, since the three packages version independently and the newest tag in the repository may not be the main plugin; whether the type checking covers the package you use, because the root typecheck script names the main plugin, the playground and the scripts directory but not the SWC or RSC packages; and which package manager your CI uses, since a preinstall hook will refuse anything except pnpm. Publishing is handled by a script in this repository rather than by hand, and the formatter is not the one most JavaScript projects use. The licence is MIT, the newest releases are plugin-rsc 0.5.35 from September 16, 2026 and plugin-react 6.1.1 from August 28, 2026, and the last commit is dated September 26, 2026.

Frequently asked questions

Official sources

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