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

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

Relevant Package

parser

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

Spinning out of DefinitelyTyped/DefinitelyTyped#68232: right now, the types for ASTs generated by @typescript-eslint/parser have "one size fits all" types. DefinitelyTyped/DefinitelyTyped#68232 (comment):

https://github.com/typescript-eslint has options (just like espree, et al) which let you change the shape of the AST. By default those options turn off things like the ranges.

However eslint does pass in the options to turn on the things it needs. So our AST then matches their shape.
https://github.com/eslint/eslint/blob/60b966b6861da11617ddc15487bd7a51c584c596/lib/linter/linter.js#L828-L841

We could define this with conditional types - but then it still wouldn't match the types you've declared.

One tricky thing is that for the sake of simplicity I don't think we want to make custom lint rule users have to see type parameters & optionality pop up all over the place in their AST. I think we'll want to have two ASTs that can be generated:

• parse: Utilizes the fancy new conditional types to make the AST shapes more precise
• parseForESLint: Avoids the fancy new conditional types and uses the same existing non-generic versions of AST nodes

I think we can get there with the following changes:

• Give NodeOrTokenData an type parameter object for whether it has loc and/or range
• For the AST types that feed into types/src/generated/ast-spec.ts, create a second version of the nodes with that same type parameter object - i.e. ParsedProgram<* extends *> extends NodeOrTokenData<*>
• Make parse configurable with that new type parameter object
• Have parse's return type use a new ParseResult interface that forwards that type parameter object to its AST nodes
• Make no changes to ParseForESLintResult or other rule infrastructure: it returns the same nodes as before

I.e. we'd be making a new set of node types that users of parse now see, without changing parseForESLint or custom rules.

Additional Info

No response