Node.js 24 LTS Deep Dive: Native TypeScript, npm 11, and Everything You Need to Know

May 20, 2025. Node.js 24 shipped. Then, in October 2025, it became an official LTS release — codename Krypton. If you’ve been following Node.js releases on autopilot, treating each one as incremental, it’s time to look more carefully. Node.js 24 is not a routine update. It changes the way you write, run, and ship backend JavaScript in ways that will be immediately visible in your daily workflow.

Three changes stand out above everything else. You can now run TypeScript files directly with node — no compiler, no build step, no extra tooling. npm 11 installs packages 65% faster than npm 9 and scans for vulnerabilities automatically. And the V8 13.6 engine underneath delivers roughly 30% better throughput than Node.js 22. Together, these aren’t just performance numbers — they eliminate real friction from the development loop.

This deep dive covers what’s new, what changed, how to migrate cleanly, and where the tradeoffs actually lie.

LTS Timeline: What “Krypton” Means for Your Planning

Understanding the support window matters for any team making infrastructure decisions. Node.js 24 LTS is on active maintenance until October 2026, with security-only maintenance extending to April 2028. If you’re still running Node.js 20, its maintenance window closes in April 2026 — so Node.js 24 is the sensible migration target now.

Native TypeScript: The Biggest Workflow Change in Years

For the past several years, running TypeScript in a Node.js project required a setup ritual: install typescript and ts-node, generate a tsconfig.json, configure path aliases, wire up the right scripts. Every new project started with this overhead. Every developer on the team had to get it right. And every CI pipeline had to include a compilation step.

Node.js 24 eliminates all of this for the common case:

# Old way: needed multiple steps
npm install -D typescript ts-node @types/node
npx tsc --init
npx ts-node src/index.ts
# Or: tsc && node dist/index.js

# Node.js 24: single command
node src/index.ts

This works through a mechanism called type-stripping. At runtime, Node.js 24 parses your TypeScript file and removes all type annotations — interfaces, type aliases, generic parameters, decorators — then executes the remaining pure JavaScript. The stripping happens in microseconds, adding effectively zero startup overhead.

Here’s a real TypeScript file running natively:

// greeting.ts — pure TypeScript
interface User {
  name: string;
  role: "admin" | "editor" | "viewer";
  joinedAt: Date;
}

function greet(user: User): string {
  const days = Math.floor(
    (Date.now() - user.joinedAt.getTime()) / (1000 * 60 * 60 * 24)
  );
  return `Hello ${user.name}! You are a ${user.role}, joined ${days} days ago.`;
}

const admin: User = {
  name: "Phuong",
  role: "admin",
  joinedAt: new Date("2024-01-15"),
};

console.log(greet(admin));
// Run: node greeting.ts

No configuration file. No build output directory. No intermediate compilation artifact. Just a TypeScript source file executed directly.

The Critical Nuance: Stripping Is Not Type-Checking

This is the most important thing to understand about Node.js 24’s TypeScript support, and it’s easy to misread. Node.js does not type-check your code. It strips types and runs. If you have a type error — a string passed where a number is expected, a property accessed on undefined — Node.js will not catch it at startup. It will surface as a runtime error, exactly as it would in plain JavaScript.

This is intentional, not an oversight. The Node.js team made a deliberate architectural decision: separate the fast path (execution) from the accurate path (validation). Running tsc to compile tens of thousands of lines can take 30 seconds or more in large codebases. That latency is unacceptable for a development inner loop. By separating the two concerns, you get instant execution during development and rigorous validation in CI.

The correct workflow looks like this:

// package.json scripts for optimal workflow
{
  "scripts": {
    "dev": "node --watch src/index.ts",
    "typecheck": "tsc --noEmit",
    "test": "node --test src/**/*.test.ts",
    "ci": "npm run typecheck && npm test"
  }
}

npm run dev gives you sub-100ms restart on file changes with zero compile overhead. npm run ci runs the full type-check before tests pass. You get the speed benefits in development without sacrificing type safety in production pipelines.

npm 11: Faster, Smaller, Safer

npm 11 ships with Node.js 24 and represents a substantial improvement over npm 9 across every dimension that affects daily developer productivity.

# npm benchmark: clean install of a large React project (~800 packages)
# npm 9:  45.2 seconds
# npm 10: 32.1 seconds
# npm 11: 15.8 seconds  ← 65% faster than npm 9!
# Bonus: lock file ~20% smaller

The 65% speed improvement comes from a rewritten dependency resolution algorithm that finds optimal install orderings more efficiently, combined with smarter parallelization of download and extraction operations. The node_modules directory itself shrinks due to improved deduplication — npm 11 identifies more cases where packages can share a single copy rather than each having their own.

The lock file size reduction is a secondary benefit that compounds over time: smaller lock files mean faster CI checkout times, smaller git history growth, and fewer merge conflicts when multiple developers add dependencies simultaneously.

Automatic vulnerability scanning on install means you’ll know immediately if a newly added package has known CVEs — before you’ve committed it, before it reaches your staging environment, before it becomes a problem.

Three New Language and Runtime Features

Float16Array: 50% Memory Savings for ML Workloads

Machine learning inference workloads in Node.js — model weights, activation tensors, image pixel buffers, audio samples — have historically been stored as Float32Array, consuming 4 bytes per element. Float16Array, now natively available in Node.js 24, halves that to 2 bytes per element while providing sufficient precision for inference (as opposed to training, which typically requires full 32-bit precision).

For a model with a million weights, that’s the difference between 4MB and 2MB in memory — and at scale, that difference determines whether you can keep models warm in a serverless function or whether cold starts become prohibitively expensive.

RegExp.escape(): Safe by Default

Every developer who has built search functionality or used user input in regular expressions has written (or should have written) a regex escaping utility. The problem was that there was no standard one — every codebase had its own, often incomplete, implementation. RegExp.escape() is now a built-in, correctly handling every character that requires escaping.

Explicit Resource Management with using

The using keyword brings deterministic resource cleanup to JavaScript — conceptually similar to C#’s using statement or Python’s with context manager. Any object that implements Symbol.dispose will have its disposal method called automatically when the surrounding scope exits, whether that exit is normal or due to an exception.

// Float16Array — Save 50% memory vs Float32Array
// Ideal for ML inference, image processing, audio
const modelWeights = new Float16Array(1024 * 1024); // 2MB instead of 4MB

// RegExp.escape() — Safe by default
const userInput = "hello (world) [test]";
const safe = RegExp.escape(userInput);
const regex = new RegExp(safe);

// Explicit Resource Management — "using" keyword
async function processFile() {
  using file = await openFile("data.csv");
  // file automatically closed when function ends
  const data = await file.readAll();
  return parseCSV(data);
}

class DatabaseConnection {
  [Symbol.dispose]() {
    this.close();
    console.log("Connection released");
  }
}

The using keyword is particularly valuable for database connections, file handles, and network sockets — resources that must be explicitly closed to avoid leaks. Previously, developers relied on try/finally blocks, which are verbose and easy to forget. With using, cleanup is structural and cannot be omitted.

Performance Benchmarks: The Numbers Behind the Claims

Raw HTTP server throughput is the most commonly cited benchmark for Node.js versions because it reflects the fundamental capacity of the runtime’s I/O handling:

• Node.js 20 LTS: 42,000 requests/second
• Node.js 22 LTS: 51,000 requests/second
• Node.js 24 LTS: 67,000 requests/second (+30% vs Node 22, +60% vs Node 20)

Memory consumption tells a complementary story:

• Node.js 20: 85MB baseline heap
• Node.js 22: 72MB baseline heap
• Node.js 24: 61MB baseline heap (−28% vs Node 20)

Both improvements trace back to V8 13.6, which ships with Node.js 24. V8 13.6 includes a revised garbage collector that reduces pause times and collects memory more aggressively between requests, a faster JIT compilation pipeline, and improved inline caching for common JavaScript patterns. The combined effect is more throughput with less memory — the ideal direction for any server-side runtime.

“Node.js 24 is the result of years of collaboration between the Node.js core team and the V8 team at Google. The performance improvements are real, and the TypeScript support changes the developer experience in a meaningful way.” — Matteo Collina, Node.js TSC member

Migration Guide: From Node.js 22 (or Earlier)

# Migration steps
nvm install 24
nvm use 24
node -v  # v24.x.x
npm test

# Remove ts-node/tsx
npm uninstall ts-node tsx
# Update scripts: "dev": "node --watch src/index.ts"

A few additional considerations for a smooth migration:

• Check your dependencies for compatibility. Run npx npm-check-updates to identify packages with available updates, then update incrementally rather than all at once. Most popular packages support Node.js 24 already.
• Minimum OS requirements have changed. Node.js 24 requires Windows 10 or newer and macOS 11 or newer. If you’re running CI on older images, update them before deploying Node.js 24.
• url.parse() behavior has changed slightly. If your codebase relies on the legacy url.parse() function (rather than the URL constructor), audit those call sites. The WHATWG URL constructor has been the preferred API since Node.js 10 and handles edge cases more consistently.
• Some deprecated APIs have been removed. Check the official Node.js 24 changelog for the complete list of removed APIs. Running your test suite against Node.js 24 is the fastest way to surface any breakage.

Conclusion

Node.js 24 LTS is the most impactful release in several years — not because any single change is revolutionary in isolation, but because these changes address the most persistent friction points in real Node.js development.

Native TypeScript execution removes the biggest everyday annoyance for the majority of Node.js developers who work in TypeScript. The separation between execution and type-checking is the right design: it keeps the development loop fast while keeping CI rigorous. npm 11’s speed improvements compound across every developer on your team, every CI run, every deployment pipeline. And the V8 13.6 performance gains are available to every application without a single line of code change.

If you’re running Node.js 20, you have until April 2026 before it exits maintenance. Start your migration now while the pressure is low. If you’re on Node.js 22, the upgrade path is even simpler — most codebases will migrate with only a version switch and a few script updates. The new features are immediately usable; the performance improvements are immediately available; the TypeScript workflow improvements are immediately visible.

Krypton is worth the upgrade.