Aw :-(
That's the bit that I'd really like to have TS macros for!
My own approach has been to loosely parse input as something like D-expressions, transform that, and pipe the result into the TS compiler. Crude but effective. The trickiest part is extending the tsserver support, but even this is doable.
https://github.com/leanprover/lean4/blob/master/tests/playgr...
I believe most of the language is defined this way, although it is pre-compiled.
For more details see the lean4 metaprogramming book: https://github.com/arthurpaulino/lean4-metaprogramming-book
Ideally, a transpiler that does not want to type check the code, should merely need to know the syntax for type related code and strip them out. This is especially true if targeting a sufficiently recent version of ECMAScript, or if the transpiler will be doing its own transformation of newer features to older ones for backward compatibility.
In practice while many typescript features can be handled like that, even some that are not strictly type features (like method accessibility modifiers), some existing features like enums needs to generate new code, although at least for that one it is an easy pattern to generate.
This is especially true of any feature that cannot be made into a trivial re-write or strip rule. Namespaces and const enums are an example of features now discouraged, as simple rewriting engines cannot handle them. Indeed the whole "isolatedModules" compiler flag is specifically about making such separate simple transpilation possible, and its documentation details other scenarios that can be a problem.
The `syntax` subdirectory is (or should be!) pretty clean. The `compiler` subdirectory is, uh, functional. Please do get in touch if you have any questions.