If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript - it could be used solely as a type checker. This would be similar to the situation in Python, where type checkers check types and leave them intact, and the Python interpreter just ignores them.
It's interesting, though, that this approach in Python has led to several (4?) different popular type checkers, which AFAIK all use the same type hint syntax but apply different semantics. However for JavaScript, TypeScript seems to have become the one-and-only popular type checker.
In Python, I've even heard of people writing types in source code but never checking them, essentially using type hints as a more convenient syntax for comments. Support for ignoring types in Node.js would make that approach possible in JavaScript as well.
If this feature ever becomes the default (ie not behind a flag) - how will the NPM ecosystem respond? Will contributors still bother to build CJS end EJS versions when publishing a NPM module, or just slap an 'engine: nodejs >= 25' on the package.json and stop bothering with the build step before pushing to NPM ?
I personally would very much prefer if NPM modules that have their original code in TS and are currently transpiling would stop shipping dist/.cjs so I unambiguously know where to put my debugger/console.log statements. And it would probably be very tempting to NPM contributors to not have to bother with a build step anymore.
But won't this start a ripple effect through NPM where everyone will start to assume very quickly 'everyone accepts TS files' - it only takes one of your dependencies for this effect to ripple through? It seems to me that nodejs can't move this outside an opt-in-experimental-flag without the whole community implicitly expecting all consumers to accept TS files before you know it. And if they do, it will be just months before Firefox and Safari will be force to accept it too, so all JS compilers will have to discard TS type annotations
Which I would personally be happy with - we're building transcompiling steps into NPM modules that convert the ts code into js and d.ts just to support some hypothetical JS user even though we're using TS on the including side. But if node accepts .ts files we could just remove those transpiling steps without ever noticing it... so what's stopping NPM publishers from publishing js/d.ts files without noticing they broke anything?
Eventually, node might allow JS to introspect those types.
That would be a huge win. Right now in Python, great tools like pydantic exist because Python can introspect said types, and generate checks out of them.
This mean you can define simple types, and get:
- type checking - run time data check - api generation - api document generation
Out of a single, standard notation.
Right now in JS, things like zod have to do:
const mySchema = z.string();
Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`).
Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit, I can’t imagine the user experience (or performance) to match Bun’s when it reaches stable.
I really enjoy typescript and have been yearning for a typescript runtime but I can't help but laugh that I left java all those years ago to finally seek something a lot closer to java.
I guess we all just wanted java with JIT, more feature rich type system and gradual typing. Also for all the shortcomings of npm ecosystem, it is a lot less daunting and more fun to be using libraries in this ecosystem.
And surprisingly even though rust is on a different end of the language spectrum but yet it offers a similar feel.
Edit: JIT was not the right terminology to use. I lazily wrote JIT. Apologies. What I meant to convey was the difference in startup times and run time between running something in JVM and V8. Java feels heavy but in javascript ecosystem it feels so nimble.
My favorite deno feature is coming to node directly. Awesome!
Maybe this means I don't always have to install esbuild to strip types - very excited how this will make writing scripts in TypeScript that much easier to use. I lately have been prefering Python for one off scripts, but I do think personally TypeScript > Python wrt types. And larger scripts really benefit from types especially when looking at them again after a few months.
It's been a really eventful month for Node. First they added node:sqlite in v22.5.0, and now TypeScript support is landing. I love the direction Node is heading in.
Hi I'm the author of the PR, AMA
A long time ago I started converted to using node js for backend work, seemed to offer many benefits over writing code in PHP without bringing many problems of Java. I found node to be somewhat clunky and a language where you had to bolt it together to get the language you wanted. Eventually started writing golang and it felt much easier to write, sometimes way more verbose but the type safety just made coding simpler.
Typescript seemed like a good option but was just another bolt on, I am not sure what value you gain by using Typescript over Golang, you have nice defined types which is great but it does not solve other issues with the language that are resolved in golang (also solved in deno).
One large benefit of using node over golang is the speed of prototyping something which I think having to use type script largely negates, so I can not really decide if this is a good step forwards or is making node loose some qualities that made it a good choice in other ways.
I beg of thee, do not do this. I get that people love typescript but I am already running into a problem where javascript resources are written in typescript by default with nothing for regular javascript. This is the same problem that happened when JQuery hit its peak popularity and an overwhelming amount of resources and guides amounted to "Oh just do this in JQuery"
Simply amazing!
I wonder bun and deno support for typescript played a big role here :)
Nice to see Node.js getting parity on this with Deno and Bun
I'm honestly giddy. This could be the (slow) beginning of a new era, where "JS with types" is finally a native thing.
I'm even willing to forgive all the mess that CJS vs. ESM is if they manage to pull this off.
I hope this sees widespread adoption/usage, which might finally cause some movement to integrate TS into ecmascript after all. Some dynamically-typed language fanatics (which are, in my opinion, completely detached from the reality that static types are what the vast majority of devs want) still have an iron grip on TC39, this might be the start of their end. And good riddance.
It's interesting how TypeScript beat Flow in terms of popularity, and yet everyone is now calling for TypeScript to be more like Flow (to focus on plain type checking instead of transpilation; just strip out the type annotations)... And most of those people don't even know about the existence of Flow.
The sad thing about the tech sector is that you can be right about something and yet still lose the hype-wagon popularity contest. Then your competitor copies your original idea... The exact same idea which they had previously claimed was inferior.
It seems that the idea was inferior purely on the basis that it wasn't their idea. As soon as they've appropriated the idea, suddenly it's the best idea in the world.
It's about time for TC39 and Microsoft to standardize TypeScript as part of JavaScript. Not "types as comments" either, but actually TypeScript, minus the non-standard runtime semantics and modulo whatever changes are necessary to integrate the grammar.
So many runtimes and tools are integrating TypeScript now, and with multiple implementations, that a real standard is necessary. It'll be much harder to evolve TypeScript because it'll have to stay backwards compatible, but it's grown to that point now, imo.
I just switched to Bun for typescript support, a free bundler and better performance. Iojs flashback all over :)
support for typescript as long as you are only using it for type checking, not if you are also using features that are not supported in the javascript version you are targeting.
What next? Renaming Node.js to Node.ts?
I understand that built in TS support is very nice as provided by Bun. But I feel doing this in Node is going to take a long time.
IMAO writing (hard-coding) TypeScript is deprecated and a waste of time. With all tech available nowadays it is possible to do the entire type check automatically in the IDE, even more so now with the help of AI. It's just a matter of time when we stop hard-coding type info. Better invest time and money in getting the IDE's work better for us.
So how does this work in practice? Does it strip types and yolo trying to run or will it spit out type errors?
It would be nice for debugging if at least simple npms could just bundle their .ts files without any processing, so we could see the comments and types as they existed in the git repo. Apps can always minify them later.
(I use Deno, but also use some npms.)
I might be ignorant but wasn't there a plan to add Typescript support to the browser itself?
In which case wouldn't V8 support TS directly without needing to transpile?
I wonder how this handles import resolution.
type: module requires file extensions and does not support importing folders like most people are used to so it will not be compatible with most existing Typescript code.
Will it transform esm import syntax into require statements?
I'd prefer it break existing code to enforce correctness
I see it just strips the typings. So if I attach the debugger I'm still going to see javascript right?
I would rather raw dog JavaScript than write Typescript. Typescript is an abomination.
Side note, but IMO Typescript is too complicated. They should have stuck to a reasonably simple type system but now I see projects with incomprehensible and frankly unmaintainable typescript consisting of extremely complex generics, type conditionals, and type constraints. Basically if you aren't careful you'll find your project metaprogramming in typescript's turing complete meta language...
I feel like Deno and Bun have lit a fire under the Node team to finally modernize things people have been desperately wanting for years. Great to see!
I have mixed feelings about this. While I do use TS with Node.js today and absolutely like the concept, its type system is still far from something mature and stable like C#. We keep running into ceilings (EDIT: lack of completeness/depth, not lack of complexity) all the time, and TypeScript questions on Stack Overflow is basically a library of workarounds. Mostly bad ones. So if I worked on Node.js I would prefer it to evolve more before actually marrying and having kids with it. But at the same time, I like the direction Node.js is taking.
It just took 3 weeks to merge this? Seems really fast by Node.js standards. I assume it was discussed before the PR was opened?
Without some kind of transformation on `enum` isn't this mostly useless? `enum` is heavily used in many TypeScript code-bases.
If this means, that one day I don't need to use a bundler any longer to make a website using TypeScript, I am all for it.
So, how much slower is it than running js?
Didn't expect types to come to JavaScript like this (native or without a separate compiler), but I love the idea.
Love this. Next on my wish list road map is tail end recursion
Nice to see this, and important to stay closer to parity with Deno and Bun.
Isn't the whole idea of TS that you just convert to JS to run it
Really glad to see this
anyone know, for example where this is already done with Bun, how this impacts startup times with large applications?
NodeJS is the ChatGPT of JS.
Eventuall they add the feature something else has, and then everyone uses it again instead of the other thing.
Ok that's cool, but how about adding native support to browsers?
Oh, great, people love JavaScript. What a shock.
Is there a slippery slope? Node -> Browser
Nice, but without support for Enums, for me it's mostly useless.
One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time.
Consider for example: `foo < bar & baz > ( x )`. In TypeScript 1.5 this parsed as (foo<bar) & (baz > (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo<(bar & baz)>(x) which desugared to foo(x). I realise I’m going back in time here but it’s a nice simple example.
If you want to continue to use new TypeScript features you are going to need to keep compiling to JS, or else keep your node version up to date. For people who like to stick on node LTS releases this may be an unacceptable compromise.