11 ms·

Node.js is able to execute TypeScript files without additional configuration

443 points by steren 1y ago

tempodox 1y ago
It looks like this works by stripping away the type information, so at best it saves you a transpilation pass and doesn't improve safety.
- medv 1y ago
  Exactly! Type checking can be long and costly.
  - deleted 1y ago
    [deleted]
  - akkad33 1y ago
    Ocaml does it fast
- resonious 1y ago
  Not needing a separate compile step just to run some script sounds great to me. I will run tsc if I want a type check.
  - primering 1y ago
    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.
    - resonious 1y ago
      The point is I don't have to deal with the index.js blob that gets produced by running the compile step myself. Worse yet the source maps. It's significantly less steps so pretty helpful I'd say.
- mattlondon 1y ago
  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.
  - koito17 1y ago
    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. [1] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-8.html#the---erasablesyntaxonly-option https://www.typescriptlang.org/docs/handbook/release-notes/t...
  - sdfhbdf 1y ago
    > 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.
- ryuuseijin 1y ago
  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.
  - insin 1y ago
    Node has had a built-in --watch flag for a while too: https://nodejs.org/docs/latest/api/cli.html#--watch https://nodejs.org/docs/latest/api/cli.html#--watch
    - linhns 1y ago
      Surprisingly this gone unheralded.
- lbltavares 1y ago
  Yes, it can't parse enums, for example.
  - dust42 1y ago
    It is available behind an experimental flag: --experimental-transform-types
  - beart 1y ago
    I think enums are on their way out, and erasable syntax is one of the main reasons. https://dev.to/ivanzm123/dont-use-enums-in-typescript-they-are-very-dangerous-57bh 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 https://www.totaltypescript.com/erasable-syntax-only
- sdfhbdf 1y ago
  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.
  - MrJohz 1y ago
    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.
  - tkzed49 1y ago
    > TypeScript is more like a linter that's exactly the point--GP is pointing out that node can't do that part
    - madeofpalk 1y ago
      Which is why the title is "Node can now execute Typescript files" and not lint, check, or even run TypeScript files.
      - ohmahjong 1y ago
        I'm not sure what the distinction between "execute" and "run" is; is there a difference?
        JoBrad 1y ago
        Node is just inline transpiling the TS into JS, then running the JS.
- nine_k 1y ago
  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.)
  - 9rx 1y ago
    > A typescript compiler does not generate code Except for where it does: Enums, namespaces, parameter properties, etc.
    - mirekrusin 1y ago
      Just use erasableSyntaxOnly = true and you're fine.
      - mmmmbbbhb 1y ago
        Hadn't heard of that. Thanks
    - MrJohz 1y ago
      This is true but these are also old features, and the TS team have stated that they will not add any more features like those, and to a certain extent regret adding them initially (particularly decorators, which iirc were added because the Angular framework wanted to use them). You can also see that these features aren't really being updated to match recent Typescript developments (parameter properties can't do true private properties, const enums don't work with isolated modules, etc). I don't think those features are ever going to go away, because they've been around for so long and are so widely used. But I generally use erasableSyntaxOnly in new projects, because I find it's useful when my typescript source matches the generated Javascript code as much as possible.
- stevage 1y ago
  >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.
  - primering 1y ago
    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.
    - SCdF 1y ago
      You can tsc on the code and then ship that git hash if it passes. You don't need to run it every single time the code executes, nothing of value is gained, because nothing has changed.
    - MrJohz 1y ago
      This is not my experience at all. In my experience, it's often quite useful being able to run code that doesn't fully type-check, as long as I do make sure everything's correct by the time I commit it. For example, I might be refactoring a module with some tests, and make a change that breaks the tests and some code in some other module. At this point, I often go in this order: 1. See that the tests aren't type checking correctly (usually for an obvious reason like adding an extra parameter or something). 2. Fix the tests using the type hints. 3. Run the tests to make sure my refactoring made sense and didn't break anything unexpected at runtime. 4. Fix all the uses in other modules. Step 3 requires me to be able to run code that doesn't type-check correctly, and that's a useful feature. There's also similar cases where I want to see how something looks in the UI even if it's not properly hooked up yet and causing type errors - I can check that part of the UI works and that it throws the correct runtime error (equivalent to whatever error typescript has). I've also had cases where I've cast things to `unknown` because I don't want to figure out the type just yet, and then written an implementation that is filled with typescript errors but will work at runtime as a mini proof of concept, only to later go back and get the types right. I shall think you're underestimating how important fast cycle times are. When I'm developing, I normally have my linter, tsc, the dev server (tsx or vite), and the test runner all running simultaneously in watch mode. At any one point, I'm probably only interested in the output from one of these tools (the type checker until the types are all correct, then maybe the test runner until everything's green there). But if I run all of them at once, then they all run optimistically, and the tool I'm interested in is more likely to give me immediate feedback. That's really useful! Even with the new 10x typescript compiler, I'd still rather my tests start running immediately rather than waiting for another process to start and finish before they get going.
- reactordev 1y ago
  Typescript mission is to strip itself of typing, what’s your point? Typescript will never be Java, you’ll never have runtime reflection.
- rand0m4r 1y ago
  I agree, that said if the main reason people use TypeScript is security they should use a decent programming language instead.
sisve 1y ago
Impressed with what Node is doing the last years, deno and bun has really made Node focus and improve. It was stuck for a while
- mattlondon 1y ago
  What are the recent improvements in node itself? 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.
  - the_mitsuhiko 1y ago
    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.
    - franky47 1y ago
      Adding to the list: permissions, CLI styling/colouring, require(esm), globs, test runner.
  - 9dev 1y ago
    Small but lovely addition for me is the ability to load .env files natively. There’s more like this; small, focused, real-world-improving features.
    - Kriptonian 1y ago
      [dead]
  - pavlov 1y ago
    Here’s a nice overview: https://kashw1n.com/blog/nodejs-2025/ 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.
ninetyninenine 1y ago
Is there any movement in the node world for the runtime to be able to ascertain types? Obviously nodejs doesn't do this, but does Bun or Deno or are there plans for any of this in the future?
- ireadmevs 1y ago
  I believe it would be too hard to keep up with pace of TypeScript development. We should probably at some point formally define the system and allow for alternative implementations outside of the control of Microsoft.
- nosianu 1y ago
  This has nothing to do with the "node world". Such an enormous feature would have to go into ECMAScript. Which is very, very unlikely to ever happen, they may as well design a new language. All those runtimes implement that spec. Expecting them to write an extremely complex new feature that is easily more complicated than everything already implemented (especially with backwards compatibility, and given that the language was not designed for this) would be a bit much. TypeScript is for compile time checking of a language that was not designed to have them. Runtime types have very different requirements! It has to be in the language from the early design phase, otherwise it will just be a hack with many conditions, restrictions and holes. TS Types are only partially a description of the underlying types in the code, a very big part instead is that it provides guard rails that prevent you from using a lot of perfectly fine and valid JS code that would however be incompatible with type guarantees. You pay the price of using only a part of the large space of JS code possibilities for guarantees. If you were to put that into the runtime you would end up with two different versions of the language. If you still want to support the full JS you would end with two runtimes in one (or one that has so many branches and conditions that maintaining that runtime is a real beast).
  - ninetyninenine 1y ago
    Can't be too hard imo. Primitives can contain an extra metadata field for the types defined in the code. This doesn't really interfere with the runtime and will be backwards compatible. The runtime of course still doesn't actually have to do any type checking, it's just forwarding the type information on a new metadata field so it's not in any way interrupting the core flow of the runtime logic. As a result you can still have the wrong type tagged onto a primitive just like TS has it currently. Only downside I see is that It can slow down the code as the runtime now has to evaluate type level functions in order to know what to place in the metadata. But you're right in the sense that it has to go into the core ECMA specification rather then being a node project.
asgr 1y ago
Deno has sandboxing and much more - use it instead
user3939382 1y ago
I’ve been happy with JSDoc
EGreg 1y ago
Great, it does type stripping by replacing TypeScript with whitespace. Can it also now load ES5 modules? That way we can use them for everything.
- azangru 1y ago
  > Can it also now load ES5 modules? ES5 standard (released in 2009) didn't have modules.
  - EGreg 1y ago
    That answers it. I guess it still can’t! :-/
- pjmlp 1y ago
  Quite for some time, assuming they are actually ES6 modules.
yard2010 1y ago
Bun can do it for years now. I think it's time to move on.
- pinoy420 1y ago
  Bun has lots of issues and lots of incompatibilities with a lot of packages.
  - akkad33 1y ago
    What are the issues
    - rockyj 1y ago
      For one I do not want to run my startup at the mercy of VC funded tech. Node.js is open source and maintained by a foundation, it will not "run out of funds" or be abandoned if there is no profitability in the near future.
      - veidr 1y ago
        Yeah, but it's not a big bet. Deno can do it, Bun can do it, if they die a tragic VC-fueled death then somebody else (maybe Node) can do it. Using Bun to me is just like using a microwave oven in 1980 — there weren't a lot of microwavable convenience foods yet, but you could sure heat up some leftovers more conveniently and quickly.
        Imustaskforhelp 1y ago
        comparing bun to oven is one of the most clever things that I have seen. My mind is actually so impressed right now in the sense that bun is well owned by oven.sh company and what you said makes sense... Do I make sense? Seriously, I can't explain but feel a little mind blown by what you wrote.
ChrisArchitect 1y ago
Some previous discussion: https://news.ycombinator.com/item?id=44597966 https://news.ycombinator.com/item?id=44597966
coolgoose 1y ago
I still want enums
lunarcave 1y ago
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.
- madeofpalk 1y ago
  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.
  - thrown-0825 1y ago
    does it have a go fmt / lint command yet?
    - Sammi 1y ago
      npx prettier
      - thrown-0825 1y ago
        does that require a config?
        coldtea 1y ago
        depends, will you keep finding pendatic faults after any answer?
        ohmahjong 1y ago
        Having a typo in "pendantic" is a masterstroke
eashish93 1y ago
But still, bun is the winner here. I recently started using bun and now not moving to node.js again. It just works.
- christophilus 1y ago
  Node still has a better repl, but I do agree. Bun is really good. It’s my goto, too.
- lioeters 1y ago
  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.
xPaw 1y ago
I wish browsers also supported directly running typescript files.
- avinashbot 1y ago
  Someday! https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
  - primering 1y ago
    That is the real reason we get a less feature-rich TypeScript in the future and Node not supporting full TypeScript. Because they want to be supported by browser.
- camdroidw 1y ago
  Already a proposal exists, recent news
  - xPaw 1y ago
    That proposal has existed for 4 years, it hasn't gone anywhere yet.
- 38 1y ago
  [dead]
dingi 1y ago
Contrary to the popular trend, I usually stick with Node and NPM for most of my projects. That said, I’ve run into plenty of headaches with CommonJS vs ESM quirks. Sharing code between frontend and backend (via shared libraries) still feels messy because of those differences. In one project I actually had to switch to Bun as the runtime, since Node kept failing at runtime, and strangely enough, Bun just worked without issues.
gettingoverit 1y ago
Even though this should be the way to go, it still leaves a bitter taste. Remember ESM fiasco? Now we have a few years of that all over again, this time with different versions of TypeScript, settings, and tsgo. Good news!
- shoeb00m 1y ago
  This is for transpilation only. it does not actually validate the typescript or perform any checks during runtime. esm actually caused errors so there should not be any issues here
vivzkestrel 1y ago
does it support watch mode? does it support path aliases?
- wildpeaks 1y ago
  It supports the same things JS scripts can do because it's merely stripping type annotations.
yahoozoo 1y ago
What backend framework is the go to these days? Still Express?
- ricardobeat 1y ago
  Express is still popular, but a lot projects these days use a full-stack framework like Next.js, SvelteKit, etc. Fastify, NestJS (bleh), Koa, Hono are the modern replacements for express, none of them have caught on as a standard though. My personal favorite for small projects is Polka (https://github.com/lukeed/polka https://github.com/lukeed/polka), when I'm not using Go instead.
- norman784 1y ago
  IMHO the only reason you are using JS in the backend is because of some meta framework, otherwise is not worth. So at least for Nuxt is nitro, not sure for SvelteKit or the other React meta frameworks.
- hungryhobbit 1y ago
  Next is where it's at these days in my opinion. You get a full-featured client-side React framework (the only one that supports modern React SSG), and then on top of it you get a better-organized approach to doing everything you can do with Express. And do mean everything: I run an entire Postrgraphile server through Next (and you can easily do the sme with Supabase or a similar tool)!
  - r1290 1y ago
    [dead]
- deleted 1y ago
  [deleted]
fennecbutt 1y ago
Wooooo! Finally! <3
rmonvfer 1y ago
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.
- port11 1y ago
  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.)
- prmph 1y ago
  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)
  - hungryhobbit 1y ago
primering 1y ago
It's not able to execute TypeScript, but a subset of it. The claim in the title is misleading if not totally wrong. This will unfortunately drive people towards using TS only as a linter, and not use its powerful features that are inherently impossible to implement with just type stripping.
- bsimpson 1y ago
  I thought TS abandoned stuff that can't just be stripped. Besides enum, what do you use that isn't strippable?
  - chamomeal 1y ago
    I guess decorators. Which are quite powerful but I’ve never seen them used outside of libraries/frameworks that use them (angular, certain ORMs, nestjs?) As a personal taste I don’t really like decorators that much, but it’s true that nestjs projects (which is probably a majority of new backend TS projects) will not gain anything from this release. Then again, you always set nestjs up with a template anyway that has all of the tooling and building baked in. So whatevs. It’s still a huge huge win, and I finally have hope for typescript-ifying some horrible legacy node apps at work!!
    - deleted 1y ago
      [deleted]
gdorsi 1y ago
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! Very well done Node team!
prmph 1y ago
I've tried it, still doesn't work as well as Bun's Typescript and test execution capabilities. So basically just went back to Bun.
1oooqooq 1y ago
the js ecosystem is so sad. all threads saying the truth, js on the server could implement actual ts and not yet another transpiler gets downvoted. js "experts" think they are smarter because they know ts is just annotations for a linter. they don't even question why that is so and why that sucks.
rovingeye 1y ago
https://github.com/nodejs/node/issues/57215 https://github.com/nodejs/node/issues/57215 Not supporting type stripping in node_modules is unfortunate
- quectophoton 1y ago
  But... that's like half the reason why I wanted this feature... Writing a library in TypeScript (with typechecks in CI/CD as devDependencies) and just importing it directly from Node.js...
  - rovingeye 1y ago
    It was the first thing I tried and of course it didn't work. It might finally be time to switch to Deno or Bun =(
    - agrippanux 1y ago
      Bun has been awesome for me and my team fwiw
    - chamomeal 1y ago
      I switched to deno for new projects ~1 year ago and it’s only been joy. There’s a shockingly small amount of friction to switch over, and there are so so many benefits
      - throwanem 1y ago
        I'm glad you've said this. I have a project at nearly a perfect point to try out that cutover. Not that it isn't nice to understand the circa 2018-2022 TS stack, but it sure would be nice not to have to. (Our ancestors had the same discussions about cfront(1). Everything old is new again.)
      - steve_adams_86 1y ago
        I have only one issue I've encountered with Deno that mattered (so to speak) and it's probably my fault. I actually created an issue for it (https://github.com/denoland/deno/issues/30433 https://github.com/denoland/deno/issues/30433). My project config is weird (slightly more sophisticated that my repro), so, it's probably on me. Otherwise I absolutely love Deno. It makes TypeScript simple and joyful. It's the simplicity this language/tooling ecosystems badly needs in my opinion. Sometimes I feel like it makes TypeScript feel a bit more like working with Go; you can just throw a main.ts in there and build an excellent CLI from it in minutes.
reactordev 1y ago
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. [0] https://nodejs.org/api/typescript.html#type-stripping-in-dependencies https://nodejs.org/api/typescript.html#type-stripping-in-dep...
- rovingeye 1y ago
  I made the same comment here https://news.ycombinator.com/item?id=44931575 https://news.ycombinator.com/item?id=44931575 "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.
  - reactordev 1y ago
    It’s a missed opportunity for sure
  - throwanem 1y ago
    "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.)
tyleo 1y ago
I’m curious what the benefit of stuff like this is vs tsc --watch and running the JS? I’ve always just run tsc to a .gitignored’d directory and execute my JS from there. Edit: Thanks for the responses. There’s some great examples in there!
- throwanem 1y ago
  It's faster and a good bit more convenient in greenfield, in my experience. Less safe in that you do still need a type checker, but nothing about Node's stripping is at all meant for more than experimental use anyway so that's fine.
- homebrewer 1y ago
  I've been using this for helper scripts, where each script is its own entry point, to assist with various maintenance tasks in frontend projects. Much easier to clone the project and run `./scripts/frobnicate` than faff around with tsc. Previously they would have been written in pure JS or just bash.
- bastawhiz 1y ago
  It performs no type checking, and you don't need to load the compiler to compile. Tsc is a heavy package and having Node do this for you means much faster startup. As a note, Node has a built in --watch now, too
- wildpeaks 1y ago
  The benefit is one fewer step between Intellisense-enhanced development (which speeds things up with autocompletion and catches a lot of issues at design time already) and running the code, same as any linter.
adityapatadia 1y ago
This change finally helped our company move to typescript. Just converted many of services to TS and some are WIP. It’s a big win.
seniorsassycat 1y ago
Anecdotally Ive noticed a lot of packages failing to build when updating from node 20 to 22.18.0 that weren't failing with earlier node 22 versions. .18 unflagged typescript support. These are packages using ts-node or tsx to run typescript in node, and with node 22.18 they seem to be using nodes native typescript support instead, and failing due to its limited feature set, or subtly different module resolution.
seniorsassycat 1y ago
> by replacing inline types with whitespace, Node.js can run TypeScript code without the need for source maps. This is a really neat idea and I hope typescript adds this as a compiler option.
tln 1y ago
Kinda wild this default got flipped on in a minor version. For that matter the TS stripping went in a minor version too
bakkoting 1y ago
It also exposes a function which does type stripping (as `import { stripTypeScriptTypes } from 'node:module'`). This lets you build simple web apps (i.e., those with no frontend dependencies) as pure TypeScript, including the frontend, by stripping the types out from your frontend scripts as you serve them: https://github.com/bakkot/buildless-ts-webapp https://github.com/bakkot/buildless-ts-webapp
827a 1y ago
Its worth being clear that it isn't capable of actually executing TypeScript; it executes the "non-emitting" subset of the TypeScript language. If your app uses `enum`, among a couple other features, it wont work.
- lerp-io 1y ago
  supposedly you can use --experimental-transform-types to enable enums but i never tried it so idk if does const enums correctly
platevoltage 1y ago
I actually just wrote my first node app in typescript without using tsc. It was refreshing. Hopefully browsers follow.
- tills13 1y ago
  Just in time for tsc to stop sniffing the bootstrapping glue and rewrite in Go.
thrown-0825 1y ago
This would be a lot more useful in the browser, TS in node has never really been a problem for me and the config is pretty simple.

443 points by steren 1y ago

It looks like this works by stripping away the type information, so at best it saves you a transpilation pass and doesn't improve safety.

medv 1y ago
Exactly! Type checking can be long and costly.
- deleted 1y ago
  [deleted]
- akkad33 1y ago
  Ocaml does it fast
resonious 1y ago
Not needing a separate compile step just to run some script sounds great to me. I will run tsc if I want a type check.
- primering 1y ago
  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.
  - resonious 1y ago
    The point is I don't have to deal with the index.js blob that gets produced by running the compile step myself. Worse yet the source maps. It's significantly less steps so pretty helpful I'd say.
mattlondon 1y ago
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.
- koito17 1y ago
  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. [1] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-8.html#the---erasablesyntaxonly-option https://www.typescriptlang.org/docs/handbook/release-notes/t...
- sdfhbdf 1y ago
  > 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.
ryuuseijin 1y ago
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.
- insin 1y ago
  Node has had a built-in --watch flag for a while too: https://nodejs.org/docs/latest/api/cli.html#--watch https://nodejs.org/docs/latest/api/cli.html#--watch
  - linhns 1y ago
    Surprisingly this gone unheralded.
lbltavares 1y ago
Yes, it can't parse enums, for example.
- dust42 1y ago
  It is available behind an experimental flag: --experimental-transform-types
- beart 1y ago
  I think enums are on their way out, and erasable syntax is one of the main reasons. https://dev.to/ivanzm123/dont-use-enums-in-typescript-they-are-very-dangerous-57bh 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 https://www.totaltypescript.com/erasable-syntax-only
sdfhbdf 1y ago
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.
- MrJohz 1y ago
  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.
- tkzed49 1y ago
  > TypeScript is more like a linter that's exactly the point--GP is pointing out that node can't do that part
  - madeofpalk 1y ago
    Which is why the title is "Node can now execute Typescript files" and not lint, check, or even run TypeScript files.
    - ohmahjong 1y ago
      I'm not sure what the distinction between "execute" and "run" is; is there a difference?
      - JoBrad 1y ago
        Node is just inline transpiling the TS into JS, then running the JS.
nine_k 1y ago
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.)
- 9rx 1y ago
  > A typescript compiler does not generate code Except for where it does: Enums, namespaces, parameter properties, etc.
  - mirekrusin 1y ago
    Just use erasableSyntaxOnly = true and you're fine.
    - mmmmbbbhb 1y ago
      Hadn't heard of that. Thanks
  - MrJohz 1y ago
    This is true but these are also old features, and the TS team have stated that they will not add any more features like those, and to a certain extent regret adding them initially (particularly decorators, which iirc were added because the Angular framework wanted to use them). You can also see that these features aren't really being updated to match recent Typescript developments (parameter properties can't do true private properties, const enums don't work with isolated modules, etc). I don't think those features are ever going to go away, because they've been around for so long and are so widely used. But I generally use erasableSyntaxOnly in new projects, because I find it's useful when my typescript source matches the generated Javascript code as much as possible.
stevage 1y ago
>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.
- primering 1y ago
  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.
  - SCdF 1y ago
    You can tsc on the code and then ship that git hash if it passes. You don't need to run it every single time the code executes, nothing of value is gained, because nothing has changed.
  - MrJohz 1y ago
    This is not my experience at all. In my experience, it's often quite useful being able to run code that doesn't fully type-check, as long as I do make sure everything's correct by the time I commit it. For example, I might be refactoring a module with some tests, and make a change that breaks the tests and some code in some other module. At this point, I often go in this order: 1. See that the tests aren't type checking correctly (usually for an obvious reason like adding an extra parameter or something). 2. Fix the tests using the type hints. 3. Run the tests to make sure my refactoring made sense and didn't break anything unexpected at runtime. 4. Fix all the uses in other modules. Step 3 requires me to be able to run code that doesn't type-check correctly, and that's a useful feature. There's also similar cases where I want to see how something looks in the UI even if it's not properly hooked up yet and causing type errors - I can check that part of the UI works and that it throws the correct runtime error (equivalent to whatever error typescript has). I've also had cases where I've cast things to `unknown` because I don't want to figure out the type just yet, and then written an implementation that is filled with typescript errors but will work at runtime as a mini proof of concept, only to later go back and get the types right. I shall think you're underestimating how important fast cycle times are. When I'm developing, I normally have my linter, tsc, the dev server (tsx or vite), and the test runner all running simultaneously in watch mode. At any one point, I'm probably only interested in the output from one of these tools (the type checker until the types are all correct, then maybe the test runner until everything's green there). But if I run all of them at once, then they all run optimistically, and the tool I'm interested in is more likely to give me immediate feedback. That's really useful! Even with the new 10x typescript compiler, I'd still rather my tests start running immediately rather than waiting for another process to start and finish before they get going.
reactordev 1y ago
Typescript mission is to strip itself of typing, what’s your point? Typescript will never be Java, you’ll never have runtime reflection.
rand0m4r 1y ago
I agree, that said if the main reason people use TypeScript is security they should use a decent programming language instead.

sisve 1y ago

Impressed with what Node is doing the last years, deno and bun has really made Node focus and improve. It was stuck for a while

mattlondon 1y ago
What are the recent improvements in node itself? 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.
- the_mitsuhiko 1y ago
  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.
  - franky47 1y ago
    Adding to the list: permissions, CLI styling/colouring, require(esm), globs, test runner.
- 9dev 1y ago
  Small but lovely addition for me is the ability to load .env files natively. There’s more like this; small, focused, real-world-improving features.
  - Kriptonian 1y ago
    [dead]
- pavlov 1y ago
  Here’s a nice overview: https://kashw1n.com/blog/nodejs-2025/ 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.

ninetyninenine 1y ago

Is there any movement in the node world for the runtime to be able to ascertain types? Obviously nodejs doesn't do this, but does Bun or Deno or are there plans for any of this in the future?

ireadmevs 1y ago
I believe it would be too hard to keep up with pace of TypeScript development. We should probably at some point formally define the system and allow for alternative implementations outside of the control of Microsoft.
nosianu 1y ago
This has nothing to do with the "node world". Such an enormous feature would have to go into ECMAScript. Which is very, very unlikely to ever happen, they may as well design a new language. All those runtimes implement that spec. Expecting them to write an extremely complex new feature that is easily more complicated than everything already implemented (especially with backwards compatibility, and given that the language was not designed for this) would be a bit much. TypeScript is for compile time checking of a language that was not designed to have them. Runtime types have very different requirements! It has to be in the language from the early design phase, otherwise it will just be a hack with many conditions, restrictions and holes. TS Types are only partially a description of the underlying types in the code, a very big part instead is that it provides guard rails that prevent you from using a lot of perfectly fine and valid JS code that would however be incompatible with type guarantees. You pay the price of using only a part of the large space of JS code possibilities for guarantees. If you were to put that into the runtime you would end up with two different versions of the language. If you still want to support the full JS you would end with two runtimes in one (or one that has so many branches and conditions that maintaining that runtime is a real beast).
- ninetyninenine 1y ago
  Can't be too hard imo. Primitives can contain an extra metadata field for the types defined in the code. This doesn't really interfere with the runtime and will be backwards compatible. The runtime of course still doesn't actually have to do any type checking, it's just forwarding the type information on a new metadata field so it's not in any way interrupting the core flow of the runtime logic. As a result you can still have the wrong type tagged onto a primitive just like TS has it currently. Only downside I see is that It can slow down the code as the runtime now has to evaluate type level functions in order to know what to place in the metadata. But you're right in the sense that it has to go into the core ECMA specification rather then being a node project.

asgr 1y ago

Deno has sandboxing and much more - use it instead

user3939382 1y ago

I’ve been happy with JSDoc

EGreg 1y ago

Great, it does type stripping by replacing TypeScript with whitespace. Can it also now load ES5 modules? That way we can use them for everything.

azangru 1y ago
> Can it also now load ES5 modules? ES5 standard (released in 2009) didn't have modules.
- EGreg 1y ago
  That answers it. I guess it still can’t! :-/
pjmlp 1y ago
Quite for some time, assuming they are actually ES6 modules.

yard2010 1y ago

Bun can do it for years now. I think it's time to move on.

pinoy420 1y ago
Bun has lots of issues and lots of incompatibilities with a lot of packages.
- akkad33 1y ago
  What are the issues
  - rockyj 1y ago
    For one I do not want to run my startup at the mercy of VC funded tech. Node.js is open source and maintained by a foundation, it will not "run out of funds" or be abandoned if there is no profitability in the near future.
    - veidr 1y ago
      Yeah, but it's not a big bet. Deno can do it, Bun can do it, if they die a tragic VC-fueled death then somebody else (maybe Node) can do it. Using Bun to me is just like using a microwave oven in 1980 — there weren't a lot of microwavable convenience foods yet, but you could sure heat up some leftovers more conveniently and quickly.
      - Imustaskforhelp 1y ago
        comparing bun to oven is one of the most clever things that I have seen. My mind is actually so impressed right now in the sense that bun is well owned by oven.sh company and what you said makes sense... Do I make sense? Seriously, I can't explain but feel a little mind blown by what you wrote.

ChrisArchitect 1y ago

Some previous discussion: https://news.ycombinator.com/item?id=44597966 https://news.ycombinator.com/item?id=44597966

coolgoose 1y ago

I still want enums

lunarcave 1y ago

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.

madeofpalk 1y ago
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.
- thrown-0825 1y ago
  does it have a go fmt / lint command yet?
  - Sammi 1y ago
    npx prettier
    - thrown-0825 1y ago
      does that require a config?
      - coldtea 1y ago
        depends, will you keep finding pendatic faults after any answer?
        ohmahjong 1y ago
        Having a typo in "pendantic" is a masterstroke

eashish93 1y ago

But still, bun is the winner here. I recently started using bun and now not moving to node.js again. It just works.

christophilus 1y ago
Node still has a better repl, but I do agree. Bun is really good. It’s my goto, too.
lioeters 1y ago
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.

xPaw 1y ago

I wish browsers also supported directly running typescript files.

avinashbot 1y ago
Someday! https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- primering 1y ago
  That is the real reason we get a less feature-rich TypeScript in the future and Node not supporting full TypeScript. Because they want to be supported by browser.
camdroidw 1y ago
Already a proposal exists, recent news
- xPaw 1y ago
  That proposal has existed for 4 years, it hasn't gone anywhere yet.
38 1y ago
[dead]

dingi 1y ago

Contrary to the popular trend, I usually stick with Node and NPM for most of my projects. That said, I’ve run into plenty of headaches with CommonJS vs ESM quirks. Sharing code between frontend and backend (via shared libraries) still feels messy because of those differences. In one project I actually had to switch to Bun as the runtime, since Node kept failing at runtime, and strangely enough, Bun just worked without issues.

gettingoverit 1y ago

Even though this should be the way to go, it still leaves a bitter taste. Remember ESM fiasco? Now we have a few years of that all over again, this time with different versions of TypeScript, settings, and tsgo. Good news!

shoeb00m 1y ago
This is for transpilation only. it does not actually validate the typescript or perform any checks during runtime. esm actually caused errors so there should not be any issues here

vivzkestrel 1y ago

does it support watch mode? does it support path aliases?

wildpeaks 1y ago
It supports the same things JS scripts can do because it's merely stripping type annotations.

yahoozoo 1y ago

What backend framework is the go to these days? Still Express?

ricardobeat 1y ago
Express is still popular, but a lot projects these days use a full-stack framework like Next.js, SvelteKit, etc. Fastify, NestJS (bleh), Koa, Hono are the modern replacements for express, none of them have caught on as a standard though. My personal favorite for small projects is Polka (https://github.com/lukeed/polka https://github.com/lukeed/polka), when I'm not using Go instead.
norman784 1y ago
IMHO the only reason you are using JS in the backend is because of some meta framework, otherwise is not worth. So at least for Nuxt is nitro, not sure for SvelteKit or the other React meta frameworks.
hungryhobbit 1y ago
Next is where it's at these days in my opinion. You get a full-featured client-side React framework (the only one that supports modern React SSG), and then on top of it you get a better-organized approach to doing everything you can do with Express. And do mean everything: I run an entire Postrgraphile server through Next (and you can easily do the sme with Supabase or a similar tool)!
- r1290 1y ago
  [dead]
deleted 1y ago
[deleted]

fennecbutt 1y ago

Wooooo! Finally! <3

rmonvfer 1y ago

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.

port11 1y ago
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.)
prmph 1y ago
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)
- hungryhobbit 1y ago

primering 1y ago

It's not able to execute TypeScript, but a subset of it. The claim in the title is misleading if not totally wrong. This will unfortunately drive people towards using TS only as a linter, and not use its powerful features that are inherently impossible to implement with just type stripping.

bsimpson 1y ago
I thought TS abandoned stuff that can't just be stripped. Besides enum, what do you use that isn't strippable?
- chamomeal 1y ago
  I guess decorators. Which are quite powerful but I’ve never seen them used outside of libraries/frameworks that use them (angular, certain ORMs, nestjs?) As a personal taste I don’t really like decorators that much, but it’s true that nestjs projects (which is probably a majority of new backend TS projects) will not gain anything from this release. Then again, you always set nestjs up with a template anyway that has all of the tooling and building baked in. So whatevs. It’s still a huge huge win, and I finally have hope for typescript-ifying some horrible legacy node apps at work!!
  - deleted 1y ago
    [deleted]

gdorsi 1y ago

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! Very well done Node team!

prmph 1y ago

I've tried it, still doesn't work as well as Bun's Typescript and test execution capabilities. So basically just went back to Bun.

1oooqooq 1y ago

the js ecosystem is so sad. all threads saying the truth, js on the server could implement actual ts and not yet another transpiler gets downvoted. js "experts" think they are smarter because they know ts is just annotations for a linter. they don't even question why that is so and why that sucks.

rovingeye 1y ago

https://github.com/nodejs/node/issues/57215 https://github.com/nodejs/node/issues/57215 Not supporting type stripping in node_modules is unfortunate

quectophoton 1y ago
But... that's like half the reason why I wanted this feature... Writing a library in TypeScript (with typechecks in CI/CD as devDependencies) and just importing it directly from Node.js...
- rovingeye 1y ago
  It was the first thing I tried and of course it didn't work. It might finally be time to switch to Deno or Bun =(
  - agrippanux 1y ago
    Bun has been awesome for me and my team fwiw
  - chamomeal 1y ago
    I switched to deno for new projects ~1 year ago and it’s only been joy. There’s a shockingly small amount of friction to switch over, and there are so so many benefits
    - throwanem 1y ago
      I'm glad you've said this. I have a project at nearly a perfect point to try out that cutover. Not that it isn't nice to understand the circa 2018-2022 TS stack, but it sure would be nice not to have to. (Our ancestors had the same discussions about cfront(1). Everything old is new again.)
    - steve_adams_86 1y ago
      I have only one issue I've encountered with Deno that mattered (so to speak) and it's probably my fault. I actually created an issue for it (https://github.com/denoland/deno/issues/30433 https://github.com/denoland/deno/issues/30433). My project config is weird (slightly more sophisticated that my repro), so, it's probably on me. Otherwise I absolutely love Deno. It makes TypeScript simple and joyful. It's the simplicity this language/tooling ecosystems badly needs in my opinion. Sometimes I feel like it makes TypeScript feel a bit more like working with Go; you can just throw a main.ts in there and build an excellent CLI from it in minutes.

reactordev 1y ago

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. [0] https://nodejs.org/api/typescript.html#type-stripping-in-dependencies https://nodejs.org/api/typescript.html#type-stripping-in-dep...

rovingeye 1y ago
I made the same comment here https://news.ycombinator.com/item?id=44931575 https://news.ycombinator.com/item?id=44931575 "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.
- reactordev 1y ago
  It’s a missed opportunity for sure
- throwanem 1y ago
  "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.)

tyleo 1y ago

I’m curious what the benefit of stuff like this is vs tsc --watch and running the JS? I’ve always just run tsc to a .gitignored’d directory and execute my JS from there. Edit: Thanks for the responses. There’s some great examples in there!

throwanem 1y ago
It's faster and a good bit more convenient in greenfield, in my experience. Less safe in that you do still need a type checker, but nothing about Node's stripping is at all meant for more than experimental use anyway so that's fine.
homebrewer 1y ago
I've been using this for helper scripts, where each script is its own entry point, to assist with various maintenance tasks in frontend projects. Much easier to clone the project and run `./scripts/frobnicate` than faff around with tsc. Previously they would have been written in pure JS or just bash.
bastawhiz 1y ago
It performs no type checking, and you don't need to load the compiler to compile. Tsc is a heavy package and having Node do this for you means much faster startup. As a note, Node has a built in --watch now, too
wildpeaks 1y ago
The benefit is one fewer step between Intellisense-enhanced development (which speeds things up with autocompletion and catches a lot of issues at design time already) and running the code, same as any linter.

adityapatadia 1y ago

This change finally helped our company move to typescript. Just converted many of services to TS and some are WIP. It’s a big win.

seniorsassycat 1y ago

Anecdotally Ive noticed a lot of packages failing to build when updating from node 20 to 22.18.0 that weren't failing with earlier node 22 versions. .18 unflagged typescript support. These are packages using ts-node or tsx to run typescript in node, and with node 22.18 they seem to be using nodes native typescript support instead, and failing due to its limited feature set, or subtly different module resolution.

seniorsassycat 1y ago

> by replacing inline types with whitespace, Node.js can run TypeScript code without the need for source maps. This is a really neat idea and I hope typescript adds this as a compiler option.

tln 1y ago

Kinda wild this default got flipped on in a minor version. For that matter the TS stripping went in a minor version too

bakkoting 1y ago

It also exposes a function which does type stripping (as `import { stripTypeScriptTypes } from 'node:module'`). This lets you build simple web apps (i.e., those with no frontend dependencies) as pure TypeScript, including the frontend, by stripping the types out from your frontend scripts as you serve them: https://github.com/bakkot/buildless-ts-webapp https://github.com/bakkot/buildless-ts-webapp

827a 1y ago

Its worth being clear that it isn't capable of actually executing TypeScript; it executes the "non-emitting" subset of the TypeScript language. If your app uses `enum`, among a couple other features, it wont work.

lerp-io 1y ago
supposedly you can use --experimental-transform-types to enable enums but i never tried it so idk if does const enums correctly

platevoltage 1y ago

I actually just wrote my first node app in typescript without using tsc. It was refreshing. Hopefully browsers follow.

tills13 1y ago
Just in time for tsc to stop sniffing the bootstrapping glue and rewrite in Go.

thrown-0825 1y ago

This would be a lot more useful in the browser, TS in node has never really been a problem for me and the config is pretty simple.