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.

[tony-scio]

I have to say, I absolutely love these rules. They're catching lots of subtle issues.

But also agree the overhead isn't tenable for large repos. We can't get lint to finish reliably on the repo with them enabled.

Here's a sample from an 82kloc subset of our repo.

react-hooks/immutability: 15425.044 ms (37.1%)
import/no-named-as-default: 5017.783 ms (12.1%)
@typescript-eslint/no-unsafe-return: 3968.732 ms (9.6%)
@typescript-eslint/unbound-method: 2475.436 ms (6.0%)
import/order: 1962.332 ms (4.7%)
@typescript-eslint/no-floating-promises: 1688.898 ms (4.1%)
@typescript-eslint/no-misused-promises: 1165.323 ms (2.8%)
@typescript-eslint/naming-convention: 888.312 ms (2.1%)
react/no-direct-mutation-state: 776.816 ms (1.9%)
@typescript-eslint/no-unsafe-call: 756.896 ms (1.8%)
react-hooks/rules-of-hooks: 665.946 ms (1.6%)
@typescript-eslint/no-unsafe-member-access: 540.447 ms (1.3%)
@typescript-eslint/no-restricted-imports: 224.026 ms (0.5%)
react/require-render-return: 180.518 ms (0.4%)
rulesdir/no-untranslated-strings: 177.146 ms (0.4%)

Using:
eslint@9.39.2
eslint-plugin-react-hooks@7.0.1
react@18.3.1

[mutewinter]

https://typescript-eslint.io/troubleshooting/typed-linting/performance has good guidance for slow rules like these.

I switched to only running react-hooks/static-components in CI. E.g.

export const ERROR_IN_CI = process.env.CI === "true" ? "error" : "off";

const config = tseslint.config(
  ...baseConfig,
  reactPlugin.configs.flat.recommended ?? {},
  {
    plugins: {
      "react-hooks": pluginReactHooks,
    },
  },
  {
    files: ["**/*.{js,jsx,ts,tsx}"],
    rules: {
      "react-hooks/static-components": ERROR_IN_CI,
    },
  },
);

export default config;

[jordan-cutler]

Thanks for sharing that workaround. We did something similar with splitting up our lint configs into two sets. Still, both workarounds are far from ideal since it means we're somewhat recreating a compile step but as part of lint rules instead of its own separate thing. We'll have to maintain two separate lint configs until the performance improves.

[jordan-cutler]

Another downside of this being in ESLint and needing separate configs is that we run into unexpected behaviors with // eslint-disable-next-line suppressions.

When we have two separate configs (or only enable the check in CI):

1. VSCode/Cursor only sees your main config, so it warns you that you have unused suppressions even though you don't (because it gets linted via the other config)
2. When you run eslint --fix, it by default removes unused suppressions, so when you run it with the main config without the react hook compiler rules for performance, it removes those suppressions, but then it fails later on in CI 🪦

Because of this, we've also had to remove the prevention of unused suppressions to keep these rules 🫤

Maybe there can be an option to expose this tool outside of ESLint as well to minimize the friction? It's seeming less an less like this belongs as an ESLint rule and more as its own compiler check that you can call via CLI outside of ESLint