Node.js adds native TypeScript execution

Node.js just made TypeScript feel a lot more like JavaScript. If your file only uses type annotations and other erasable syntax, Node can now run it directly — no transpile step, no extra runner, no setup dance. That change has been rolling through releases for a while, but it now covers every active Node line and has become stable in the newer ones. ### What actually changed? The short version is simple: Node has built-in “type stripping.” It reads a `.ts` file, removes TypeScript syntax that doesn’t affect runtime behavior, and executes the result. This first landed behind `--experimental-strip-types` in Node 22.6.0, then turned on by default in Node 23.6.0 and Node 22.18.0. In today’s docs for Node 26, the feature is listed.0 and v24.12.0 too. ### Which Node versions matter here? The active lines right now are v22 LTS, v24 LTS, v25 Current, and v26 Current. Node’s release page shows v22 and v24 as LTS, with v26 newly current as of May 2026. The important part is that native TypeScript execution is no longer a “future Node only” thing — it spans the versions people are actually using in production and day-to-day development. ### So can Node run all TypeScript now? No — and this is the catch. Node only supports lightweight execution for code that uses erasable TypeScript syntax. It does not do type checking. It also ignores `tsconfig.json`, which means settings like path aliases or downleveling newer syntax are intentionally out of scope. If your code needs TypeScript features that generate JavaScript, you still need a fuller toolchain. ### What counts as “lightweight”? Basically, Node is treating TypeScript like JavaScript plus annotations it can erase. That works well for scripts, CLIs, build helpers, tiny services, and prototypes. It’s the difference between peeling sticky notes off a document and rewriting the document itself — Node does the first one. The moment your setup depends on compiler behavior, project territory. ### Why does that still help so much? Because a lot of friction in TypeScript has never been about the language. It’s been about ceremony. Want to run one script? Install a runner. Wire up a config. Maybe fight module settings. Native execution cuts out that overhead for the simplest case: write `file.ts`, run `node file.ts`, move on. That’s a big quality-of-life upgrade even if it doesn’t replace the compiler. ### Why not add full TypeScript support too? Node’s docs are pretty explicit here: full TypeScript support still belongs to third-party tools. The built-in feature is intentionally lightweight. That keeps Node from chasing every TypeScript compiler option and every version-specific behavior. It also avoids turning the runtime into a second TypeScript toolchain with its own compatibility headaches. ### What should developers do now? Use native execution when you just want to run TypeScript files that don’t need transforms. Keep using `tsc`, `tsgo`, `tsx`, or similar tools when you need type checking, `tsconfig` behavior, emit control, or broader syntax support. Node even recommends modern TypeScript settings like `noEmit`, `nodenext`, and `erasableSyntaxOnly` for this lightweight path. ### Bottom line? Node didn’t “replace TypeScript tooling.” It removed the annoying part for the easy case. That’s enough to matter.