REL1CX

> Then why it must be implemented here instead of an option of `perfectionist/sort-jsx-props` nor `@stylistic/jsx/jsx-sort-props`? Because this is the only way to correctly set the severity of the two...

> > Because this is the only way to correctly set the severity of the two types of problems mentioned above under the ESLint plugin system > > Why it/they...

> > This is exactly the bad practice, caused by a lack of understanding of the linter tool. > > Hah? The current implementation is exactly the bad practice without...

> > This is exactly the bad practice, caused by a lack of understanding of the linter tool. > > Hah? The current implementation is exactly the bad practice without...

In most cases, this is an advantage rather than a drawback. When a rule takes on too many responsibilities, the rule itself becomes a "plugin", and its error messages (as...

> What if the rule logic were enhanced such that — when used as a an object method — it will only apply when the object is `React`? > >...

> I was curious how complex the code was that [@Rel1cx](https://github.com/Rel1cx) shared and it goes deep, with many helper functions. Feel free to correct me if it's not as bad...

> Modern: what are the API differences? Why are they better? > Performance: got stats? what's different? @JoshuaKGoldberg We have a lot to discuss about both aspects, but for now,...

Based on recent feedback on the `eslint-plugin-react-hooks` 7.0 update, I'm reconsidering the integration of the `exhaustive-deps` and `rules-of-hooks` rules, also mentioned in #710

> I'd suggest that passing in a signal should be sufficient to satisfy the rule, since the linter can't reliably determine whether that signal will be aborted at the appropriate...