Docs: jot down comon patterns for rule development

[kirkwaiblinger]

Before You File a Documentation Request Please Confirm You Have Done The Following...

• I have looked for existing open or closed documentation requests that match my proposal.
• I have read the FAQ and my problem is not listed.

Suggested Changes

I wonder if there's a good spot we could catalog common strategies we recommend for rule development, especially for contributing to typescript-eslint, but also for custom rule developers.

For example, the maintenance page for reviewing PRs has a couple helpful ideas. Maybe we could expand this and add it to the corresponding page for new contributors who would like to get involved (perhaps with an asterisk of "don't feel like you have to do all these perfectly; just do your best, and we are happy to help you with common edge cases")? Or it could also be helpful for the custom rule development guide.. Maybe these all link to a new page?

Already listed in maintenance page:

• getConstrainedTypeAtLocation
• getWrappingFixer
• unionTypeParts/intersectionTypeParts

Some ideas to add (off the top of my head):

• Tagged Templates are fancy function calls. Consider whether they should be checked as well when linting function calls in a rule.
• It's a common strategy check inside some syntaxes recursively (examples in no-floating-promises and prefer-find). For example:
  • ternary branches ("ConditionalExpression")
  • comma operator ("SequenceExpression")
  • optional chaining expressions ("ChainExpression")
  • sometimes, things like &&, ||, ?? ("LogicalExpression")
• Prefer to use things like getStaticValue and a utility for static member access (once it exists, see Repo: Make utility for static member access #8323) to pick up more edge cases for free.
• .... probably there are more!

Affected URL(s)

https://typescript-eslint.io/developers/custom-rules/
https://typescript-eslint.io/contributing/pull-requests
https://typescript-eslint.io/maintenance/pull-requests#common-things-to-look-for

[kirkwaiblinger]

Another one would be

• When inspecting the type of function params, you must check whether it's an ordinary param, or not (i.e. rest param or destructuring params. Nothing stops you from querying the type of the param without this check, but the result will mean something completely different, especially depending whether it's rest param or not. (e.g. Bug: [no-floating-promises] False positive for spread arguments in then() #8958)