Other than a bundler, Node already has all of these. Different test runner syntax maybe but otherwise TS "just works" out of the box and their built in test runner is totally capable. Not sure I see the need for such a lament over Bun.
Additionally, Bun's push for covering as much of the Node API as possible has pushed Deno towards the same level of compatibility, and now most code is basically runtime agnostic. I'm not sure if I'll ever actually use Bun in production, but I'm glad it exists because the JavaScript ecosystem has been much improved simply due to its existence.
Node didn't have all of these features when I initially went down the path of choosing Bun, so I have a number of existing projects that have Bun baked into them.
Is there anything else that doesn't run as valid JS if you strip the types (and maybe some other extra keywords)out?
Genuine question, in my head there's not much, but TS has a few weird corners I maybe haven't used
I'm using it in my projects with no issues.
Outside of that I’ve barely seen them used in typescript, they’re not really idiomatic in react projects
Now that we have `satisfies` and `as const`, there's really no reason to ever use an enum. In my opinion, TypeScript is best when it is simply used as Language Server, and it should never have had runtime implications in the first place.
`node --experimental-transform-types example.ts`
As for whether this matches your definition of "native support" or not...
IIRC they "almost" recommend against using them (the last part, I haven't researched again now).
But the usage of many features has reached a sort of point of no return, so I hope Node will go the route of making the experimental transpilation the default for TS files at some point.
Goes to show how strong the appeal of syntax is, especially enums.
To people coming from languages with enum support, it just looks so much more organized to use them, compared to union types, despite all of the (many) drawbacks.