[kbenson]

This doesn't seem all that odd. I read this as a temporary solution to the fact that there's some real problems that TypeScript causes for the way their project is laid out and used with regard to certain types of introspection (noting duplicate classes) and performance (it's damn slow).

It's like them running the TypeScript compiler to generate one large JS file and using that intermediate as what people build against instead of the original TypeScript source. I'm not sure if this is what they're actually doing (or if they're somewhat manually doing the equivalent of it), but as a hopefully short-term workaround that allows them to solve the problems, that doesn't seem too bad (but it does possibly highlight some TypeScript problems).

Even if they actually move to a large core JS file that is the active development target, as long as they keep track of the TypeScript specifics (and don't code themselves into a corner assuming something works that they find much later errors), it may not necessarily be hard to go back to TypeScript from that (possibly with a lot of it automated with a lot of structured comments).

[esprehn]

Part of what's slow is that they're type checking and compiling the code at the same time. Best practice for a project of this size would be to run type checking as a unit test and only transpile during the build. An incremental type check is also super fast, it's possible they don't have caching setup.

To me this reads more like a list of issues in the deno architecture, and how they integrated TypeScript, than any issue with TypeScript itself.