Node.js 'Type Stripping' for TypeScript Now Enabled by Default

The JavaScript runtime Node.js can execute TypeScript (Microsoft's JavaScript-derived language with static typing).

But now it can do it even better, explains Marco Ippolito of the Node.js steering committee: In August 2024 Node.js introduced a new experimental feature, Type Stripping, aimed at addressing a longstanding challenge in the Node.js ecosystem: running TypeScript with no configuration. Enabled by default in Node.js v23.6.0, this feature is on its way to becoming stable.

TypeScript has reached incredible levels of popularity and has been the most requested feature in all the latest Node.js surveys. Unlike other alternatives such as CoffeeScript or Flow, which never gained similar traction, TypeScript has become a cornerstone of modern development. While it has been supported in Node.js for some time through loaders, they relied heavily on configuration and user libraries. This reliance led to inconsistencies between different loaders, making them difficult to use interchangeably. The developer experience suffered due to these inconsistencies and the extra setup required... The goal is to make development faster and simpler, eliminating the overhead of configuration while maintaining the flexibility that developers expect...

TypeScript is not just a language, it also relies on a toolchain to implement its features. The primary tool for this purpose is tsc, the TypeScript compiler CLI... Type checking is tightly coupled to the implementation of tsc, as there is no formal specification for how the language's type system should behave. This lack of a specification means that the behavior of tsc is effectively the definition of TypeScript's type system. tsc does not follow semantic versioning, so even minor updates can introduce changes to type checking that may break existing code. Transpilation, on the other hand, is a more stable process. It involves converting TypeScript code into JavaScript by removing types, transforming certain syntax constructs, and optionally "downleveling" the JavaScript to allow modern syntax to execute on older JavaScript engines. Unlike type checking, transpilation is less likely to change in breaking ways across versions of tsc. The likelihood of breaking changes is further reduced when we only consider the minimum transpilation needed to make the TypeScript code executable — and exclude downleveling of new JavaScript features not yet available in the JavaScript engine but available in TypeScript...

Node.js, before enabling it by default, introduced --experimental-strip-types. This mode allows running TypeScript files by simply stripping inline types without performing type checking or any other code transformation. This minimal technique is known as Type Stripping. By excluding type checking and traditional transpilation, the more unstable aspects of TypeScript, Node.js reduces the risk of instability and mostly sidesteps the need to track minor TypeScript updates. Moreover, this solution does not require any configuration in order to execute code... Node.js eliminates the need for source maps by replacing the removed syntax with blank spaces, ensuring that the original locations of the code and structure remain intact. It is transparent — the code that runs is the code the author wrote, minus the types...
"As this experimental feature evolves, the Node.js team will continue collaborating with the TypeScript team and the community to refine its behavior and reduce friction. You can check the roadmap for practical next steps..."

Maybe Iâ(TM)m missing something?

[smadad]

What then becomes the point of writing typescript in the first place if you are just going to strip it at runtime with no type checks? I guess you still get the benefit of type checks in your IDE, but I still feel like compiling your TS before running will continue to be the way most devs go as there are other benefits of doing so.

Re:

[machineghost]

There's still a build/compile step with most modern frameworks. If you're using React for instance, you *have* to transpile all that JSX stuff into JS, because the browser won't know what to do with all that HTML in the JS.

This is just about letting your code run *after* all the build/type check steps you've already run ... or (in a less serious project, where maybe all you care about is your IDE warnings) ... even if they haven't.

Re: Maybe Iâ(TM)m missing something?

[reanjr]

Well, for me, this means I can work with someone who wants to use TS without issue. Before this change, my Node.js code doesn't have a build step, so if someone comes in and tries to add TS to the project, they are demanding I now slow myself down by rebuilding all the time. This is unacceptable. And this is what MS wants.

And to be clear, TS doesn't enforce anything, so it's exactly the same as running it stripped through Node.js.

Re:

[Waffle Iron]

What then becomes the point of writing typescript in the first place if you are just going to strip it at runtime with no type checks?

Well, that's ultimately what any compiler does. Machine code for any mainstream CPU has no type checking.

Back to Java again

[AlanObject]

TypeScript has reached incredible levels of popularity and has been the most requested feature in all the latest Node.js surveys.

I find irony in the fact that for many years that Java was derided and dismissed for being type-strict in favor of Javascript and Python that were fully type free. I never understood the issue, except for comments like "Python doesn't insult your intelligence" by telling you what to do or something.

Now all these wonderful languages are getting layers of specification and processing added onto them that makes them fully typed-checked -- just like Java. Javascript/ECMAscript has Typescript and CoffeeScript and Python evolved conventional libraries like Typings, Pydantic and @dataclass.

Perhaps the strict approach that Java took was right to begin with, no?

Re: Back to Java again

[smadad]

Maybe. Typescript is excellent for large applications, but I still think strictly typed JS for all use cases would be overkill and a huge mistake.

Re:

[machineghost]

It's all about the tooling.

TypeScript lets Javascript code get all the benefits of Java IDEs: for instance, you can autocomplete arguments (and then have your IDE yell at you if you put the wrong type in them). Javascript itself lacks the information to do that, but virtually every major library provides it (in the form of type files).

What this amounts to is that the average JS dev *doesn't* have to use types at all, and they can still leverage all those tooling benefits. If they want those tooling benefi

Re: Back to Java again

[reanjr]

"TypeScript lets Javascript code get all the benefits of Java IDEs"

So does JSDoc, and you get it without build bloat or non-standard code.

Re:

[machineghost]

JS Doc is more limited in what it can express, so it won't be an option for everyone ... but yes, and this is just another example of:

we have the full flexibility to use whichever level of type strength we want

Re:

[mrbester]

Wait, you're comparing a OO based strictly typed language that doesn't run in the browser to a prototypal delegation based loosely typed language that does?

CoffeeScript was an abomination, BTW.

If money is on the line, types are your friends

[Somervillain]

TypeScript has reached incredible levels of popularity and has been the most requested feature in all the latest Node.js surveys.

I find irony in the fact that for many years that Java was derided and dismissed for being type-strict in favor of Javascript and Python that were fully type free. I never understood the issue, except for comments like "Python doesn't insult your intelligence" by telling you what to do or something.

Now all these wonderful languages are getting layers of specification and processing added onto them that makes them fully typed-checked -- just like Java. Javascript/ECMAscript has Typescript and CoffeeScript and Python evolved conventional libraries like Typings, Pydantic and @dataclass.

Perhaps the strict approach that Java took was right to begin with, no?

Having done massive projects in Java, Python, node.js and others...yeah, Java is the leader for a reason. It's always been fashionable to shit on Java...at least in the last 25 years...and without a doubt, there are opportunities for improvement. However, the top contenders have all been far worse and have some HORRIBLE design decisions.

If you're the only one who will ever work with it?...do what you like...node.js is fine..so is python, brainfuck, or go find something rarer like ada or fortran...no o

Re:

[Waffle Iron]

Perhaps the strict approach that Java took was right to begin with, no?

No. Look at all the slow, bloated "bean" frameworks that had to be created for Java, which all use runtime reflection in order to get around its brittle type system.

Re:

[bill_mcgonigle]

```
"Python doesn't insult your intelligence" by telling you what to do or something.
```

Except if you hit that spacebar and break your loops and stand a 5% chance of seeing it.

But a typed language with no definition of how types work? Oh, lordy.

I was surprised to hear in a lunduke video a few months back that Java complied only uses 2.5x as much cpu and energy as the same benchmarks coded in c. All of the scripting languages were 60x (Perl) worse or worse than that. 75x for python, etc.

Re:

[bussdriver]

The problem is that the majority of vocal users are not the competent or wise ones... eventually at some point the committees are run by incompetents trying to please the fool demographic. This is how stuff degrades over time. Problems solved get undone and repeated creating an endless cycle which produces new languages, fads, etc. Mistakes accumulate permanently or you become "rigid" and "old" causing the fools to migrate so they can be free to be fools. Older people get grumpy and "conservative" for good

Deno is the new Node

[Qbertino]

It fixed everything that was borked with Node and supports native TS.

I recommend Deno for anything mission critical. Node is outdated.

Divisive issue

[Going_Digital]

It seems that the debate over strict types is never going to be reconciled. Personally I would like to see TypeScript run natively in browsers and simply run.ts files with strict typing and .js without. It would give people the freedom to choose and remove the transpiring step from TS.