Node.js Now Runs TypeScript Natively: The No-Build-Step Guide
One of the most quietly consequential shifts in the JavaScript world reached a milestone this summer: Node.js now runs TypeScript files directly, with no build step. As of Node.js 24 — the current Long-Term Support release in 2026 — the runtime strips the types out of a .ts file and executes it as-is. What used to require a compiler, a config file and a watch process is now just node app.ts.
This feature, called type stripping, shipped experimentally in Node.js 22.6, became the default in the 22.18 and 23.6 releases, and is now on by default in Node 24. It changes the day-to-day reality of building server-side JavaScript, and it removes one of the oldest points of friction for anyone starting a new project. Here is what actually happens, what it does and does not support, and how to decide whether to rely on it.
What "type stripping" actually means
TypeScript is JavaScript with type annotations layered on top. Traditionally you ran a compiler (tsc) that read your .ts files, checked the types, and emitted plain .js files that Node could run. Type stripping short-circuits that: Node reads your .ts file and simply erases the type syntax at load time, replacing it with whitespace, then runs the resulting JavaScript.
The key word is erases. Node is not compiling your TypeScript and it is not type-checking it. A : number annotation, an interface block, a generic parameter, an import type — all of it is stripped out and thrown away. Because the transformation is whitespace-only, source maps stay accurate and line numbers in stack traces still line up with your original file. Fast, predictable, and lossless for the parts of your code that actually execute.
The one thing it does not do: check your types
This is the single most important thing to understand before you lean on it. Type stripping gives you the ergonomics of TypeScript — write typed code, run it directly — but none of the safety. If you write const x: number = "hello", Node will happily run it, because it deleted the : number before it ever executed anything.
In practice that means you still run tsc --noEmit (or your editor's TypeScript language server, or a CI step) to actually catch type errors. Node handles running the code; a real type-checker still handles verifying it. Treat them as two separate jobs, because they are.
What works and what needs an extra flag
Type stripping covers all the "type-only" syntax that has no runtime footprint. A smaller set of TypeScript features generate real JavaScript and therefore need a full transform — enabled with --experimental-transform-types — or a traditional compiler like tsc or SWC.
| Works out of the box (stripped) | Needs transform / a compiler |
|---|---|
Type annotations (: string, : number) | enum declarations |
interface and type aliases | Constructor parameter properties (constructor(private x)) |
Generics (<T>) | namespace blocks that emit runtime code |
import type / export type | Legacy import x = require(...) aliases |
as and satisfies casts | Emitting decorator metadata |
The right-hand column is deliberately kept opt-in because those features change the shape of the emitted JavaScript rather than just deleting characters — a more invasive operation the Node team did not want to enable silently. For most modern codebases the left column is all you use anyway.
How to use it today
If you are on Node 24, there is nothing to enable — point Node at a .ts file and it runs:
- Run a file directly:
node server.ts. Nots-node, no build folder, nooutDir. - Keep a type-check step: add
tsc --noEmitto yourpackage.jsonscripts and your CI so bad types still fail the build. - Enforce strip-safe code: set
"erasableSyntaxOnly": truein yourtsconfig.json. It makes the compiler rejectenum, parameter properties and other constructs that need a full transform, so your team never accidentally writes code Node cannot strip. - Need enums anyway? Run with
node --experimental-transform-types, or compile withtsc/SWC for that project.
This is a natural fit for scripts, tooling, small services and greenfield backends. If you are commissioning or briefing that kind of work, it is one more reason a modern Node stack keeps developer time — and therefore build cost — down: less tooling to configure, fewer moving parts to break.
Where this fits in the 2026 stack
Native TypeScript is part of a broader convergence. The whole JavaScript ecosystem in 2026 is trending toward server-first rendering, compiler-driven optimisation and TypeScript as the assumed baseline rather than an add-on — the same direction we covered in the Next.js 16 and React 19 shift. Rivals such as Deno and Bun ran TypeScript natively for years; Node closing that gap removes the last big reason greenfield projects reached elsewhere for a first-class TypeScript experience.
It also plays well with how code gets written now. As more of the boilerplate is generated by AI coding tools, cutting the build-config surface area means fewer places for a generated project to go wrong on the first run. Less scaffolding, faster from git init to a running server.
The takeaway
Node.js running TypeScript natively is a small feature with an outsized quality-of-life impact. It deletes an entire category of setup — transpilers, watch processes, build folders — for a large share of everyday Node work. Just remember the boundary: Node runs your TypeScript, but it does not check it. Pair native execution with a real type-check step and you get the best of both — the speed of no build step and the safety TypeScript exists to provide.
Frequently asked questions
Does Node.js type-check my TypeScript when it runs it?
No. Node strips the type syntax out and runs the resulting JavaScript without verifying anything. You still need tsc --noEmit, your editor, or a CI step to catch type errors. Node handles execution; a real type-checker handles correctness.
Which Node.js version do I need?
Type stripping shipped experimentally in Node 22.6, became default in 22.18 and 23.6, and is on by default in Node 24, the 2026 LTS release. On Node 24 you can run node file.ts with no flags.
Why won't my enum or decorator code run?
Those features generate real JavaScript rather than just adding annotations, so plain type stripping cannot handle them. Run with --experimental-transform-types, compile with tsc or SWC, or set erasableSyntaxOnly in your tsconfig to avoid them entirely.
Do I still need a bundler or ts-node?
For running server-side .ts files, no — native execution replaces ts-node for most cases. You may still want a bundler for front-end code or for producing a single optimised artifact, but for backend scripts and services Node alone is enough.
Should I use this in production?
It is stable and enabled by default in the LTS release, so yes for many workloads — provided you keep a separate type-check step in CI. For projects that rely heavily on enums, decorators or namespaces, decide up front whether to use the transform flag or a full compiler.
