After years of community requests, Node.js 24 ships with an experimental flag that changes the TypeScript game: --experimental-strip-types. This feature allows you to execute .ts files directly without any build step. But before you remove TypeScript from your CI pipeline, let's understand what's actually happening under the hood and whether this is suitable for production workloads.

How Native TypeScript Stripping Works

Node.js does NOT compile TypeScript to JavaScript. Instead, the VM's parser identifies type annotations, interfaces, enums, and other TypeScript-specific syntax, then safely ignores them while preserving runtime code. This is similar to how Babel's TypeScript preset works, but implemented natively in C++ for maximum performance.

The process happens entirely in memory — no .js files are written to disk. Node.js parses the TypeScript source, strips types, generates bytecode, and executes. This approach is intentionally limited: no type checking, no declaration file generation, no JSX, and no tsconfig.json support.

What Works and What Doesn't

✅ Fully supported:

• Type annotations (: string, : number)
• Interfaces and type aliases
• as type assertions
• ! non-null assertion operator
• enum (converted to object lookups)
• namespace (limited support)

❌ Not supported (throws errors):

• JSX/TSX syntax (use .jsx files with React instead)
• const enum (requires full compilation)
• export = and import = require() syntax
• Decorators (Stage 3 proposal, not stable)

Real-World Performance Comparison

We benchmarked a typical Express API with 50 endpoints and 30 TypeScript files:

# Using ts-node (traditional)
$ time node --loader ts-node/esm server.ts
Startup time: 2.4 seconds
Memory: 180MB
Using Node.js 24 native stripping
$ time node --experimental-strip-types server.ts
Startup time: 0.8 seconds
Memory: 95MB
Using pre-compiled JavaScript (build + run)
$ tsc && node dist/server.js
Startup time: 0.3 seconds
Memory: 88MB

Native stripping is 3x faster than ts-node and 60% more memory efficient, but still slower than pre-compiled JavaScript. For development, this is a game-changer. For production, pre-compilation remains optimal.

Production Considerations

Should you use native TypeScript stripping in production? Generally, no. Here's why:

• No type safety: Type errors become runtime errors. You lose the primary benefit of TypeScript.
• Debugging complexity: Stack traces refer to .ts lines, but source map support is experimental.
• Performance overhead: Parsing and stripping types on every server restart adds latency.
• Missing ecosystem tools: tsc provides declaration files, path mapping, and project references.

Recommended approach: Use native stripping for development, scripts, and REPL experimentation. For production, maintain your existing tsc build pipeline.

Migration Path for Existing Projects

You don't need to change your project structure. Add this npm script for rapid prototyping:

{
  "scripts": {
    "dev": "node --experimental-strip-types --watch src/index.ts",
    "build": "tsc",
    "start": "node dist/index.js"
  }
}

For new projects starting from scratch, consider a hybrid approach: write modules using native stripping for internal scripts, but compile public APIs for distribution.

Common Mistakes to Avoid

Mistake #1: Using const enum expecting native support. const enum requires full compilation — stick to regular enum or union types.

Mistake #2: Forgetting the flag. Without --experimental-strip-types, Node.js treats .ts files as CommonJS and fails with syntax errors.

Mistake #3: Importing .js files from .ts without extensions. Node.js still requires file extensions in ESM, even with TypeScript.

Conclusion

Native TypeScript support in Node.js 24 is a monumental step forward, but it's not a replacement for tsc in production. Use it to accelerate development workflows, eliminate ts-node from your toolchain, and reduce context switching. As the feature matures (expected stable in Node.js 26), we may see broader production adoption. For now, embrace it as a powerful development tool while keeping your build pipeline intact.