[FEATURE] Support for TypeScript AST nodes

[xeho91]

I'm creating a package - svelte-ast-print, which under the hood uses this awesome package. Thank you for it! 🙏

I'm attempting to achieve a momentum where I can support TypeScript syntax as well, so the ecosystem (especially for Svelte) can write codemods.
I personally have this need while contributing to @storybook/addon-svelte-csf - on an experimental support for Svelte v5. We want to improve developer's experience of migration from legacy syntax to modern. Currently, my printer (svelte-ast-print) will strip out all of the TypeScript syntax.

I know that Svelte parse does output AST nodes related to TypeScript syntax using typescript-acorn.

Possible blockers

1. typescript-acorn doesn't provide public types (interfaces) for AST nodes, nor there's any known to me a public/official ESTree TypeScript AST specification.

   If there's an agreement to help support TypeScript AST nodes with this package - esrap. Then I can help contributing to this package with exposing types of AST nodes related to TypeScript which typescript-acorn spills out.

[dummdidumm]

If we agree that it's too "dangerous" to add first class support for typescript-acorn nodes, I'm wondering if instead there's a way to create somewhat of a plugin API, where devs can contribute AST node->string participants that esrap then uses in a certain manner.

[xeho91]

If we agree that it's too "dangerous" to add first class support for typescript-acorn nodes, I'm wondering if instead there's a way to create somewhat of a plugin API, where devs can contribute AST node->string participants that esrap then uses in a certain manner.

I like the idea of a plugin API!
If you don't mind when you can find a time, could you share an initial idea of what this plugin API would look like (in terms of code, a small snippet or something)? Just to help me visualize it, so I could help better with contributing. Perhaps even to the point where I convert my package svelte-ast-print to be a plugin for esrap.

Also, just to clarify if I understood the "dangerous" part regarding adding first-class support for typescript-acorn nodes.
The risk is coming from the fact that they're not official nodes, nor is there any official specification to rely on? Or is there any other reason I don't see?

[manuel3108]

Also, just to clarify if I understood the "dangerous" part regarding adding first-class support for typescript-acorn nodes.

Yeah, that also irritates me. I don't see anything that would be dangerous about that. We could maybe consider hiding it behind a typescript flag or something, although I don't think this would be necessary.