How would you roll the React Compiler out across a large existing React codebase, and what would you require before enabling it everywhere?

## Frame it correctly Enabling the React Compiler is not adding an optimisation; it is adopting a *precondition*. The compiler is safe exactly to the degree that the codebase obeys the Rules of React, so the real question a principal is being asked is whether the organisation can hold purity as an enforced invariant. Answering with a rollout order that never mentions the lint gate misses the point of the question. ## Step 1 — survey before committing Run the health check the project ships: `npx react-compiler-healthcheck`. It reports roughly how many components in the repo would successfully compile, which files violate the rules the compiler depends on, and which libraries in use are known to be incompatible with the memoization it introduces. That converts "should we adopt this" into three numbers you can plan against: expected coverage, violation count, and dependency blockers. Also confirm the version baseline. On React 19 the plugin needs no extra runtime; supporting React 17 or 18 requires the plugin's `target` option together with the `react-compiler-runtime` package, which is an extra dependency decision to make deliberately. ## Step 2 — make the lint rule blocking `eslint-plugin-react-compiler` runs the compiler's own analysis and reports violations in the editor and in CI. Turning it on as a warning and letting the backlog sit is the failure mode: violations are the reason components get skipped, so an unenforced rule means adoption quietly stalls at partial coverage. The practical sequencing is to make the rule blocking for changed files immediately, so no new violations land, while the existing backlog is worked down as scheduled tickets. Every fix has a double payoff — a real latent bug removed, and a component promoted from skipped to compiled. ## Step 3 — pilot narrowly Two ways to narrow, and both are legitimate: - `compilationMode: 'annotation'`, where nothing compiles unless the function carries a `"use memo"` directive. Maximum control, good for a first exposure. - Scoping the Babel plugin to a directory in the build config, so an entire well-tested feature area compiles at once. Pick an area with real test coverage and low blast radius, not the checkout flow. Then widen to the default inference mode when the pilot has run in production long enough to be boring. ## Step 4 — verify with evidence Two distinct checks, and teams routinely skip the second. **Correctness:** the test suite, plus manual exercise of the pilot area. Watch specifically for the bug class that only appears once memoization exists — code that unknowingly depended on a fresh object or function identity every render, an effect whose dependency now stops changing, or an impure render whose mutation was previously masked by constant recomputation. **Benefit:** profile a real, representative interaction before and after. A well-composed app that already moved state down and passed subtrees as children may gain very little, and that is a legitimate finding — it means the adoption argument rests on removing memoization *maintenance*, not on speed. Reporting "we enabled the compiler" with no measured delta is not a result. ## Step 5 — policy for the escape hatch and the old memoization `"use no memo"` is a bisect tool. Left in place it marks a component that is both unoptimised and known to misbehave under caching — that is, one with a latent impurity. Require an owner and a removal ticket on every occurrence, and grep for them periodically. On existing `useMemo`/`useCallback`/`React.memo`: do not run a big-bang deletion. The compiler understands and preserves them, so they are harmless. Remove them opportunistically as files are touched, and review each one for whether it was ever about render cost — a few encode identity requirements that must survive. ## What separates a strong answer Sequencing (survey → enforce → pilot → measure → widen), naming the lint rule as a gate rather than advice, acknowledging that gains are proportional to how much waste existed, and putting an expiry on opt-outs. A weak answer is "add the Babel plugin and ship it"; the compiler makes that mostly survivable, which is exactly why the discipline has to be argued for rather than assumed.