[Compiler Bug]: The “one or more React ESLint rules were disabled” check is too aggressive

[iamakulov]

What kind of issue is this?

• React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
• babel-plugin-react-compiler (build issue installing or using the Babel plugin)
• eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
• react-compiler-healthcheck (build issue installing or using the healthcheck script)

Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAwhALYAOhCmOAFAJRHAA6xRchYOLRAbgEMANlAQAaImAQ4A8jgAWCGADURYogF8iAXiJRpAZQoIAEhAgBrJu3ZF90gKJo0CXPSa6AfCzv3O3BDCCAB0whAA5vRCogiMfvbScorKarHR6nEJRAD0OUQIYMJ4dAC0ACZ4YIIARsGlmAgAHjilxY1EMAiCuKUKFpZgOc0Kggb4-AgVCJRgfpqSANoxYgC68Zh+XTiwxAA8JAp4wuUCmTrAKwjaOV7smiCaQA

Repro steps

A codebase where I’m adopting React Compiler right now has multiple components with // eslint-disable-next-line react-hooks/exhaustive-deps put in front of a useEffect dependency array:

function Component() {
  const { value, setOtherValue } = useSomeHook()

  useEffect(() => {
    console.log(value)
    setOtherValue(value)
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [value])

  return <Child value={value} />
}

(In this scenario, the developer’s intention is to run the effect only when value changes.)

This is, arguably, a code smell (if setOtherValue changes, we won’t call it, and that might lead to bugs!). But this doesn’t affect the effectiveness of memoization. However, Compiler bails out when it sees any ESLint comment like that, leading to deopts in components that would otherwise be perfectly memoized.

How often does this bug happen?

Every time

What version of React are you using?

19.1.1

What version of React Compiler are you using?

19.1.0-rc.2

[josephsavona]

Thanks for posting. There's two things happening here:

• By default we shouldn't report an error if there's a ESLint suppression: the user already knows there is an issue with the code. This is on our todo list.
• And then, as you alluded to, suppressing an exhaustive deps rule on an effect specifically doesn't affect memoization. It would be safe to memoize this example despite the lint suppression. We've had this on our wish list for a while, the only catch is just being more precise about detecting where existing suppressions are.

[ricaxvi]

Let me do it!

[zekariasasaminew]

@ricaxvi are you working on this? I was planning to try this out

@josephsavona @iamakulov

[josephsavona]

Part one of what I said is already done, with the recommended lint config in the latest release you won’t see errors about other rules being suppressed.

Part two is in progress in the stack at #34394 - we’re moving exhaustive deps checking into the compiler so that we can treat violations on effects differently than memo/callback.

[dimaMachina]

you can use // eslint-disable-line react-hooks/exhaustive-deps which isn't checked by react compiler ;)

  useEffect(() => {
    console.log(value)
    setOtherValue(value)
+ }, [value]) // eslint-disable-line react-hooks/exhaustive-deps

[josephsavona]

@dimaMachina ah good catch, we should detect that too