Consider components in jsx as missing dependencies in @typescript-eslint/parser@4.x

[eps1lon]

Summary

Closes #19810

1. extract flow tests from tests
   This results in 3 test suites for JS, Flow and TypeScript. I originally thought Bug: eslint-plugin-react-hooks "Cannot read property parent of null" #19810 was only failing with TS parsers. So I wanted to also run all JS tests with the TS parsers (since any JS is also valid TS) but tests included some tests written for flow which isn't valid TS. Turns out the test in question only fails with a specific major of @typyescript-eslint/parser so that effort isn't strictly necessary for this PR but it increases test coverage nonetheless.
2. add minimal repro from Bug: eslint-plugin-react-hooks "Cannot read property parent of null" #19810 (comment) to failing tests
   Turns out this only crashes in @typescript-eslint/parser@4.x. All other parsers incorrectly mark this as valid which is tracked in Bug: [eslint-plugin-react-hooks] exhaustive-deps false positive on "unnecessary" dependency if its a React component #18051
3. Fix failing test by supporting JSXIdentifier

Test Plan

• CI green

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 553f6cc:

Sandbox	Source
React	Configuration

[sizebot]

No significant bundle size changes to report.

Size changes (stable)

Generated by 🚫 dangerJS against 553f6cc

[sizebot]

No significant bundle size changes to report.

Size changes (experimental)

Generated by 🚫 dangerJS against 553f6cc

[eps1lon]

That is a bit hacky since it would return true when comparing isSameIdentifier(Component, <Component />). Can't imagine a path that would lead to this though.

[gaearon]

That sounds odd. Can we find a way to tighten it up?

[eps1lon]

Added a check that makes sure a and b are the same kind of identifier. isSameIdentifier-ish is probably more accurate at this point.

[gaearon]

Are you saying this fixes #18051? Why?

[eps1lon]

Are you saying this fixes #18051?

It fixes it only for @typescript-eslint/parser@4.x. For any version below (or other parsers) this PR has no effect.

Why?

Isn't #18051 similar to the test I added?

function Foo({ Component }) {
  React.useEffect(() => {
    console.log(<Component />);
  }, [Component]);
};

I tried the added test with @typescript-eslint/parser@3.x and with that parser the code is (falsely) considered valid. I can restructure how the tests are partitioned so that it's more obvious that one test is invalid with one parser but valid with another one.

[gaearon]

For any version below (or other parsers) this PR has no effect.

That’s what I was missing. We should make sure we don’t accidentally close that issue then.

Is this good to go?

[eps1lon]

For any version below (or other parsers) this PR has no effect.

That’s what I was missing. We should make sure we don’t accidentally close that issue then.

Is this good to go?

Oh, I understand the confusion. I didn't intend to reference #18051 for automatic closing but #19810

[eps1lon]

Is this good to go?

Should be. Not a fan of how the test suite is growing. I hope it doesn't get too confusing.