set-state-in-effect not consistent with eslint plugin

[einarq]

I run a fairy strict eslint setup on any code that is being committed:

  rules: {
    ...reactHooks.configs['recommended-latest'].rules,
    // https://github.com/facebook/react/blob/3640f38/compiler/packages/babel-plugin-react-compiler/src/CompilerError.ts#L807-L1111
    'react-hooks/todo': 'error',
    // other useful rules:
    'react-hooks/capitalized-calls': 'error', 
    'react-hooks/hooks': 'error', 
    'react-hooks/rule-suppression': 'error', 
    'react-hooks/syntax': 'error', 
    'react-hooks/unsupported-syntax': 'error', 
  }

Still, code like this goes through without complaints.

  const [image, setImage] = useState(initImage);
  useEffect(() => {
    setImage(initImage);
  }, [initImage]);

When I run the React Doctor however, it points out that this should be derived during render instead.

Perfectly valid to highlight this, but curious how this is being detected by the Doctor when the Compiler doesn't complain?

[einarq]

Actually I wonder if Doctor has its own heuristics, and thereby just consider any function that begins with "set" to be a state setter?

[OmniSliver]

You're probably using an old version of the "react-hooks" Eslint plugin.

For reference, the rule that checks that case is set-state-in-effect and is included in the "recomended" set.

[einarq]

Using v7.0.0 of the plugin, and using the "recommended-latest" preset (which also includes the rule).
Several other areas are highlighted by the plugin, but this one goes unnoticed but still picked up up by React Doctor.

Also think I've seen a "setTimeout" call in a useEffect mistakenly highlighted, so thats what made me wonder if it has its own somewhat naive heuristics.