Originally this was a part of #11578 however it was decided better to do it separately, because it looks to be bigger refactoring(not just converting it to typescript).

This is still very much in progress - and is just a starting point, to start experimenting with next steps.

Remaining issues, to solve:

1. Decide how to type incomplete nodes

The problem is that currently parser typically starts with node which does not yet have a specific node type, and then adds more properties to it or removes some of them, to eventually get final node type.

Often it looks like this:

 // creates `Node` which is not expected to have additional props, T also in many cases is not yet clear
const node = this.startNode<T extends Node>(…);
if(…) {
  node.someNode1SpecificProp = …;
  return this.finishNode<T>(node, "Node1");
} else {
  node.someNode2SpecificProp = …;
  delete node.somethingNotUseful;
  return this.finishNode<T>(node, "Node2");
} 

TypeScript does not work well with that approach… Also, there might be some space for optimization, not sure but I guess it might be faster to have constructor or object literal

2. Decide what to do about src/types

Node types there are incomplete, and in some cases were effectively same as any for type-checks with flow… I tried to fix it, however I guess - @babel/types probably should be used instead or to add some code generation for parser as well.

Suggestion - to try doing something like this instead:

 // creates builder which stores some information about context where node was started
const nodeBuilder = this.startNodeBuilder(…);
if(…) {
  const someNode1SpecificProp = …;
  // inside to use builder from @babel/types
  return nodeBuilder.node1(someNode1SpecificProp);
} else {
  const someNode2SpecificProps = …;
  // use builder from @babel/types
  return nodeBuilder.node2(someNode1SpecificProp);
} 

This would be much better for type-checking, and will require less manual type annotations.

However about builders - probably this might require some changes for generated builders in @babel/types if to used them - I worry, they might be slow, In particular - I think we might want to remove or disable runtime parameter validation(not actually sure how beneficial that would be…), and generally make them less dynamic instead generating more code.

Drafted changes for @babel/types here #13369