What does the react-hooks/exhaustive-deps rule from eslint-plugin-react-hooks actually check, and what does it cost you to silence it with an eslint-disable comment?

## What the rule inspects `react-hooks/exhaustive-deps` runs on hook calls that take a callback plus a dependency array. Out of the box it recognises `useEffect`, `useLayoutEffect`, `useCallback`, `useMemo` and `useImperativeHandle`; a project's own wrapper hooks can be added through the rule's `additionalHooks` option, which takes a regular expression matching the hook names to treat the same way. For each such call it walks the callback body and collects the identifiers it references that are *reactive* — declared inside the component (props, state, values derived from them, functions defined in the body). Module-level constants, imported functions, and the setter returned by `useState` are excluded, because they cannot change between renders. It then diffs that set against the entries in the array literal and reports the difference in both directions: `React Hook useEffect has a missing dependency: 'userId'` when something is used but not listed, and an unnecessary-dependency report when something is listed but never read. ```jsx useEffect(() => { const t = setInterval(() => setCount(count + 1), 1000); return () => clearInterval(t); }, []); // warns: missing dependency 'count' ``` ## Why it is a warning, not an error In the plugin's recommended configuration `react-hooks/rules-of-hooks` is an error and `react-hooks/exhaustive-deps` is a warning. That asymmetry is deliberate. A rules-of-hooks violation is unconditionally a defect — there is no correct program that breaks call ordering. An exhaustive-deps report is a very good heuristic, but a small set of correct programs legitimately omit a dependency: a mount-only effect whose captured value is genuinely wanted at its mount-time value, or a hook whose dependency is stable by construction in a way the analyser cannot prove. ## The limits of the analysis It is purely syntactic, and there are shapes it cannot reason about: - **A non-literal array.** `useEffect(fn, deps)` where `deps` is a variable defeats it entirely — the rule reports that the dependency list is not an array literal and stops checking, because it has nothing to compare against. - **A callback that is not an inline function.** If you pass a function defined elsewhere, the rule cannot see what it reads. - **Indirection through a helper.** A function defined in the component body counts as one dependency; whether *that* function's own reads are covered depends on it being recreated each render. These are worth naming in an interview because they are the cases where a passing lint run means nothing. ## What a disable comment actually costs Suppressing the rule does not assert "this array is correct today". It asserts "never check this call site again". The realistic failure is not the moment you write it — you presumably reasoned about it — but the next edit. Someone adds a line to the callback that reads a new prop, the array is not updated, no warning appears, and the hook runs with a value captured on an earlier render. That class of bug is invisible in review because the disable comment reads as an approved decision rather than as suspended checking. So the practical discipline: a disable comment carries a one-line reason on the same line, and its scope is one call site (`eslint-disable-next-line`, never a file-level disable). If the reason cannot be written in a sentence, the code needs restructuring instead. ## The restructurings that make the warning go away honestly Most warnings are a signal that the dependency should not have been read directly: - A state value read only in order to update it becomes the functional updater form: `setCount(c => c + 1)` reads nothing, so the dependency disappears. - A function defined in the component body and used by exactly one effect can move inside the callback, which removes it from the dependency set entirely. - A value that must be current but must not re-trigger the hook can be held in a ref and read as `ref.current` inside the callback, which the rule correctly treats as non-reactive. Each of these changes the code so that the honest dependency array is the short one, rather than lying about the long one. That is the difference an interviewer is listening for: suppressing the rule negotiates with the linter, restructuring negotiates with the actual dependency. ## One organisational note Because the rule fires as a warning, teams that run ESLint with warnings unfiltered accumulate hundreds of them and stop reading the output. Either promote it to an error and fix the backlog, or fail CI on new warnings only — a permanent warning stream is functionally the same as having the rule switched off.