React Compiler awareness does not suppress fresh manual dependency diagnostics

[simPod]

Summary

React Doctor 0.9.3 reports react-doctor/no-effect-with-fresh-deps and react-doctor/exhaustive-deps in a Vite client that has React Compiler enabled through babel-plugin-react-compiler.

Some of these findings may still be useful, but the diagnostics do not indicate how React Compiler changes the cost or whether a manual rewrite is required. This makes it difficult to distinguish actionable dependency mistakes from compiler-redundant manual memoization cleanup.

Setup

• React Doctor: 0.9.3
• React Compiler is configured in Vite:

import reactCompiler from "babel-plugin-react-compiler";

export default defineConfig({
  plugins: [babel({ plugins: [jsxSyntax, reactCompiler] })],
});

• The React Compiler ESLint plugin is also enabled.
• Invocation:

pnpm exec react-doctor . --yes --lint --no-dead-code --no-supply-chain --no-score --verbose --no-warnings --blocking none

Examples

The audit reports:

• react-doctor/no-effect-with-fresh-deps for a useMemo whose dependency is a freshly created Date.
• react-doctor/no-effect-with-fresh-deps for a useCallback that depends on a fresh wrapper callback.
• react-doctor/exhaustive-deps for the related dependency arrays.

React Doctor can already detect this project has React Compiler: it emits react-hooks-js/incompatible-library and React Compiler syntax diagnostics. However, the dependency diagnostics are still presented without compiler-aware guidance.

Expected behavior

When React Compiler is enabled and detected, please either:

1. Suppress only findings that are compiler-redundant, or
2. Keep reporting them but mark their compiler status and explain why an explicit manual change is still needed.

Rule-specific behavior would be important: no-mutable-in-deps remains actionable because ref.current is not reactive, while a purely manual callback-stability cleanup may be less urgent under the compiler.

Why this matters

Without this distinction, projects can accumulate low-value manual memoization rewrites or broad suppressions that risk hiding genuinely actionable dependency issues.

[simPod]

Related to #1468, but this project uses a different @rolldown/plugin-babel configuration:

import reactCompiler from "babel-plugin-react-compiler";

babel({ plugins: [jsxSyntax, reactCompiler] })

It does not use reactCompilerPreset(). #1468 and PR #1469 cover the preset detection path; this report is specifically about direct babel-plugin-react-compiler registration and the resulting dependency diagnostics.

[react-doctor-evals]

❌ Triage errored — trace 9b0381cba472e69cd3c98f20bef939df. Check server logs for that trace ID.

[simPod]

Follow-up: I migrated the reproduction project to the documented reactCompilerPreset() setup with @rolldown/plugin-babel:

import react, { reactCompilerPreset } from "@vitejs/plugin-react";
import babel from "@rolldown/plugin-babel";

plugins: [react(), babel({ presets: [reactCompilerPreset()] })]

Vite 8.2.0 successfully builds with this configuration, but React Doctor 0.9.3 still reports hasReactCompiler: false for the client project through its supported JSON inspection. This appears to reproduce the detection issue even on the preset path.

[aidenybai]

fixing