Unify type assertion nodes

[JoshuaKGoldberg]

Discussed in #6021

^{Originally posted by bradzacher May 31, 2020}
There are two styles for type-assertions:

• as assertions (x as type)
• "angle bracket" assertions (<type>x)

Currently they produce two different, but almost identical ASTs:

const x = 1 as 1;

{
  "type": "TSAsExpression",
  "expression": { /* ... */ },
  "typeAnnotation": { /* ... */ }
}

and

const y = <1>1;

{
  "type": "TSTypeAssertion",
  "expression": { /* ... */ },
  "typeAnnotation": { /* ... */ }
}

I don't think that there's a reason why these should be separate AST nodes. I think that they're separate nodes because they have different code representations, but I don't know if that's something that matters from the POV of the AST. Similar to the discussion that's going on around the ESTree representation of optional chaining - there is a difference between the AST and the CST.

From the perspective of ESLint, having two nodes causes pains when writing lint rules, as authors have to remember to add both nodes to selectors or if checks. Often they don't, which means rules don't have proper support for TS syntax.

I propose that we unify the two nodes with the following AST:

interface TSTypeAssertion extends Node {
  type: AST_NODE_TYPES.TSTypeAssertion;
  typeAnnotation: TypeNode;
  expression: Expression;
  kind: 'as' | 'angle-bracket';
}
```</div>

Consider this issue a re-opening of #2142.

[bradzacher]

Worth noting that now we have TSSatisfiesExpression as well - so we have 3 nodes for assertions now!

[Josh-Cena]

TSSatisfiesExpression should definitely be a separate thing from the other two—it has entirely different semantics from an "assertion". But the TSTypeAssertion amalgamation makes some sense to me.

[bradzacher]

It's worth noting that the AST is there to represent the syntax, not the semantics of the code.

The original issue suggested aligning the nodes based on the semantics (as assertion being the same as an angle bracket assertion), but was suggested to try and make it easier for lint rule authors.

From a pure ast perspective - satisfies and as should really be the same node with kind: 'as' | 'satisfies', and angle bracket assertions exist as their own node.
But it just easier overall to keep things separate so that old rules don't accidentally match satisfies expressions.

At this point I think almost everyone has moved away from angle bracket assertions, so it's becoming less relevant to merge things.

[JoshuaKGoldberg]

... so it's becoming less relevant to merge things.

Yeah I don't think this is really necessary anymore. I can't recall anybody external to us asking for it, and it's not completely cut-and-dry which one to go for. I'll just close this issue for now.

Someone should yell & make noise if there's a compelling reason to make this change!