Comment by Stratoscope
3 hours ago
That is true only if you confine your TS code to be pure JS plus type annotations.
There are TS constructs that require compilation into equivalent JS, such as enums and namespaces.
3 hours ago
That is true only if you confine your TS code to be pure JS plus type annotations.
There are TS constructs that require compilation into equivalent JS, such as enums and namespaces.
Are there any other?
Namespaces are heavily discouraged. Some teams still use enigma but most people in the know us unions of strings.
I know the TS team regrets enums and I have not seen any plans for adding additional keywords that break type stripping.
The other one I read about was parameter properties in constructors.
And thank you for the correction! It was quite a few years ago that I used TypeScript, and I think the landscape was different then.
Making things even fuzzier in my mind, this was an Angular project, and it was hard to keep track of what was Angular and what was TypeScript.
It sounds like people these days actively avoid the parts of TypeScript that require translation into different JS code.
"fortunately" we can load swc compiled to wasm to deal with that.
absolutely nobody used those outside of a language demo. We also got --erasableSyntaxOnly last year to remove them from the language. The TS team considers them “mistakes“ for a really long time now
Thanks for the correction! It was a long time ago that I used TypeScript, and making things worse (for my memory) it was an Angular project.
So today, most people and teams avoid the parts of TS that require compilation into different JS, and --erasableSyntaxOnly lets you enforce this, right?
Exactly. There is plenty of code change however introduced by bundlers who do “bundling“, polyfill injection, minification, this kind of stuff.