Still a nifty new tool though. I wish JS would just allow type declarations at this point. It doesn't need to enforce them, just allow them like Python does. That would be amazing.
But this is just an on-the-fly transpile(natively supported). It would be much better if JavaScript would go the Python route. For that they would have to extend the EcmaScript spec (to be safe) I guess.
Just using JSDoc is imho not a good alternative. The big benefit of TypeScript is that your compiler checks this all for you. I've seen to much incomplete or wrong JSDoc in my life.. also a nightmare to maintain.
Open a js file with ts comments, and it silently converts to ts editing. Save the file and it converts ts back to js with comments before actually writing.
The tsc transpilation to lower ES versions is actually really useful when using not-so-recent Node versions. Not to mention this severely restricts TypeScript syntax to "just types" which isn't too bad but it means you now have to worry about yet another thing.
Then there's the ESM & CJS mess. You almost always want to export in both formats which will change a lot of the syntax, so this quickly falls apart for anything serious.
Just use esbuild if you want speed.
I haven’t exported CJS in half a decade. I haven’t authored CJS in a decade. You most definitely do not always want to do that.
We're shipping production real-time genomics apps in vanilla JS with no source maps.
Am I forgetting any or is it the only feature that actually generates code rather than just being extra annotation?
`const enums` (beyond enums) are especially odd. They rely on type information to emit code.
* Subsequent to their release in TypeScript, EcmaScript versions now support some of these.
Moreover, aside from namespaces and enums (which are discouraged), none of those features were incorporated into TypeScript until they were on track for inclusion into JS. They weren't taken from TypeScript and imported into JS; TypeScript took them from the ECMAScript people.
Being able to compile TypeScript by just stripping types has become a design principle of the language. For better or for worse, the TypeScript team steadfastly refuses to try to innovate on runtime language features at this point.
The problem with using strings is that nothing else uses strings (like say, your database), so you have to have this interminable roundtrip conversion between strings and integers.
JS programmers are in a bit of a bubble where using strings as enums is socially acceptable, if a C programmer saw this code
typedef struct {
const char* type;
} Animal;
If a database engineer saw this schema:
CREATE TABLE animal (
id INTEGER PRIMARY KEY,
type TEXT
)
It's way nicer to use integer enums from A to Z, because everything else has enums and people use them.
If you use plain integers instead of integer enums then the compiler has no visibility into what your tags are. So your diagnostics will be hard to read because the compiler doesn't know that 69 is AnimalType.frog
Pointing to a lower level language with a different use case doesn't justify int enums to me.
> These unsupported TypeScript features already have preferred alternatives:
> Prefix-style type assertions (<type>value) should be replaced with as-style type assertions.
Am I out of date? Does someone know something I don't?
Instead of writing, e.g. `const n = <number>someValueThatYouKnowIsANumber;`, you should write `const n = someValueThatYouKnowIsANumber as number;`
(well, really, you shouldn't write either, casts are bad. But, yknow.)
I haven't used it as I haven't had a need for it.
Node uses swc to do this. The swc implementation of blank-spacing (implemented here https://github.com/swc-project/swc/pull/9144) was inspired by the author of ts-blank-space here: https://gist.github.com/acutmore/27444a9dbfa515a10b25f0d4707.... It has just taken a little longer to release the original implementation.
JavaScript is really slow though compared to golang. For that reason I prefer esbuild for type-stripping.
Hmm...