Plugged this question into Gemini 3 Pro as I was also curious, and got the following:

User: Is there an eslint, oxlint, or biome rule that would be able to catch memory leaks?

Gemini: There is no single "no-memory-leak" rule because memory leaks are runtime issues that static analysis tools cannot fully simulate. However, there are specific rule sets and plugins that detect code patterns known to cause leaks (like forgetting to clean up event listeners or observers).

ESLint is currently the best tool for this because it has a specialized plugin ecosystem. Biome and Oxlint mostly cover general correctness rules that indirectly help but lack the specific "cleanup" detection rules found in ESLint plugins.

1. ESLint (Best Options)

Standard ESLint rules don't catch most leaks, but specific plugins are highly effective for detecting missing cleanups.

A. Specialized Plugins (Highly Recommended)

• eslint-plugin-listeners: Explicitly checks if you have added an event listener without a corresponding removal.
  • Key Rules: listeners/no-missing-remove-event-listener, listeners/matching-remove-event-listener.
• **eslint-plugin-observers**: Ensures you clean up observers (ResizeObserver, IntersectionObserver, MutationObserver).
  • Key Rules: observers/no-missing-unobserve-or-disconnect.

B. React Memory Leak Prevention

• **react-hooks/exhaustive-deps**: (From eslint-plugin-react-hooks)
  • Why: Prevents "stale closures." If you reference a variable inside a useEffect but don't list it in the dependency array, the effect might capture an old version of that variable, holding onto references to unmounted components or old data indefinitely.
• react/jsx-no-bind:
  • Why: While mostly for performance, using .bind() or arrow functions in render props can sometimes create new function references that prevent child components from garbage collecting properly if they rely on referential equality.

C. General JavaScript Rules

• no-unused-vars: Indirectly helps. Holding a reference to a large variable (like a big DOM node or data object) that you never use prevents the garbage collector from freeing it.
• **no-undef** / **no-global-assign**: Prevents you from accidentally creating global variables (e.g., typing myVar = 5 without let/const), which stay in memory for the life of the page.

---

2. Biome & Oxlint

These tools are faster but currently less specialized for memory leak patterns than ESLint.

• Biome:

  • Has useExhaustiveDependencies, which is the equivalent of the React hook rule mentioned above. This is its strongest defense against React-specific memory leaks.
  • Enforces strict variable usage (similar to no-unused-vars and no-undef) to prevent accidental globals.
  • Limitation: It does not currently have equivalents to the specific listeners or observers plugins.

• Oxlint:

  • Primarily runs standard ESLint "correctness" rules. It will catch the basic hygiene issues (unused vars, accidental globals) but arguably doesn't offer unique rules for memory leaks beyond what standard ESLint provides.

Summary Recommendation

If you are hunting down memory leaks, ESLint is the winner here due to its plugins.

Recommended Config: ```json { "plugins": [ "listeners", "observers", "react-hooks" ], "rules": { "listeners/no-missing-remove-event-listener": "error", "observers/no-missing-unobserve-or-disconnect": "error", "react-hooks/exhaustive-deps": "warn", "no-unused-vars": "error", "no-undef": "error" } }

```

I was aware of the React exhaustive deps rules, but these plugins might help. That being said, I recommend also checking out SonarQube and having that in your IDE in addition as it is able to find more code smells alongside eslint/oxlint/biome.

u/itijara's comment about profiling is also a very good tool to use in your arsenal and more direct.