1. You can define enum like `const enum A {...}` and they will not have runtime representation.
Correct, but that does not solve the other issues I pointed.
Additionally, const enums DO NOT have an associated type. That is a problem in libraries, since users cannot reuse the type definition around (it back ports to a string or a number)
const enum doesn't work when in transpileOnly mode (e.g. webpack, Parcel), and Babel treats "const enum" the same as "enum". I'd really love a non-broken const enum in TypeScript, though.
I'd love to see them out of the language. I do not have evidence/document supporting this, but I think it was ultimately a failed attempt of copying the C# feature ignoring the fact that JavaScript works differently.
Why is #3 a problem? It's a feature! Enums are a great way to enforce values to a predefined set. I don't want you to work around it with random strings. Use the enum. That's what it is there for.
1. Because they have a runtime representation, I cannot do `import type` — and I am importing the entire file (which might have a side effect). While it's still not justified (ideally importing should not do anything) the reality in JavaScript is different.
2. I can swap the enum value with a number or a string and it would still work, even if invalid. See https://www.typescriptlang.org/play?#code/KYOwrgtgBAggxgFwJY... for an example
3. On the other hand, I cannot use strings to create an Enum (https://www.typescriptlang.org/play?#code/KYOwrgtgBAygLgJwJY...) — this is the exact opposite of n. 2
4. Duplicates are possible: https://www.typescriptlang.org/play?#code/KYOwrgtgBAIghgTwPI...