Node.js 24 Native TypeScript: Run .ts Files Without a Build Step in 2026

You know the drill. You've got a TypeScript project, write your .ts file, and then realize you need to add ts-node, configure tsconfig, maybe install tsx just to run a single script. In 2026, that entire ceremony is optional — Node.js 24 ships with native TypeScript support, and it's now stable. Let's break down what it actually does, what it doesn't, and whether you should care.

What Is Type Stripping?

Type stripping is exactly what it sounds like. When you run a .ts file with Node.js 24, it strips out all TypeScript type annotations before executing. No compilation. No JavaScript output files. Just execution.

Node.js reads your TypeScript, removes the annotations, and runs the raw JavaScript underneath. It does NOT check your types — that's still tsc's job. But it means you can go from zero to running TypeScript in seconds, with zero tooling overhead.

How to Get Started

First, make sure you're on Node.js 22.6+ (where type stripping landed as experimental) or Node.js 24+ (where it graduated to stable). Check your version:

node --version
# v24.0.0

Now just run your .ts file directly — no flags needed:

node server.ts

That's it. No ts-node install. No tsconfig.json required. No build pipeline. Here's a quick example:

// greet.ts
function greet(name: string): string {
  return `Hello, ${name}!`;
}

console.log(greet("world"));
// Output: Hello, world!

Run it with node greet.ts and it just works. Node.js 24, zero extra packages.

What Type Stripping Does — and Doesn't — Do

Here's the important part: type stripping is not compilation. Node.js is not running tsc under the hood.

What it does:

• Removes type annotations, interfaces, and type-only imports

• Lets you execute .ts files directly with node

• Works with zero config — no tsconfig.json needed to run

• Has zero runtime overhead — it's just string removal before execution

What it does NOT do:

• Type check — Node.js won't tell you if your types are wrong

• Support const enum with cross-file inlining or TypeScript namespace syntax

• Handle path aliases from tsconfig.json (e.g., @/utils/...)

• Support .tsx files natively (JSX transform is a separate concern)

Bottom line: still run tsc --noEmit in your CI pipeline to catch type errors. Type stripping just makes the dev loop dramatically faster.

Watch Mode + TypeScript: Your New Dev Loop

Here's the combo that genuinely changes how you work. Node.js has built-in watch mode, and it plays perfectly with native TypeScript:

node --watch server.ts

No nodemon. No ts-node/nodemon combo. No extra config. Your server restarts on save, TypeScript just works, and you didn't install a single extra package. This alone is worth knowing about in 2026.

What About ts-node and tsx?

Fair question — does this replace ts-node or tsx? Partially.

For scripts, CLIs, quick prototypes, or dev-time tooling, native Node.js type stripping is excellent. Zero deps, zero config, zero friction.

You might still want ts-node or tsx if you rely on:

• Path aliases (e.g., @/components, ~/utils) from tsconfig.json

• Decorator-heavy frameworks like NestJS with experimentalDecorators

• const enum values inlined across file boundaries

But for the large category of projects where ts-node was used purely as a convenience layer, native type stripping is a clean, zero-dep replacement in Node.js 24.

npm Scripts Setup

Here's how your package.json scripts section looks with native TypeScript in 2026:

{
  "scripts": {
    "start": "node server.ts",
    "dev": "node --watch server.ts",
    "typecheck": "tsc --noEmit"
  }
}

Notice the separate typecheck script. Run that in CI to catch type errors — the runtime won't do it for you, so you need an explicit check in your pipeline.

Should You Remove Your Build Step?

Honest answer: probably not for production web apps targeting browsers, but maybe for everything else.

You still need a build step for:

• Browser bundles (browsers don't strip types)

• Tree shaking and minification for production

• Publishing npm packages (distribute .js, not .ts)

• Production cold-start performance optimization

But for backend Node.js services, internal tools, CLIs, and dev scripts? Removing the build step is now a completely legitimate choice in 2026, and you don't need to justify it.

TL;DR

• Node.js 24 runs .ts files natively via type stripping — no ts-node, no tsx, no tsconfig required

• It strips types but does NOT check them — still run tsc --noEmit in CI

• Use node --watch file.ts for a seamless, zero-dep dev loop

• Best for scripts, CLIs, and backend services; keep a build step for browser bundles and npm packages

• Stable in Node.js 24+ — not experimental anymore. Open a terminal and try it right now.