Perf: react-hooks ESLint plugin (eslint-plugin-react-hooks) rules are extremely slow, dominating lint time

[jordan-cutler]

react-hooks ESLint plugin rules are extremely slow, dominating lint time

• React version: react@19.2.3
• eslint-plugin-react-hooks version: eslint-plugin-react-hooks@7.0.1
• eslint version: eslint@9.39.1

Steps To Reproduce

1. Install eslint-plugin-react-hooks (the React Compiler ESLint plugin)
2. Enable the recommended plugin rules: e.g. reactHooksPlugin.configs.flat.recommended, jstsFiles
3. Run ESLint with TIMING=50 on a large codebase (~15k+ files)
4. Observe that react-hooks/static-components takes 42-56% of total lint time

Link to code example

Unfortunately, we cannot share a minimal reproduction as this occurs on a large proprietary codebase. However, the performance data should be reproducible on any sufficiently large React codebase.

The current behavior

When running ESLint with the TIMING flag on our codebase, the react-hooks plugin rules dominate lint time:

Rule                                       |  Time (ms) | Relative
:------------------------------------------|-----------:|--------:
react-hooks/static-components              | 393394.236 |    56.2%
unused-imports/no-unused-imports           |  62579.162 |     8.9%
redos-detector/no-unsafe-regex             |  35114.790 |     5.0%
import/named                               |  24641.617 |     3.5%
react-hooks/rules-of-hooks                 |  16596.903 |     2.4%
...

Key findings:

• react-hooks/static-components takes ~393 seconds (6.5 minutes) — more than 5x longer than the next slowest rule
• The react-hooks plugin nearly doubles total lint time: ~3 minutes without the plugin vs ~6 minutes with it enabled
• With 4x parallelism (--concurrency=4), total ESLint time goes from ~190 seconds to ~370 seconds when the plugin is enabled
• Even if we disable react-hooks/static-components, another rule jumps up to take the top spot. It seems to trigger from the plugin itself, not any particular rule.

The expected behavior

The react-hooks rules should have comparable performance to other ESLint rules. A single rule taking 42-56% of total lint time and being 5x slower than any other rule suggests there may be optimization opportunities in the rule implementation.

---

Impact: This performance issue significantly affects CI pipeline times and local development experience. We're considering running these rules as a separate parallel step or disabling them entirely, which isn't ideal.

[josephsavona]

Thanks for posting. For context, note that React Compiler’s lint rules are easily an order of magnitude more complex than typical lint rules. The lint rules are checking the same thing that the compiler itself checks as part of the build process, to provide consistent validations between lint and build. Given the level of sophistication and assistance the compiler provides, we think it’s not unreasonable that it takes longer than other rules.

As for why disabling one rule just makes another rule look longer: this is due an extreme limitation of ESLint in which different rules cannot share any analysis. To work around this, we run ~all the rules the first time, regardless of which exact rules are configured (again, no great option due to ESLint limitations), and then as ESLint processes each rule we just grab the already computed errors for that rule and report them. Rules-of-hooks and exhaustive-deps are the exceptions, they are standalone and don’t (yet) use the compiler infrastructure.

Compiler performance is definitely something we’re keeping an eye on, and feedback like this helps us prioritize. There are a few semi easy optimizations we could potentially do to speed up lining. The obvious one is to accept eslint’s native estree format as input instead of re-parsing in Babel. But the AST -> HIR conversion is non-trivial and we don’t really want to have to duplicate the whole thing.

[jordan-cutler]

Thanks for the quick reply, @josephsavona and it's good to know the background context on why the rules are so slow. In a sense, it almost seems like its a totally separate check from how normal ESLint rules operate--kind of like running the TS compiler. It came as a big surprise to us. Would it make sense to make that expectation explicit somewhere? Also, are there any workarounds you'd suggest in the meantime?

Our team would like to adopt the React compiler and prevent React compiler breakages through some form of check, and of course, having it in ESLint is nice for near-immediate feedback and shifting left in developer flows. At the same time, we're coming up on ESLint being the bottleneck in our CI flows due to the slow performance.

[Faithfinder]

This is also specifically a problem in v7, since there's no more config that doesn't include the compiler rules, so you're forced to hut down compiler rules by name and turn them off manually.