Rule enforcing typeAnnotation on a complex query is correct

[JoshuaKGoldberg]

Copying conversation from typescript-eslint/typescript-eslint#4065 (comment) & typescript-eslint/typescript-eslint#6444 (comment): typescript-eslint doesn't have a way to infer the types of nodes when the ESQuery selector is complex:

return {
  'ClassDeclaration, ClassExpression[id]'(
    node
    // ^? TSESTree.Node
    // Expected: something like...
    // TSESTree.ClassDeclaration | TSESTree.ClassExpression & { id: TSESTree.Identifier }
  ) {

Even with these two not(-yet?)-implemented helpers (neither of which may ever be useful for public consumers):

• [utils] Use template literal types to parse esquery selectors to automatically type complex selectors typescript-eslint/typescript-eslint#4065
• Enhancement: use codegen to generate esquery selector types typescript-eslint/typescript-eslint#6224

...there's no way for custom rules written in TypeScript to enforce that the type of node matches its AST shape. Which means devs can write blatantly wrong code like:

return {
  'ClassDeclaration, ClassExpression[id]'(
    node: TSESTree.Identifier

Is eslint-plugin-eslint-plugin an appropriate place to write a lint rule that makes sure the type annotation on a node matches the node itself?

This rule might be tricky to write given that microsoft/TypeScript#9879 blocks having a TypeScript API to check type assignability. The rule could use basic string comparisons in the meantime.

[bmish]

I'm open to accepting rules targeted at TypeScript rules/syntax, including this one.

I previously added general compatibility with TypeScript rules in v4.

Any new rule targeted at TypeScript rules should just no-op when running against a JavaScript rule.

We can even use meta.docs.category: "TypeScript" to have a separate group/list of our TypeScript-focused rules (related: #341).