I think this + node:test makes Node.js a pretty compelling sensible default for most things now. Running things with `tsx` was such a QoL improvement when it happened, but it didn't solve everything.
Runtime type assertion at the edges is mostly solved through `zod` and tools like `ts-rest` and `trpc` makes it so much easier to do full-stack Typescript these days.
This. It's 2025 and the node ecosystem is finally usable by default!
ESM modules just work with both Node and Typescript, Node can run .ts files, and there's the a good enough test runner built in. --watch. The better built in packages - `node:fs/promises` - are nice with top-level await for easier async loops.
It took a while to convince everyone involved to just be pragmatic, but it's nice now.
This is great to hear, but perhaps comes too late for people like myself. Node.js has been by go-to platform from around 2014 until last year. But around September last year, I found myself thrust into the .NET ecosystem (due to a client project). Within a few months, I realized that it too, had finally become usable by default (unlike the last time I tried it, when it was too tightly coupled to Windows). In fact, it felt like what Node.js would be, if it had strong typing built-in, and had a good standard library that eliminated a lot of the module management and churn. I'm now finding it hard to return to Node.js.
What's the story with supporting CommonJS libraries? I've tried to update many projects to ESM multiple times over the years, and every time, I ended up backing out because it turned out that there was some important upstream library that was still CommonJS - or even if we fixed those issues, our downstream NPM consumers wouldn't be able to consume EJS. So then you have to go down this rabbit hole of dual compilation, which actually means using something other than tsc.
I can’t help but think that none of these would have happened without Deno doing it first. It was basically the pragmatic Node before Node started to get reasonable.
Watching NodeJS fill in these gaps the last 5 years or so has been great, I strongly prefer using built-in stuff as much as possible now to avoid bloating the modules and becoming dependent on a thousand random people being good-stewards of their packages.
I'm very much in favor of TS support directly in node. vitest has made it easier these days, but I've lost too much time over the years getting the balance just right when configuring test environments for .ts files.
trpc and ts-rest are a different animal in my opinion. I'm happy to use either one but won't deal with them in production. For trpc that's mainly due to the lack of owning API URLs and being able to more clearly manage deprecating old URLs gracefully.
For ts-rest I just tend to prefer owning that setup myself, usually with zod and shared typings for API request/response pairs. It also does irk me every time I import what is clearly an RPC tool named "-rest"
i switched to python a while ago. it has batteries included. i feel so much better now that i dont have to debug all the quirks of a half-baked system.
It doesn’t. The comment you’re replying to is referring to tsx, the package that lets you execute ts files, not to running files with the tsx extension.
This is great up until you get to the fact that typescript will not be accepted under node_modules [0].
That leads me to ask, what about project dependencies? I wrote a lib for my data models in typescript and I want to import that into my app in node, in typescript? Does the rule only apply to npm packages? There’s opportunity here…
I wrote a runtime in golang that runs typescript (well, JavaScript in general). The grafana folks have sobek that all they need is to add type striping. I feel like if there’s one runtime where typescript could be adopted fully and it would change the world is Node.js. No transpiler, no typescript-go, no rust (well, maybe some rust ;) just a great parser that will keep track of the source map and types in debug mode (for tracing).
Either way, kudos to the node team, contributors, for pulling in the goal posts to make the kick to launch shorter. I’m still a fan of bun, and my own runtime, but node is the standard by which we all are kinda following. I also like that the embedding api is simple and clean to use now so if you want to make an executable, you can.
"Written only in TypeScript" might put it better. If your module ships TypeScript source and a JS build as it should, then this will never affect it. Otherwise, to support stripping arbitrary modules would immediately compromise the design goal of light weight, due to the torrent of ill-founded and -formed bug reports incorrectly raised on Node that would follow. ("Don't make the maintainers' lives too miserable to continue the work" being also of course an implicit goal.)
Last actually note-worthy improvement I heard of was properly supporting import/export (although do you still need to use the .mjs hack?), but I've been out of the loop here for sometime so would be nice to know what they've added since.
Sounds like the obvious correct solution, making .cjs and .mjs obsolete - unless of course someone uses import() statements exclusively, in which case I need to ask: why?
using, memory64, undici, async local storage, ESM import improvements, type stripping, local storage / session storage, env file support, built in file watching. Those are just the ones I mainly remember. There is a lot more.
As a quick aside, “them” is an object pronoun, not a subject pronoun. The correct word you needed is “they”.
You couldn’t phrase your original question as a statement “Them have though.” That’s often a quick test for valid English grammar. With the correct pronoun, it makes more sense: “They have though.”
As another example, take this sentence: “Have you seen them though?”
“You” is the subject of that sentence, and “them” is the object.
I’m not a heavy JS/TS dev so here’s an honest question: why not use Bun and forget about node? Sure I understand that not every project is evergreen but isn’t Bun a much runtime in general? It supports TS execution from day 1, has much faster dependency resolution, better ergonomics… and I could keep going.
I know I’m just a single data point but I’ve had a lot of success migrating old node projects to bun (in fact I haven’t used node itself since Bun was made public)
Again, I might be saying something terribly stupid because JS/TS isn’t really my turf so please let me know if I’m missing something.
I've mainly worked with Node for now 8 years, and recently switched to Deno. Even that switch was hard to do; not because things don't work, but you don't know when they won't.
Node has its share of flaws, but it's the de facto baseline against which things are tested and developed. I'm somewhat more comfortable working with The Main Thing.
The JavaScript ecosystem is nightmarish enough that many developers don't want to switch to the Next Cool Thing. I think many of us have had enough fatigue caused by new build tools, new bundlers, new runtimes, etc.
As of right now, Bun is not compelling enough for the potential headaches down the line.
(Maybe there won't be any, but I've spent weeks dealing with incompatibilities caused by a single TS minor update (which should've been breaking). Days chasing after dependency problems, after missing docs, etc.)
Because Node is controlled by and maintained via the OpenJS Foundation. Bun is a venture-backed startup. That would be fine, but multiple, direct requests from me to the founder (Jared) about what the business model is (what I personally need to say "yes" or "no") have gone without response every time.
That led me to the assumption that Bun may very well be technically superior (or at least on the track to being so), but I can't bet anything significant or long-term on it. I need to know that this isn't just an exit vehicle for the founder (masquerading as a desire to fix JS server runtimes). Silence to a simple (dare I say, obvious) question doesn't bode well.
I have tried fully switching to bun repeatedly since it came out and every time I got 90% of the way there only to hit a problem that couldn't be worked around. Last I tried I was still stuck on some libraries requiring napi functions that weren't implemented in bun yet, as well an issue I forget but it was vaguely something like `opendir` silently ignoring the `recursive` option causing a huge headache.
I'm waiting patiently for bun to catch up because I would love to switch but I don't think its ready for production use in larger projects yet. Even when things work, a lot of the bun-specific functionality sounds nice at first but feels like an afterthought in practice, and the documentation is far from the quality of node.js
I agree. I've tried the Node TS and test runner features, and they are still (not yet) as good as Bun's. So for now sticking with Bun for those.
Really, in the Node ecosystem you eventually learn not to put all your eggs in one basket. Different things excel in different aspects. Here is my preferred setup for now:
Bun.js:
As a Node runtime, and for TS execution and test running. I tried lots: TSX, TS-Node, Node itself
NPM
For executing tooling scripts
PNPM
For installing dependencies. It's simply better than the rest (npm, yarn, bun) for several reasons
Biome.js
For linting (superior to every other tool I tried)
The bun test runner is definitely a lot better for testing than Node's.
But really, any test runner is beter than Node's: that thing is awful. It's like they looked at all the test runners in existence, and instead of copying what they all did, decided "let's make things harder for no apparent reason."
> I’m not a heavy JS/TS dev so here’s an honest question: why not use Bun and forget about node?
Why would you switch from runtime A to runtime B? I mean, you presented no reason at all, let alone a compelling one, to pick either one. So what leads you to believe it is a reasonable idea to waste time switching runtimes?
I dislike being on the bleeding edge for things. NodeJS is the most supported in the JS ecosystem. I find it much better to just be on the "default" option for things. You know, choose boring technology.
Is it a boring technology? I remember trying Node.js when it just came out, and I don't think all that much improved. Whole node.js always felt one step forward, two steps back. A lot of early design decisions still hurt it.
I would call it stagnated before I call it boring.
For me - it doesn't support secure and reliable dependency vendoring.
The best way to do this atm. is using (and configuring) yarn for zero-installs.
This keeps dependencies inside the codebase so that:
* Issues can be easily traced to the code that actually ran - development and deployment are the same.
* Deployment doesn't depend on package repositories.
* Deployment is secure from many kinds of attacks.
* It is possible to transparently patch packages.
* Development is only internet dependent when adding a new package.
* and the best ease-of-use - no reinstall when changing branches.
Bun is still a toddler: it's not ready for primetime.
Simple example: you know how at the command line you can type "npm run", and then type a character or two, hit tab, and the appropriate script from your `package.json` will autocomplete? And if you keep going (eg. "npm run knex") you can do the same thing to autocomplete arguments?
Bun still hasn't figured out how to do that (https://github.com/oven-sh/bun/issues/6037), even though they can all but copy NPM's (already written) completions. I really liked using bun when I played around with it (and it ran my codebase perfectly, without issue) ... but if they can't handle something as simple as Bash completions, they're clearly not ready for the big leagues.
Your indicator of technology maturity is "is there an autocomplete script for my shell" ? I have autocomplete working on any CLI app I make before it's even functional.
The best thing is that they are shipping this as "type stripping" which means that there are no sourcemaps involved, making it zero-cost in production!
Yup, I'm in the same boat. Been using Bun for a year or so, and enjoying the many quality of life improvements. I still use Node when the project requires it, but I'm actively moving them over to Bun when I can. Still it's great to see Node continues to improve in its own way, benefiting a wider audience.
One of Typescript's design goals is that removing all type-related parts of the source text should yield a valid JavaScript file. A typescript compiler does not generate code (unlike, say, PureScript).
You can run a typechecker (such as tsc) that check various properties of your code statically, relying on the type information. It is then erased.
The same applies, say, to Python: type annotations are ignored at runtime. Somehow similarly, Java's type information is also partly erased in the bytecode; in particular, all the information about parametrized types. (This is to say nothing about actual machine code.)
Agreed about TS, but Python type annotations are not ignored. They are executed as code (all type annotations are valid expressions) and the results are stored on the module/class/function object that contains the annotated variable
>so at best it saves you a transpilation pass and doesn't improve safety.
That's a bit misleading. Node being able to run TS code does not "improve safety", because that's not where the type checking happens. You can do type checking in your editor, or various other points in your toolchain.
Node being able to run TS code reduces the friction in writing TS code, which indirectly helps with type safety.
Except it doesn't. In anything serious, you have to wait for a full type check to happen before you run your TS code. Why would you run code that has not been checked yet and could throw very weird errors like undefined property access?
That just doesn't make sense. Yes, you can wait for your editor in your current open file, if you are lucky and the change in the open file doesn't break anything downstream in another file that is not yet open. In best case you have such simple code that nothing breaks, and in worst case, you have to still run it with type-checking - on top of running it in type-stripping-mode, because you got weird errors in runtime. This is a net negative.
This whole situation is there because we are trying to workaround the slow TSC. It's not a feature, it's something we actively work around. We try to whitewash now the obviously less useful "solution" of running code without its core features enabled: type checking. To me this is insane.
TypeScript never promised improving safety, maybe it’s a common misconception. But TypeScript has no runtime mode or information. You were always at the mercy of running and not ignoring the typechecker. Nothing stopped you from running ts-node or tsx on code with egregious type errors. TypeScript is more like a linter in that regard.
I think it's not fair to say that Typescript isn't about improving safety, just that the mechanism isn't the same as with other languages. Typescript had always allowed you to ignore the type checker (in fact, the default configuration will always attempt to emit compiled Javascript, even if the source Typescript has type errors). But if you run the type checker on every commit (via e.g. CI or a precommit hook), then you can be sure that the code you release is correctly typed, which will not guarantee it is safe, but makes it more likely.
I agree that it's better to think of Typescript as a linter that needs specialised annotations to work, rather than a type system like you might find in Java or Rust.
What, pray tell, would be the point of putting all that type information in there, and then have it checked (via tsc), if not for the sake of safety? What other use would this have in your opinion?
There is always a compile step (JS -> Bytecode -> Machine code). The question is only if it is visible to you or not. They could have made it totally transparent to you by fully support TS including type checking under the hood including support full TS and not this subset of it, but decided not to do so. There is nothing inherently great to have less compile steps if you are not even aware of it. See v8 how many compile and optimizations steps they have - You don't care, because you don't see it. The only problem of TS is, you will always be able to see it because of it being slow.
I think running TS without type checks is almost entirely pointless.
I'm using tsx for a project to achieve the same effect. As you said, it saves you from having to set up a build/transpilation step, which is very useful for development. Tsx has a --watch feature built in as well, which allows me to run a server from the typescript source files and automatically restart on changes. Maybe with nodemon and this new node improvement this can now done without tsx.
To check types at runtime (if that can even be done in a useful way?) it would have to be built into v8, and I suppose that would be a whole rewrite.
Yeah agreed - saying "node can execute typescript files" is a bit misleading. More accurate would be "node can find-and-replace type information with spaces from .ts files and try and executing them as if they were plain JavaScript"
I suspect this would only handle the most rudimentary and basic typescript files. Once you start using the type system more extensively I suspect this will blow-up in your face.
It's kinda a shame. What a missed opportunity to do it properly (rather than relying on third party plugins etc)
Edit: if you are just using typescript for type checking at build time (i.e. the most basic rudimentary typescript files) the sure fine this may help you. But typescript also generates JavaScript code for missing features e.g. proper class access modifiers, generics, interfaces, type aliases, enums, decorators etc etc. typescript generates JS code to handle all that, so you're going to have a bad time if node just replaces it with the space character at run time.
Just to give context here, NodeJS doesnt support enums, namespaces and class parameter properties. All of these have been described as regrets by Anders Hejsberg, and none of them prevent advanced use of the type system at all.
TypeScript 5.8 added a configuration option[1], where the compiler emits errors when using language features that result in code generation (e.g. enums). It's expected that people wanting to run TypeScript through "erase-only" transpilers will use this option.
Of course, everyone else is free to use enums, decorators, class parameters, etc., but for quick prototyping or writing simple scripts in TypeScript, Bun has been good enough for me, and I assume Node will be "good enough" as well.
> node can find-and-replace type information with spaces from .ts files and try and executing them as if they were plain JavaScript
That’s what all the other tools like ts-node and tsx do already.
I’m not sure what more are you expecting to do?
Typescript is build time type checked, there is no runtime component to TypeScript. If you want type checking you run tsc.
I think this is a great step in the right direction by node. It will save transpiration on the server and improve stack traves and whatnot.
> Once you start using the type system more extensively I suspect this will blow-up in your face.
I don’t see why. There isn’t any more runtime information in “complex”
TypeSceipt types than in simple ones. It’s all build time - see above.
> What a missed opportunity to do it properly
Please explain in more detail what “doing it properly” means to you. Including the typechecker? If so that wouldn’t make sense - they would be competing with TypeScript itself, they shouldn’t, all the “third party plugins” rely on tsc for type checking.
I have been using this feature to remove the transpilation step during development for a rather large monorepo that makes extensive use of very complex types and haven’t noticed any errors whatsoever at runtime.
You’re downplaying this quite a bit. Node being able to execute TS files slashes a lot of tooling in half, especially during development when you want to modify files and retry in quick succession.
Besides, I’m not so sure this cannot be expanded in the future to adopt validation features before stripping the type information. For now it solves some major pain points for a lot of people.
Readit News
Runtime type assertion at the edges is mostly solved through `zod` and tools like `ts-rest` and `trpc` makes it so much easier to do full-stack Typescript these days.
ESM modules just work with both Node and Typescript, Node can run .ts files, and there's the a good enough test runner built in. --watch. The better built in packages - `node:fs/promises` - are nice with top-level await for easier async loops.
It took a while to convince everyone involved to just be pragmatic, but it's nice now.
trpc and ts-rest are a different animal in my opinion. I'm happy to use either one but won't deal with them in production. For trpc that's mainly due to the lack of owning API URLs and being able to more clearly manage deprecating old URLs gracefully.
For ts-rest I just tend to prefer owning that setup myself, usually with zod and shared typings for API request/response pairs. It also does irk me every time I import what is clearly an RPC tool named "-rest"
Two types of languages...
https://github.com/privatenumber/tsx
That leads me to ask, what about project dependencies? I wrote a lib for my data models in typescript and I want to import that into my app in node, in typescript? Does the rule only apply to npm packages? There’s opportunity here…
I wrote a runtime in golang that runs typescript (well, JavaScript in general). The grafana folks have sobek that all they need is to add type striping. I feel like if there’s one runtime where typescript could be adopted fully and it would change the world is Node.js. No transpiler, no typescript-go, no rust (well, maybe some rust ;) just a great parser that will keep track of the source map and types in debug mode (for tracing).
Either way, kudos to the node team, contributors, for pulling in the goal posts to make the kick to launch shorter. I’m still a fan of bun, and my own runtime, but node is the standard by which we all are kinda following. I also like that the embedding api is simple and clean to use now so if you want to make an executable, you can.
[0] https://nodejs.org/api/typescript.html#type-stripping-in-dep...
"To discourage package authors from publishing packages written in TypeScript"
I tried to use it with private packages but that doesn't work either, apparently node doesn't even read the "private" field.
"You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility."
Still would have been nice to have this for private packages.
This makes Deno/Bun much more attractive alternatives
Last actually note-worthy improvement I heard of was properly supporting import/export (although do you still need to use the .mjs hack?), but I've been out of the loop here for sometime so would be nice to know what they've added since.
https://kashw1n.com/blog/nodejs-2025/
It doesn’t cover everything, but as an old-school Node user I found several interesting features I didn’t know about.
Syntax detection is enabled by default in v22.7.0, v20.19.0:
https://nodejs.org/api/packages.html#syntax-detection
Sounds like the obvious correct solution, making .cjs and .mjs obsolete - unless of course someone uses import() statements exclusively, in which case I need to ask: why?
And the biggest issue with Node IMO is that the standard lib still forces you to rely on endless npm dependencies.
Node is still very much stuck.
How? We have async/await file access, a async/await test runner, and even async/await sleep built in. What are you missing?
On the projects I am involved, they could even not exist, only node LTS releases matter, and the most recent projects are still node 20.
You couldn’t phrase your original question as a statement “Them have though.” That’s often a quick test for valid English grammar. With the correct pronoun, it makes more sense: “They have though.”
As another example, take this sentence: “Have you seen them though?”
“You” is the subject of that sentence, and “them” is the object.
I know I’m just a single data point but I’ve had a lot of success migrating old node projects to bun (in fact I haven’t used node itself since Bun was made public)
Again, I might be saying something terribly stupid because JS/TS isn’t really my turf so please let me know if I’m missing something.
Node has its share of flaws, but it's the de facto baseline against which things are tested and developed. I'm somewhat more comfortable working with The Main Thing.
The JavaScript ecosystem is nightmarish enough that many developers don't want to switch to the Next Cool Thing. I think many of us have had enough fatigue caused by new build tools, new bundlers, new runtimes, etc.
As of right now, Bun is not compelling enough for the potential headaches down the line.
(Maybe there won't be any, but I've spent weeks dealing with incompatibilities caused by a single TS minor update (which should've been breaking). Days chasing after dependency problems, after missing docs, etc.)
Because Node is controlled by and maintained via the OpenJS Foundation. Bun is a venture-backed startup. That would be fine, but multiple, direct requests from me to the founder (Jared) about what the business model is (what I personally need to say "yes" or "no") have gone without response every time.
That led me to the assumption that Bun may very well be technically superior (or at least on the track to being so), but I can't bet anything significant or long-term on it. I need to know that this isn't just an exit vehicle for the founder (masquerading as a desire to fix JS server runtimes). Silence to a simple (dare I say, obvious) question doesn't bode well.
localAddress on TCP connections ignored, last time I tried it its no-op
Incompatibility with Node module APIs (https://github.com/spamscanner/spamscanner wouldn't work)
EventEmitter race problems (partially worked around with https://www.npmjs.com/package/eventemitter2)
Svelte vites dev server sometimes forever freeze until I wiped node_modules and reinstalled it.
I'm waiting patiently for bun to catch up because I would love to switch but I don't think its ready for production use in larger projects yet. Even when things work, a lot of the bun-specific functionality sounds nice at first but feels like an afterthought in practice, and the documentation is far from the quality of node.js
Really, in the Node ecosystem you eventually learn not to put all your eggs in one basket. Different things excel in different aspects. Here is my preferred setup for now:
Bun.js: As a Node runtime, and for TS execution and test running. I tried lots: TSX, TS-Node, Node itself
NPM For executing tooling scripts
PNPM For installing dependencies. It's simply better than the rest (npm, yarn, bun) for several reasons
Biome.js For linting (superior to every other tool I tried)
But really, any test runner is beter than Node's: that thing is awful. It's like they looked at all the test runners in existence, and instead of copying what they all did, decided "let's make things harder for no apparent reason."
Why would you switch from runtime A to runtime B? I mean, you presented no reason at all, let alone a compelling one, to pick either one. So what leads you to believe it is a reasonable idea to waste time switching runtimes?
I dislike being on the bleeding edge for things. NodeJS is the most supported in the JS ecosystem. I find it much better to just be on the "default" option for things. You know, choose boring technology.
Is it a boring technology? I remember trying Node.js when it just came out, and I don't think all that much improved. Whole node.js always felt one step forward, two steps back. A lot of early design decisions still hurt it.
I would call it stagnated before I call it boring.
The best way to do this atm. is using (and configuring) yarn for zero-installs.
This keeps dependencies inside the codebase so that: * Issues can be easily traced to the code that actually ran - development and deployment are the same. * Deployment doesn't depend on package repositories. * Deployment is secure from many kinds of attacks. * It is possible to transparently patch packages. * Development is only internet dependent when adding a new package. * and the best ease-of-use - no reinstall when changing branches.
Simple example: you know how at the command line you can type "npm run", and then type a character or two, hit tab, and the appropriate script from your `package.json` will autocomplete? And if you keep going (eg. "npm run knex") you can do the same thing to autocomplete arguments?
Bun still hasn't figured out how to do that (https://github.com/oven-sh/bun/issues/6037), even though they can all but copy NPM's (already written) completions. I really liked using bun when I played around with it (and it ran my codebase perfectly, without issue) ... but if they can't handle something as simple as Bash completions, they're clearly not ready for the big leagues.
Not supporting type stripping in node_modules is unfortunate
Writing a library in TypeScript (with typechecks in CI/CD as devDependencies) and just importing it directly from Node.js...
It might finally be time to switch to Deno or Bun =(
Dead Comment
Dead Comment
Very well done Node team!
You can run a typechecker (such as tsc) that check various properties of your code statically, relying on the type information. It is then erased.
The same applies, say, to Python: type annotations are ignored at runtime. Somehow similarly, Java's type information is also partly erased in the bytecode; in particular, all the information about parametrized types. (This is to say nothing about actual machine code.)
Except for where it does: Enums, namespaces, parameter properties, etc.
Just for generics, I believe
That's a bit misleading. Node being able to run TS code does not "improve safety", because that's not where the type checking happens. You can do type checking in your editor, or various other points in your toolchain.
Node being able to run TS code reduces the friction in writing TS code, which indirectly helps with type safety.
That just doesn't make sense. Yes, you can wait for your editor in your current open file, if you are lucky and the change in the open file doesn't break anything downstream in another file that is not yet open. In best case you have such simple code that nothing breaks, and in worst case, you have to still run it with type-checking - on top of running it in type-stripping-mode, because you got weird errors in runtime. This is a net negative.
This whole situation is there because we are trying to workaround the slow TSC. It's not a feature, it's something we actively work around. We try to whitewash now the obviously less useful "solution" of running code without its core features enabled: type checking. To me this is insane.
I agree that it's better to think of Typescript as a linter that needs specialised annotations to work, rather than a type system like you might find in Java or Rust.
What, pray tell, would be the point of putting all that type information in there, and then have it checked (via tsc), if not for the sake of safety? What other use would this have in your opinion?
that's exactly the point--GP is pointing out that node can't do that part
I think running TS without type checks is almost entirely pointless.
To check types at runtime (if that can even be done in a useful way?) it would have to be built into v8, and I suppose that would be a whole rewrite.
https://nodejs.org/docs/latest/api/cli.html#--watch
Deleted Comment
https://dev.to/ivanzm123/dont-use-enums-in-typescript-they-a...
They added an optional flag to disable enums (and a few other features) in 5.8
https://www.totaltypescript.com/erasable-syntax-only
I suspect this would only handle the most rudimentary and basic typescript files. Once you start using the type system more extensively I suspect this will blow-up in your face.
It's kinda a shame. What a missed opportunity to do it properly (rather than relying on third party plugins etc)
Edit: if you are just using typescript for type checking at build time (i.e. the most basic rudimentary typescript files) the sure fine this may help you. But typescript also generates JavaScript code for missing features e.g. proper class access modifiers, generics, interfaces, type aliases, enums, decorators etc etc. typescript generates JS code to handle all that, so you're going to have a bad time if node just replaces it with the space character at run time.
Source: 49m 43s https://m.youtube.com/watch?v=NrEW7F2WCNA
Of course, everyone else is free to use enums, decorators, class parameters, etc., but for quick prototyping or writing simple scripts in TypeScript, Bun has been good enough for me, and I assume Node will be "good enough" as well.
[1] https://www.typescriptlang.org/docs/handbook/release-notes/t...
That’s what all the other tools like ts-node and tsx do already.
I’m not sure what more are you expecting to do?
Typescript is build time type checked, there is no runtime component to TypeScript. If you want type checking you run tsc.
I think this is a great step in the right direction by node. It will save transpiration on the server and improve stack traves and whatnot.
> Once you start using the type system more extensively I suspect this will blow-up in your face.
I don’t see why. There isn’t any more runtime information in “complex” TypeSceipt types than in simple ones. It’s all build time - see above.
> What a missed opportunity to do it properly
Please explain in more detail what “doing it properly” means to you. Including the typechecker? If so that wouldn’t make sense - they would be competing with TypeScript itself, they shouldn’t, all the “third party plugins” rely on tsc for type checking.
You’re downplaying this quite a bit. Node being able to execute TS files slashes a lot of tooling in half, especially during development when you want to modify files and retry in quick succession.
Besides, I’m not so sure this cannot be expanded in the future to adopt validation features before stripping the type information. For now it solves some major pain points for a lot of people.