Hacker News new | past | comments | ask | show | jobs | submit
diggan | on: TypeScript enums: use cases and alternatives
> Enums is going to make your TypeScript code not work in a future where TypeScript code can be run with Node.js or in browser when typings are added to JavaScript[1]

How is that the conclusion you reach? The proposal you link says types will be treated like comments by the runtime, so it's not about adding types that will be used in the runtime (which begs the question, why even add it? But I digress), but about adding types that other tooling can use, and the runtime can ignore.

So assuming the runtime will ignore the types, why would using enums specifically break this, compared to any other TypeScript-specific syntax?

moogly | parent | next
I banned enums in TS codebases I contributed to _over 6 years ago_ when Babel 7 w/ TS transpilation support came out, and namespaces along with old TS modules even earlier than that when moving over to JS modules.

If you ask me, both features have been de facto deprecated for ages now.

The future has been here for a while.

msoad | parent | next
The idea from the proposal is that types are used by other tools to type-check and runtimes would ignore them. It's not final yet but it's very likely that in future you can `node -e 'function foo(arg: string) {}; foo(42)'` but if your code has `enum` in it, Node.js or browser will throw an error
loading story #42767114
loading story #42767678
jakub_g | parent
https://nodejs.org/docs/latest/api/typescript.html#typescrip...

> Since Node.js is only removing inline types, any TypeScript features that involve replacing TypeScript syntax with new JavaScript syntax will error, unless the flag --experimental-transform-types is passed.

> The most prominent features that require transformation are:

> Enum > namespaces > legacy module > parameter properties

loading story #42767184