Hacker News new | ask | show | jobs
by chrismorgan 1608 days ago
I think you may have misunderstood the complaint, which is perfectly valid. A few paragraphs earlier:

> The downside to enums comes from how they fit into the TypeScript language. TypeScript is supposed to be JavaScript, but with static type features added. If we remove all of the types from TypeScript code, what's left should be valid JavaScript code. The formal word used in the TypeScript documentation is "type-level extension": most TypeScript features are type-level extensions to JavaScript, and they don't affect the code's runtime behavior.

And:

> Most TypeScript features work in this way, following the type-level extension rule. To get JavaScript code, the compiler simply removes the type annotations.

> Unfortunately, enums break this rule.

And then there is an explanation about why this is important: it makes life hard for tooling, especially fast tooling; for in the absence of such features, JavaScript tooling can support TypeScript with little bother, just dropping the TypeScript bits and getting equivalent JavaScript; but in the presence of such features, they have to either use tsc (slow!) or implement more TypeScript-specific stuff.

Compilation of most TypeScript features to JavaScript simply removes the TypeScript bits. Enums, however, have to be transformed, adding to the output JavaScript something that was not in the source JavaScript.

1 comments

esbuild seems to support enums fine
It doesn't support one variant of them, const enums for example. That ties you to tsc emit. Its pretty clear that if the tsc team could they would remove enums and favour literal unions.
I've just looked this up and it seems to support `const enum` just fine[0]. I remember Babel not being able to process `const enum`, since it goes across module boundaries and Babel does not.

[0]: https://github.com/evanw/esbuild/issues/128