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-hooks (build issue installing or using the eslint plugin)
• react-compiler-healthcheck (build issue installing or using the healthcheck script)

Link to repro

https://github.com/manNomi/rc-test

Repro steps

🐞 Bug Report: eslint-disable incorrectly suppresses incompatible-library warning, causing silent memoization skip

Summary

First and foremost, I want to express my sincere gratitude for the clarification provided in #35096. You were absolutely correct that the compiler automatically skips memoization for incompatible APIs, and I apologize for my earlier misunderstanding about needing use no memo.

I'm writing to humbly bring attention to what I believe may be an important edge case: an unrelated eslint-disable comment (such as for exhaustive-deps) appears to inadvertently suppress the incompatible-library warning. This transforms what should be a debuggable "automatic skip" (where developers are properly notified) into a silent skip scenario (where no notification occurs), which could potentially lead to confusion, especially for developers who are still learning React.

The Two Scenarios

Please allow me to illustrate the concern through two scenarios:

Scenario 1: Expected Behavior (Debuggable)

1. A developer uses useVirtualizer (an incompatible API) within a custom hook
2. Compiler: Automatically and correctly skips memoization for this hook
3. Linter: Properly displays the react-hooks/incompatible-library warning
4. Result: The developer is informed that this hook is not memoized and can adjust their debugging approach accordingly

This behavior works wonderfully and as intended.

Scenario 2: Potential Issue (Silent Skip)

1. A developer uses useVirtualizer (an incompatible API) within a custom hook
2. In the same hook, they add a useEffect with an eslint-disable-next-line react-hooks/exhaustive-deps comment
3. Compiler: Skips memoization for this hook (due to the incompatible API)
4. Linter: The eslint-disable-next-line react-hooks/exhaustive-deps comment appears to also suppress the react-hooks/incompatible-library warning
5. Result: The hook is silently un-memoized without any warning, leaving the developer without a debugging signal

Why This Matters

I understand this might be an edge case, and React's design philosophy encourages certain patterns over others. However, in real-world development, developers (especially those newer to React) sometimes write code in varied ways, which can lead to unexpected edge cases like this.

The particular concern is that when code is extracted into a custom hook, no error is thrown, yet only that custom hook loses its memoization—creating a subtle performance issue that's very difficult to trace.

The incompatible-library warning serves as a crucial debugging signal, informing developers that the compiler's automatic skip has occurred. When an unrelated eslint-disable rule inadvertently silences this critical signal, developers may believe their code is functioning correctly (since the linter appears clean), while the hook is actually un-memoized without their knowledge.

Respectful Suggestion

If I may humbly suggest: perhaps an eslint-disable comment for one rule (such as exhaustive-deps) could be prevented from suppressing a different, critical warning (like incompatible-library)?

The incompatible-library warning might benefit from having higher precedence, displaying regardless of other eslint-disable comments, as it signals a fundamental state of the hook that developers should be made aware of.

Closing Thoughts

I want to emphasize that I have tremendous respect and love for React—it has genuinely transformed my career and given me my livelihood. If the team believes this direction would be valuable, I would be more than happy to contribute and help implement a solution to the best of my abilities.

Thank you so much for taking the time to consider this report, and for all the incredible work you do on React. The React Compiler is an amazing advancement for the ecosystem, and I'm excited to see it evolve.

With sincere appreciation and respect.

How often does this bug happen?

Every time

What version of React are you using?

19.2.0

What version of React Compiler are you using?

1.0.0