Post

I'm very impressed with the collaboration we've seen from TypeScript to make Node integration a success. It is a team effort with all participants leaning in. Extension rewriting in TS 5.7 is the first treat. This was directly motivated by the Node use-case. And there's more to come! 💙

Honestly the only change to TS that has made me cringe and think through the use-cases. I'm *very* torn to put it safely.

This is a move that makes it feel like TS is it's own language when it reality it's a superset of JS designed as a superset to work with types stripped off the syntax. Imports are no longer required to be valid for the environment you are authoring.

If this is the direction it's taking, either knowingly or accidentally, another TS / Flow will emerge. I don't want it to, but watch it happen.

I get it. The rewriting is a semi-complex runtime transform with a runtime helper. One motive is to promote npm packages publishing *.d.ts files. Another is to facilitate maintaining *.js as the executable format for publishing. @searyanc.dev did not merge it accidentally.

I'll have to search through the issues and read through the thought process that lead to the change in opinion from the team.

In short, Node.js started being able to execute TypeScript directly, and we did not want to leave users in a postion where they couldn't publish their TypeScript code without converting all of their code back to JS extension imports that may or may not be exectuable as TS.

I guess I don't understand why node didn't just update the resolution algo to pretend it's JS code like every single TS loader implementation does.

To be clear, I don't have a horse in this race. It just feels weird and I don't like the way node approached this and the fact they're (potentially bad?) decisions are making their way into tooling so quickly.

"Write your TS code as if it were JS and being transpired to the same location on disk" has been my approach to anything that isn't fed through a bundler for the last 2 years. All the code I've written in that time can't just be ran with the new node imp.

A flag which bans TS features with runtime emit (enums, namespaces, experimental decorators, etc) will come in 5.8 to help people executing TS code via Node.js (or who want to avoid using those features for "reasons").

I like that this flag is comming! Kind of like strict typescript It will also mean having a flag to disable ts enums and that's a win too

I mean, strict TypeScript already exists 😅 I'm always surprised how many people want to disable these features given how widespread they are used... Would we add them today if they didn't exist? No, probably not, but they are here today... Just a challenge if TC39 ever adds conflicting features.

@mary.my.id heavy signal to just stop using const enums already

this is so sad

Do you have a name for this subset of TS without runtime features? The ts-blank-space project calls it “Modern TypeScript”, a bold choice. Also could get confusing as TS evolves.

At Agoric we’ve been calling it “erasable TypeScript” because it’s the set of features that can be erased from the source code and it will still run in an ES environment.