function-component-definition should not match unfixable edge cases (TypeScript generics)

[philer-jambit]

The documentation for the function-component-definition rule helpfully points out, that certain cases in TypeScript code using generics can not be fixed.
For example this:

function Component<T>(props: Props<T>) {
  return <div />;
};

can not be converted into an arrow function as the type parameter conflicts with JSX syntax.

Since that is the case, the rule should not highlight these cases as errors to begin with.

Thanks :)
Also, generally great work on this plugin!

Note: There may be a suggestion to just add some more syntax, like <T extends unknown>, to prevent the syntax collision. However not only does this conflict with other linting rules specifically designed to prevent this ( particularly (@typescript-eslint/no-unnecessary-type-constrain ), it also obscures the fact that code was added to alleviate a deficiency in the linter.
IMHO the only valid way to deal with this currently is to spam eslint-disable-next-line, which is not great.

[ljharb]

The patterns that aren't autofixable aren't necessarily un fixable - however, if there is a pattern that has no other possibility, you're right, we shouldn't warn on it.

[TUTAMKHAMON]

isn't this generally auto-fixable this way?

- function Component<T>(props: Props<T>) {
+ const Component = <T,>(props: Props<T>) => {
  return <div />;
};

(notice the comma)

[ljharb]

Converting a named function to an arrow function would be a harmful fix; components shouldn’t be arrow functions.

[TUTAMKHAMON]

@ljharb That's besides the point. The rule offers that option so it should support it. As it stands it's ability to "autofix" some of the components it may encounter stands hindered by an issue that's easily fixable.
Now I'll have a guess that this is a deficiency that enough people run into, given it has that specific example in the documentation for the rule:

function components with one unconstrained type parameter cannot be autofixed to arrow functions because the syntax conflicts with jsx

and seeing how there is a simple enough solution for it, I think it warrants some more consideration than "just don't use the rule that way".

[ljharb]

That's not besides the point; autofixes are supposed to be safe, and that wouldn't be one.

See #3345 (comment) for the PR i'm looking for here.