React Compiler Linting Just Got a Rust-Native Speedup in Oxlint

ibobev1 pts0 comments

React Compiler Linting Just Got a Rust-Native Speedup in Oxlint – Master.dev Blog

/ BLOG

OxlintReactReact CompilerRustVite

React Compiler Linting Just Got a Rust-Native Speedup in Oxlint

Andrew Patton<br>on<br>August 17, 2026

The React team made a big splash recently when it announced the release of the Rust rewrite of React Compiler and said that it would be the new canonical version of the compiler going forward.

I’ve been on the React Compiler train to enable reliable performance on my AI website builder Outlyne for almost a year now, and I haven’t looked back. I no longer think about when I need to useCallback or useMemo. That, coupled with judicious use of useEffectEvent and adherence to “You Might Not Need An Effect” best practices, has largely freed me from the most common complaints leveled at React by its critics (and, maybe even more so, its proponents).

I’ve also migrated fully onto Vite v8 (with Rolldown) and the accompanying oxc ecosystem. There were many replacements recently in the Vite ecosystem:

Rollup → Rolldown

eslint → Oxlint

prettier → oxfmt

jest → vitest

This means repo-wide code formatting is effectively instantaneous, tests run way faster, and linting is mostly very fast. But React Compiler has held that toolchain back from its full potential.

Most of my build time goes to Babel + React Compiler, and my lint task has been slowed way down by needing to lean on Oxlint’s support for JS plugins to add the React Compiler linter. That linter plugin needs to run Babel, then the React Compiler core to build up the AST and understanding of the code it requires to statically analyze it and report its results. In total, running the React Compiler lint plugin made my lint job take more than three times as long as linting without.

“Not worth it,” you’re probably thinking, “it’s just some lint rules.” So glad you brought that up, because it gets at one last bit of essential context: I consider running the React Compiler linter, with all rules enabled, to be an indisputable prerequisite to using React Compiler, something I covered in a previous blog post. Briefly, removing manual memoization to leave it in the hands of React Compiler is magic and simplifies and cleans up your codebase significantly, but it can also bite you hard if you have a situation where the component tree rapidly re-renders without the proper memoization being applied and you happen to introduce some code outside of React Compiler’s supported subset of JavaScript. Doing so causes the compiler to bail out, meaning you lose the automatic memoization and could see significant UX degradation.

It happened to us: a bailout shipped a janky, visually broken (though still functional) animated placeholder in our homepage’s primary prompt input.

Oxlint gets native React Compiler support

While Vite doesn’t have support for the Rust version of React Compiler, oxlint released v1.70.0 in June, which introduced built-in support for the React Compiler linting plugin:

Adds a nursery react/react-compiler rule that runs the React Compiler (oxc_react_compiler) in lint-only mode and reports Rules of React violations: conditional hook calls, setState during render, ref access during render, mutation errors, etc.

The oxc team built and released their own vendored React Compiler crate (oxc_react_compiler) to power the new built-in ruleset. No more need for the Babel pipeline or the Oxlint jsPlugin escape hatch. I tried switching over and found that all of the existing React Compiler lint rules were fully supported, which I verified by introducing violations and seeing that they were caught. There was a small bug related to type generics, but that was fixed by oxc#24158, which first shipped in Oxlint v1.73.0.

And we found that the speed gains were as promised . Switching to the native rule took our lint task from ~29.2s → ~9.1s, a 3.2× speedup courtesy of the native Rust implementation. That number still includes perfectionist, a JS plugin with no native Oxlint equivalent that we keep running. When I tried dropping that too, the same lint task runs in ~2.6s, an 11× speedup.

The Option You Never Knew You Needed: reportAllBailouts

react/react-compiler ships as a “nursery rule”, meaning it’s considered unstable and needs to be explicitly enabled in your config, at which point you can also enable a super useful new config option unique to Oxlint called reportAllBailouts. In your .oxlintrc.json:

"plugins": ["react"],<br>"rules": {<br>"react/react-compiler": ["error", { "reportAllBailouts": true }]<br>}Code language: JSON / JSON with Comments (json)

Doing so makes the linter report an error on any instance where React Compiler has to bail out from compiling a component or hook. That lets you enforce, at the lint level, a code base where every hook and component is React Compiler compatible. You can achieve the same thing with the eslint React Compiler plugin, but it requires manually enumerating and enabling all of their lint rules in your config,...

react compiler oxlint lint native linting

Related Articles