TypeScript enums: use cases and alternatives

Re:TypeScript enums: use cases and alternatives by awongh on Monday January 20, 2025 @06:45AM (#42767678)

I get why people would want to push this forward in general, but except in a case down the road, many years from now, is there a real case right now for running your typescript code without compiling it?

Maybe library compatibility?

My first reaction is that this just further fractures the ecosystem, where some codebases/libraries will have TS that is required to be compiled and some will not, adding a third kind of TS/JS code that's out there.

[ Parent | on HN ]

Re:TypeScript enums: use cases and alternatives by JimDabell on Monday January 20, 2025 @07:01AM (#42767789)

> except in a case down the road, many years from now

We’re not talking about the distant future. Node shipped its first version supporting type stripping six months ago.

[ Parent | on HN ]

Re:TypeScript enums: use cases and alternatives by awongh on Monday January 20, 2025 @07:22AM (#42767958)

I'm not up to date on what people are working on, but I just mean that type stripping is probably not the final solution to a roadmap of node-typescript compatibility?

That I would imagine there are other features being proposed that will continue to develop this compatibility?

[ Parent | on HN ]

Re:TypeScript enums: use cases and alternatives by JimDabell on Monday January 20, 2025 @11:31AM (#42770255)

The difference between type stripping and implementing other behaviour is precisely what is being flagged as a problem with enums in this thread. If you only have type stripping – which is the present day situation for Node users – then using enums will break TypeScript that you would otherwise be able to execute.

[ Parent | on HN ]

Re:TypeScript enums: use cases and alternatives by mistercow on Monday January 20, 2025 @11:36AM (#42770331)

Being able to set up a node project like a web server without configuring or maintaining any build steps is pretty nice.

[ Parent | on HN ]