869: Node + TypeScript in 2025

Scott and Wes explore the experimental world of running TypeScript in Node, breaking down the differences between type stripping and compiling. They cover the pros, cons, and quirks of the current implementation, plus explore tools like tsx, ts-node, and even alternatives like Deno. Show Notes 00:00 Welcome to Syntax! 00:41 Brought to you by Sentry.io. 01:29 Running TypeScript in Node. 01:45 Experimental Type Stripping. 03:17 TypeScript refresher. 04:05 TypeScript can be compiled and/or Type Stripped. 05:09 Current Node implementation is only type stripping. 05:40 Limitations of no compiling. 05:57 Enums. 08:30 Other issues. 08:35 Parameter properties. 09:20 Experimental transform types. 10:01 Importing types with type keyword. 11:17 No need for sourcemaps. 11:42 No dependencies. 13:08 Other tools. 13:25 tsx. 14:28 ts-node. 14:44 JSDoc. 16:30 Deno and Bun. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax on this Monday, Hasty Treat. We're going to be talking about Node and TypeScript, or should I say TypeScript in Node. How can you use TypeScript with Node? What are the various ways with the new stuff?

• 0:16Wes Bos?

  Yeah.

• 0:17Scott Tolinski?

  There's a lot here. So my name is Scott Talinsky. I'm a developer from Denver. With me as always is Wes Boss. What's up?

• 0:23Wes Bos?

  Hey, excited about TypeScript being much easier in Node now. So we're going to explain sort of what that means and what the downsides and upsides are to this, as well as a bunch of other tools. And we'll, of course, talk about Dino and Bun as well.

• 0:39Scott Tolinski?

  The implications, if you will. The implications, though, of you writing code are that it's going to break. And if your code breaks, well, you need a tool like Sentry on your side to help you fix it. But more than just breaking, if your code is slow, maybe your code's stinky. Who knows? Sentry will help with most of those things. It will not help if your code is physically stinky. If there's code smell, it might help there. But if you want to check it out, head on over to sentry.io/synthesis. Sign up and get two months for free with the coupon code HASTYTREAT and make better stuff. I mean, that's really the end all be all of it is that Sentry just really helps you, enables you to make better stuff all the time. So check it out.

• 1:29Scott Tolinski?

  So you want to run TypeScript in Node. What do you do? Do you fire up TSC, create a TS config and compile down every time you make a change? What do you do, Wes?

• 1:43Wes Bos?

  Yes, so Node, a couple of months ago, rolled out experimental type stripping support. And in Node 23.6, so just at the time you're listening, a couple of weeks ago, they unflagged that, meaning that TypeScript can be run in Node without a flag right now. It's still considered experimental, but we're going to talk about what that means and whatnot. But this is, this is pretty huge because it means a whole class of tools and how we write TypeScript may be going away, which is, is pretty exciting that it's going to be sort of a first-class citizen.

• 2:23Scott Tolinski?

  It's very exciting. Yes, especially because I don't know about you, but the TS config to me, as far as configs go, it's one of those ones where like, I just tweak it until it works or until it does what I want it to do. I'm not like fully versed on every single op. There is too many options and too much variety. They do too many different things. If I don't have to get into my TS config to run TypeScript code and you know, not have to deal with that compilation step, then yeah, I'm going to do that.

• 2:57Wes Bos?

  Yeah, Dino actually runs TypeScript as well with not needing a TS config, which is really nice when you just want to do something very quickly. I still recommend you have a TS config for most of your projects because there's lots of good stuff in there in terms of both how it's compiled as well as different rules for your editor. So let's start with a refresher. TypeScript is JavaScript with some type information sprinkled on top. So basically you're just adding information about the shape of your functions and your objects and your data and how things can be passed to each other. And JavaScript engines

• 3:35Wes Bos?

  don't understand TypeScript. They understand JavaScript. So in order for a JavaScript engine, whether that is your browser with like a V8 in Chrome or JavaScript Core, which is what runs in Safari in Bun, before it can run that, it has to either do one of two things. It has to compile your TypeScript into JavaScript, or it has to strip the types out of your TypeScript so that it will be JavaScript. So the difference between those two is that stripping types does not do any type checking. It will simply take your TypeScript and it will find the parts where

• 4:18Wes Bos?

  you added types and it will simply just take them out. In the case of Node.js, it literally replaces them with white space so that the source maps still are reflected. There is no source maps because Your TypeScript is essentially just, they just punch out all the holes of where those pieces are. Compiling TypeScript is a little bit different in that, once you have that tsconfig file, you can tell TypeScript several things in terms of how should it output it? Should it output it as common JS? Should it output it as ESM? Should it polyfill some of the features that are not available? Other things it will do is, what should it do with

• 5:00Wes Bos?

  JSX that it encounters? Should it compile it to React JSX? Should it leave it alone? Should it compile it to Preact? There's a couple of options that you have there. So, the Node JS implementation currently of TypeScript is simply type stripping, meaning that it does not do any transformation of your code, other than simply just punching out the types and replacing them with white space. So, that's exciting, because A, you can now just run node something dot TS, and it will just run that code without any intermediaries.

• 5:40Wes Bos?

  The sort of limitations of that right now is because it's not compiling your, or transforming your TypeScript, you cannot use any of the features of TypeScript that transform what your code actually looks like. So, the big ones there being enums. So, enums are kind of a weird one in TypeScript, in where it's a type, it's a way to specify possible options. So, you might have like an enum for status, you know, pending, private, published. Those convert to objects in TypeScript, and it's a bit of a weird thing. A lot of people, myself

• 6:22Wes Bos?

  included, just say, "Don't use, don't use enums at all," because they sort of cross the boundary of, from description to actual JavaScript code.

• 6:31Scott Tolinski?

  Right. It's actually being used as code. It is not a landmark. It is not a type, even though it is being used that way. I was pro enum for a while. Until I had that realization that if we are stripping the types from a file, then of course, that means that's not real code, right? You cannot use that. So that's really what took me on about it. You know, I, people might be wondering, if not ENUMS, what do you use? Well, largely string literals are one thing that is, or even just options in general.

• 7:08Wes Bos?

  Objects.

• 7:09Scott Tolinski?

  Objects, right?

• 7:09Wes Bos?

  Yeah, just an object or a map is, it compiles to an object. If you write an ENUM, compile it, it's an object at the end of the day with a bunch of keys on it. And those keys can also have values if, if you want that. So you can, if that's the case, that's just, that's just a dictionary lookup, right? And that can be an object or a map in most cases. And that's often what I'll reach for.

• 7:34Scott Tolinski?

  And now that we have as const too, you can throw an as const on the end of that object and make that pretty explicit.

• 7:41Wes Bos?

  Yeah, generate a, quickly generate a type for it or get a union of all the keys if you want. So yeah, it's, it's totally doable. Even like Dino will say, like, they have this thing called fast types. And there's like rules of things you should not use. And ENUMS is, is one of those. And plus, we also now have a, there's a proposal for adding type stripping to the JavaScript syntax, meaning that we eventually will, I bet, will have this idea where you can just run TypeScript files in the browser as well. And then the, the JavaScript browser engine will also know how to strip types out. So if you're thinking about like future compatibility of what this looks like,

• 8:23Wes Bos?

  try to avoid features that need to be compiled before they can be used. So ENUMS is probably the big one. NameSpace, legacy module, and parameter properties is also another really big one. So parameter properties in TypeScript allow you to initialize a class property in the constructor rather than having in your class, rather than having to specify the property inside of the class.

• 8:50Scott Tolinski?

  Okay.

• 8:50Wes Bos?

  Because otherwise, what you're doing when You construct a class, your constructor is full of these this dot name equals name, this dot age equals age, et cetera, et cetera. And you have all these like annoying settings. So TypeScript allows you to set both whether it's a public or private property as well as the type directly in the constructor. And then when you pass the value, it'll immediately get set on the class.

• 9:19Scott Tolinski?

  Interesting.

• 9:20Wes Bos?

  Yeah, that's, that's probably the one that I'm a bit bummed. But I'm, I'm going to say there also is work being done on Node.js called experimental transform types. So it's not that this will be this way forever, but they are working on the loader so that you will be able to use all of these features in your Node.js, which is, is great because like, if we have this thing where it's like, oh, great, we have it, but you can't use any of these features. It's always a bit of a bummer. And then people just go and use the other, the features, you know, like it's, don't make it like, like watered down. Give us all the features because at the end of the day, people are going to need these features. The other kind of gotcha is, and we've talked about this in the past, is you

• 10:05Wes Bos?

  have to import types with the type keyword. And I've, I think I've on the podcast, on the podcast saying, I've, I don't see any reason why you would need to use the type keyword. And the way that this works is if you're importing a type from a file, you can just import it just like you're importing any other export that's a variable or a function. But the other way to do it in TypeScript is you say import type podcast, and that's the, the type of podcast. So if you want to use this with Node.js, you have to use the type keyword.

• 10:41Scott Tolinski?

  I've always used the type keyword. And from my perspective, especially if you are having types that cross the server client boundary, that's when I've gotten into issues where server code is leaking into my client code without using the type annotation there in the import. So I've always used it. So.

• 11:02Wes Bos?

  I've, I've always been in the case. That don't use it, but I have been confused a few times when I'm importing something with a capital on it. Is that a class or is that a type or is it both?

• 11:13Scott Tolinski?

  It's explicit. I like it. Yeah.

• 11:14Wes Bos?

  Yeah. Yeah, I can. I could see that. So that's the sort of upsides and downsides to Node JS. There's no need for source maps. Part of why I kind of like this whole type stripping is you're not introducing a build step in the middle. The code you write is the code that is run pretty much. There's no need for source maps. So you're not getting some weird stack traces that don't make sense to you at all. One thing is they have on the website is they say is not for dependencies. So to discourage package authors from publishing packages written in TypeScript, Node will by default refuse to handle TypeScript files inside of folders under a node modules path.

• 11:57Scott Tolinski?

  That makes sense. Yeah.

• 12:00Wes Bos?

  I kind of, but also I'm so sick of having to debug compiled JavaScript where I was all this Babel crap and all these, like it's compiled to ES5 and like, I just want to, I want to run the code as it was authored. And I know that might be a pipe dream that will never hit, but wouldn't it be nice?

• 12:21Scott Tolinski?

  Oh yeah. No, I a hundred percent agree with you. I would just be concerned for, you know, people on older versions of Node, they install something. I guess you'd also publish the compiled versions as well. And then, you know, if you're in a TypeScript environment.

• 12:38Wes Bos?

  Now you're, now you're publishing the TypeScript, the ESM, the common JS, the types.

• 12:46Scott Tolinski?

  Trust me, my dream would just be you just use the file that's authored and it just imports and works. And there's no compilation. Yeah, that's, that's my dream as well.

• 12:56Wes Bos?

  But again, it's, it's not a standard. So we get it. Because like what happens when we move on from TypeScript?

• 13:03Scott Tolinski?

  What?

• 13:04Wes Bos?

  And we want the new version, you know? So.

• 13:08Wes Bos?

  Yeah, we'll see about that other tool. So that's Node, Node 23. You can start using it today. Obviously, it's still experimental. It's going to throw a little warning in your console when you run it. I think in a couple of months or whatever, we'll start to see, especially once the transformation part comes. If you're not using that, if you want to, like, I personally have a Node.js TypeScript course platform. I use TSX. So TSX is not the same thing as TSX, which is for JSX in TypeScript. TSX means TypeScript execute, and you can use it in place of Node, meaning that you just say TSX your app dot TS, and it will do the transpilation and everything for you.

• 13:53Wes Bos?

  And in my experience, this works flawlessly. I don't even, when I deploy my code to production, I don't even compile it. I simply just run TSX in production and it runs it and it works really well. It passes all the, like, one thing about using like Node mon and all these other tools is you have to figure out, how do you pass all these arguments to the node process? TSX does a fantastic job of passing the command line flags that are not for it just to the node process that is needed. So, big fan of that.

• 14:26Scott Tolinski?

  Yeah.

• 14:27Wes Bos?

  Have you used any others?

• 14:29Scott Tolinski?

  Yeah, I've used TS node, which is a fairly popular one for basically doing exactly just running TypeScript as nodes.

• 14:38Wes Bos?

  Way more popular than TSX, like five times.

• 14:41Scott Tolinski?

  Way more popular. That's the only one that I've used. I've also done straight up JS doc style typing where you're writing comments for your types instead of writing dot TS files, you're writing dot JS files. I think JS doc is a very, very

• 15:00Scott Tolinski?

  Reasonable solution to some of this stuff. That said, I still mostly opt to writing .ts files 99% of the time.

• 15:09Wes Bos?

  JSDoc is awesome. If you have an app that's not in TypeScript, you can just start writing JSDoc because VS Code will still consume.

• 15:19Scott Tolinski?

  Yes.

• 15:19Wes Bos?

  Like, a lot of people don't know this, but VS Code is built on top of TypeScript. That's, that's why VS Code is so good at JavaScript because it, it's still, even if you have a JavaScript project, it still runs everything through the TypeScript with allowJS turned on. And if you just start adding JSDoc to a lot of your functions, you'll, all of a sudden you have some nice types and that's a great way to sort of move to TypeScript without having to do a big rename of all your files.

• 15:48Scott Tolinski?

  And I, I'm going to be honest, I like JSDoc for more than just the TypeScript features. I like that you can like mark functions as deprecated and give a little context to things here and there, write a description.

• 16:01Wes Bos?

  Type an error. You, you can, one thing TypeScript can't do is you can't type what a function throws. So you have no idea what, once you catch an error from a function, you have no idea what the shape of that thing is and you have to sort of narrow it down inside of TypeScript. I really wish you could do that.

• 16:19Scott Tolinski?

  You also can't type an entire function.

• 16:22Wes Bos?

  Yes.

• 16:22Scott Tolinski?

  Yeah, where with JSDoc, you can type the inputs and outputs of a function with one, one fell swoop, which is nice.

• 16:29Wes Bos?

  Yeah, you're right. Let's talk about Dino and Bun. So Dino and Bun obviously have TypeScript built in as a first-class citizen and I think are largely responsible for Node getting this, which is really exciting. And Dino and Bun's implementation are really good. They also have JSX support, which is something that Node will not do with TypeScript because when you have JSX, TypeScript needs to understand what to do with it. And you can, like I said earlier, you can tell it to compile it to React, you can tell it to compile to Preact, you can tell it to leave it alone. There's a bunch of different options there. So Dino and Bun having JSX built in as a first-class citizen is really

• 17:13Wes Bos?

  nice, especially if you're just trying to. Mock up some templates real quick.

• 17:17Scott Tolinski?

  I love it. Yeah.

• 17:18Wes Bos?

  Yeah. And then just like Bun has a whole bunch of nice niceties around JSX and TypeScript for logging, displaying your components and whatnot.

• 17:27Scott Tolinski?

  Word. Well, do you have anything else here? Because I love where we're at with this world compared to where we were at five years ago, even two years ago, one year ago in TypeScript. It does feel like there are less foot guns. There's less in the way of just getting going. And to me, that's great for all accounts.

• 17:49Wes Bos?

  Totally. Yeah, it's it's not like a thing anymore where you need to like literally run a webpack watcher and compile and then your node process watches the output and restarts itself. And thankfully, that stuff is is a thing of the past. And every single tool I've used in the last year or two, just TypeScript first class support.

• 18:08Scott Tolinski?

  Right.

• 18:09Wes Bos?

  All right, that's it for today. Thanks for tuning in. We will catch you later.

• 18:12Scott Tolinski?

  Peace.