ESLint Plugin: react-compiler

The eslint-plugin-react-compiler package exposes compiler findings through ESLint, so compiler-detected problems can appear as lint diagnostics during development. Its package description explicitly identifies the plugin as an ESLint surface for errors found by the React compiler.

This exists to make compiler feedback visible at the linting stage rather than requiring a successful compiler transformation first. The available source shows that rules inspect compiler result events and react specifically to CompileError events.

Sources: compiler/packages/eslint-plugin-react-compiler/package.json:1-5, compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:175-182

Core concepts

Compiler result

A compiler result is the object returned to the lint rule by getReactCompilerResult, including an events collection that the rule examines.

Sources: compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:175-180

Compile error event

A CompileError event is the compiler event kind that the rule considers when deciding whether to report a diagnostic.

Sources: compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:179-182

Rule category

A rule category is the classification used to select which compiler error belongs to the current ESLint rule. The rule compares detail.category with rule.category.

Sources: compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:180-182

Compiler execution path

A compiler execution path is the implementation selected to produce compiler results: the shown code can use a Rust compiler plugin instead of the TypeScript compiler.

Sources: compiler/packages/eslint-plugin-react-compiler/src/shared/RunReactCompiler.ts:173-178

How compiler findings become lint diagnostics

The plugin builds an ESLint rule through makeRule. When ESLint creates that rule, the implementation calls getReactCompilerResult(context) and then iterates over result.events.

The important boundary is the event kind check: only events whose kind is CompileError enter the compiler-error handling path shown in the excerpt. The rule then reads the event's detail and checks its category against the category assigned to the current rule.

This means a failing rule should be read as compiler feedback about the current source, not merely as a stylistic preference invented by ESLint. The plugin's package description says its purpose is to display errors found by the React compiler, while the rule implementation filters compiler events by category.

The available excerpts do not enumerate every error category or show the final context.report call, so they do not support naming a specific runtime bug that every lint failure catches. What they do establish is that the plugin surfaces compiler-reported failures before the compiler's normal output is accepted by the surrounding workflow.

The event-to-rule path can be summarized as follows.

The diagram reflects the visible sequence: create the rule, obtain the compiler result, inspect its events, and compare matching error categories.

Sources: compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:175-180, compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:179-182, compiler/packages/eslint-plugin-react-compiler/package.json:1-5, compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:175-182

Does linting reuse compiler analysis?

The evidence points to reuse of compiler execution and compiler events rather than a completely separate lint-only analysis. The lint rule consumes getReactCompilerResult(context), and the package is explicitly described as displaying errors found by the compiler.

The implementation also has a Rust path. When useRustCompiler is enabled, RunReactCompiler selects the Rust NAPI Babel plugin instead of the TypeScript compiler; the excerpt says that this Rust plugin handles scope extraction, compilation, and event forwarding through resolveOptions and compileWithRust.

Therefore, the plugin's analysis boundary can vary by compiler path, but both paths are described as compiler-backed paths that forward events to the lint integration. The excerpts do not prove that every diagnostic is identical across the TypeScript and Rust implementations, so differences between those paths should not be inferred from this page.

The package metadata makes the Rust integration optional at the peer-dependency level. babel-plugin-react-compiler-rust appears as a peer dependency, and its metadata marks it optional.

Sources: compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:175-180, compiler/packages/eslint-plugin-react-compiler/package.json:1-5, compiler/packages/eslint-plugin-react-compiler/src/shared/RunReactCompiler.ts:173-178, compiler/packages/eslint-plugin-react-compiler/package.json:37-45

Package shape and maintenance boundary

The package builds dist with tsup, runs tests with Jest, and supports a watch mode that rebuilds through the package's build script.

Its runtime dependencies include Babel parsing and transformation packages, hermes-parser, and Zod validation packages.

These metadata boundaries show that the plugin is distributed as a compiled package, tested independently, and connected to ESLint plus an optional Rust compiler integration.

Sources: compiler/packages/eslint-plugin-react-compiler/package.json:6-9, compiler/packages/eslint-plugin-react-compiler/package.json:14-19, compiler/packages/eslint-plugin-react-compiler/package.json:4-19, compiler/packages/eslint-plugin-react-compiler/package.json:21-45

How it connects

The plugin belongs to the compiler package area and depends on compiler execution rather than the reconciler's runtime error path. Its repository metadata places it under compiler/packages/eslint-plugin-react-compiler.

For the compiler concepts behind the result it consumes, read Compiler Overview & Pipeline and Compiler Validation & Diagnostics. Those pages are the appropriate hand-offs for pipeline ordering and the validation rules that produce compiler failures.

For the Babel integration and the Rust alternative mentioned by the lint path, read Babel Plugin Integration and Compiler Rust Port. The shown implementation explicitly selects between the TypeScript compiler and the Rust NAPI Babel plugin.

For the broader linting model and hook-specific rules, read ESLint Plugin: react-hooks. This page only establishes the compiler-backed event routing and does not define the separate hooks plugin's analysis.

Sources: compiler/packages/eslint-plugin-react-compiler/package.json:46-50, compiler/packages/eslint-plugin-react-compiler/package.json:1-5, compiler/packages/eslint-plugin-react-compiler/src/shared/RunReactCompiler.ts:173-178

Key takeaways

• eslint-plugin-react-compiler displays errors found by the React compiler.
• makeRule obtains a compiler result and inspects its events.
• The rule filters for CompileError events and matching categories.
• The lint path can use the TypeScript compiler or an optional Rust compiler plugin.

Sources: compiler/packages/eslint-plugin-react-compiler/package.json:1-5, compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:175-180, compiler/packages/eslint-plugin-react-compiler/src/rules/ReactCompilerRule.ts:179-182, compiler/packages/eslint-plugin-react-compiler/src/shared/RunReactCompiler.ts:173-178