Solution redesign using AST transform

[zm-cttae]

Currently the repository is a fork of pegjs with many hardcoded changes that are difficult to maintain.

It was generally suggested as a collateral of #92 that we transform the parser outpu tree instead.

I've been looking into doing a PR to add Peggy 3.0 support, but so far I have mostly learned that the code generation in Peggy has changed quite a lot since 2.0. So much so, that it's probably simpler to do a complete rewrite of ts-pegs than to attempt merging in changes from Peggy 3.0.

— @pjmolina

It appears that you duplicate most of the bytecode generation from Peggy. Is there a reason you don't just strip the typescript annotations from each Peggy action, let Peggy generate the source, and then re-export the Peggy-generated parser with types?

— @siefkenj

I've been looking into doing a PR to add Peggy 3.0 support, but so far I have mostly learned that the code generation in Peggy has changed quite a lot since 2.0. So much so, that it's probably simpler to do a complete rewrite of ts-pegs than to attempt merging in changes from Peggy 3.0.

— @nene

Is there a way to convert the pegjs output to an estree & add types to that, then convert back to source?

Should be possible with recast or jscodeshift.

[siefkenj]

@zm-cttae As of #97 and #98 ts-pegjs now relies on the source generated by Peggy. It inserts some surrounding code into the ast and then lets Peggy render it to a file.

[zm-cttae]

Has there been regression testing vs previous output?

In particular, do we still use import instead of let for dependencies?

[zm-cttae]

Also is there still use of any that might set off a linter rule or add code smell?

[siefkenj]

There probably is...If a type cannot be determined, it is returned as any