Before You File a Proposal Please Confirm You Have Done The Following...

• I havesearched for related issues and found none that match my proposal.
• I have searched thecurrent rule list and found no rules that match my proposal.
• I haveread the FAQ and my problem is not listed.

Relevant Package

utils

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

#6814 ->#8146 and the discussion in#8149 are making me think that we really,really don't want users to use a parser that isn't at the very least running@typescript-eslint/parser internally. This is for two reasons:

• typescript-eslint rules need to be able to assume the TSESTree shape for the AST
• Type-checked rules need our generated type information

#8146 tries enforcing the exact parser being used - but that won't work for all users because some languages require wrapping parsing with their own (https://github.com/typescript-eslint/typescript-eslint/pull/8146/files#r1437273011). So checking the exact parser isn't likely feasible.

Instead, what if we augmentRuleCreator so that rules verify some basic assumptions about the parsed AST / context beforecreate(context)?

• It can check the root nodes to make sure there's the expected TSESTreeProgram AST node
  • I haven't verified that this is true for other parsers - but likely an equivalent will hold up
• It can it can run the normal checks fromgetParserServices on theesTreeNodeToTSNodeMap andtsNodeToESTreeNodeMap node maps existing
• If the rule has type checking, it can run the normal check fromgetParserServices on theprogram existing if!allowWithoutFullTypeInformation

Additional Info

No response