Geoffrey Booth

If what we ship is type stripping, then we’re essentially shipping experimental support for the [Type Annotations proposal](https://github.com/tc39/proposal-type-annotations). Which is good! I feel like that’s what _does_ make sense to...

This was discussed today in the [loaders meeting](https://github.com/nodejs/loaders/issues/207): - I think there was general agreement that type stripping (but probably not more) is something that we would like to see...

> which barely strips out the type. How can this be used to just strip types and nothing more?

> See [swc.rs/docs/references/wasm-typescript](https://swc.rs/docs/references/wasm-typescript) I saw that. What settings would I use to just strip types and nothing more? No support for enums, decorators, transpiling module import/export, etc. As in, if...

> These operations is one `typescript` set, but I can remove the enum part and/or handling code for type-only imports. > I’ll add options for them soon. What I would...

> Proposed compromise: an additional flag to enable them, like --experimental-generative-transpilation that enables enums, decorators, etc already supported. We could potentially do this, or we could push such users into...

> Why type-stripping and no transformation? I guess stability (?) as those are features without a spec (?) I guess its ok to avoid them. > Probably offer a flag...

> After some thoughts I think the higher level `requires()`/`link()` hooks that span across `resolve`/`load` make more sense than lower level `exports()`/`link()` hooks Let’s say I want to write CoffeeScript...

Something that was expressed to me about the idea of hooks threads that correspond to loader pools is that such an architecture is very complicated both to build and to...

> The current list of broken things: Can you share the issues for esmock and ava? I’ve only seen the issue for Angular.