That was not true three years ago and it is a meaningful simplification.

the workflow#

{
  "compilerOptions": {
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true,
    "module": "nodenext",
    "strict": true,
    "noEmit": true
  }
}

node --test          # test runner, built in
node --watch app.ts  # dev, with reload, running TypeScript directly
npx tsc              # typecheck only, in CI
node app.ts          # production

No bundler. No transpiler in the runtime path. No ts-node. No nodemon. No dotenv. No test framework. No node-fetch.

The erasableSyntaxOnly flag is what makes it safe: it rejects any TypeScript syntax that cannot be removed by whitespace substitution — enums, namespaces with runtime values, parameter properties — so your source is guaranteed to run under type stripping.

what got absorbed, cumulatively#

Over the last several major versions Node has taken into the runtime:

Every one of those is a dependency removed, which is a supply chain surface removed, an upgrade treadmill removed, and a postinstall script removed.

For a small service, a fresh project's dependency count is now dramatically lower than it would have been in 2022. That is the most important consequence and it is rarely framed that way.

the division of labor that makes sense#

Typechecking belongs in CI and your editor. Not in the production runtime hot path. tsc --noEmit in CI, language server in your editor, type stripping at runtime.

A type error will happily run under stripping and fail at runtime. That is the correct trade — you check types where checking is cheap and run where running should be fast — and it requires that CI actually gates on the typecheck. If it does not, you have given up types.

Bundling is still right for some things. If you deploy to a serverless platform where cold start scales with file count, bundling helps. If you ship to browsers, obviously. For a long-running server process, it buys you nothing.

what is still missing#

Decorators. They are not erasable — they generate runtime code. If your framework depends on decorator-based dependency injection or routing, you need a transform. Several major frameworks are in this category, and it is the single most common blocker for adopting the no-build workflow.

Path aliases. @/components/foo requires resolution mapping. Node supports imports in package.json with the # prefix, which works and requires changing your import style.

Anything in your build that is not TypeScript. CSS modules, GraphQL documents, asset imports. If your build does more than strip types, you still have a build.

the migration advice#

If you are on Node 22 or earlier, plan the move. Check:

• Base image compatibility — minimum glibc and macOS versions have moved.
• Deprecated APIs that now throw rather than warn.
• Native modules, which need a rebuild.

Run the full suite on the new version in CI before switching the default. The upgrade is usually uneventful and "usually" is load-bearing.

the broader observation#

Node's response to competitive pressure from Deno and Bun was to absorb their best ideas rather than to argue about philosophy.

That was correct, it took about four years, and the ecosystem is meaningfully better for it. Competition in developer tooling works, and the incumbent that responds by improving rather than by defending is the one that keeps the position.

what you get in 24 LTS#

The accumulated result of the last two years of Node absorbing its own ecosystem:

• A test runner (node --test) with coverage, mocking, and watch mode.
• TypeScript type stripping, no build step.
• A permission model for filesystem, network, and child process access.
• .env file loading built in.
• A SQLite module in the standard library.
• fetch, WebSocket, URLPattern as globals.
• using declarations for deterministic resource cleanup.
• A watch mode that does not require nodemon.

Every one of those replaced a dependency. That is the whole story of Node's last three years, and it was the correct response to competitive pressure.

where the three landed#

Node won by absorbing. It has the ecosystem, the deployment targets, the enterprise support, and now most of the convenience. Its remaining weaknesses are startup time and the accumulated weight of API decisions from 2010 that cannot be changed.

Deno built the best security model and the most coherent standard library, then spent years walking back the decisions that made adoption hard — first adding npm compatibility, then node_modules, then package.json. It is excellent and it is a niche, and the trademark dispute over "JavaScript" was an unusual way to spend a year.

Bun won on speed and on the package manager. bun install is dramatically faster than npm and a very large number of teams use it for exactly that while running Node in production. That is a real and defensible position — being the best tool for one step of the workflow.

what actually changed for developers#

The competition worked. All three runtimes are much better than Node was in 2021, and Node specifically improved in ways it had resisted for a decade.

That is the argument for competition in developer tooling, and it is worth remembering when a dominant tool seems permanent.

practical guidance#

For a new production service: Node 24 LTS. The ecosystem compatibility and operational maturity dominate, and the convenience gap has closed.

For a CLI or a script: Bun, probably. Startup time and the single-binary story are genuinely better, and the compatibility risk is low for a program you control end to end.

For anything where sandboxing matters: Deno's permission model is the most mature, though Node's is now credible.

For your package manager: Bun or pnpm. npm is fine and it is slower, and the difference on a large install is minutes rather than seconds.

the migration note#

If you are on Node 20, plan the move to 24. Node 22 is a reasonable interim stop and there is no strong reason to linger there.

Things to check:

• Base image compatibility. Node 24 raises minimum glibc and macOS versions.
• Deprecated APIs that now throw rather than warning.
• Native modules. Anything with a compiled component needs a rebuild and possibly an upgrade.

Run your full test suite on 24 in CI before you switch the default. The upgrade is usually uneventful and "usually" is doing work in that sentence.

what's in it#

V8 13.6. Brings RegExp.escape (finally), Float16Array, Atomics.pause, and explicit resource management — the using declaration:

{
  using file = await open("data.txt");
  // ...
}  // file[Symbol.asyncDispose]() called automatically

That last one is a genuinely useful addition to the language. Deterministic cleanup without try/finally pyramids, and it composes with async.

npm 11. Faster, stricter, and with better handling of the lifecycle-script security surface.

AsyncLocalStorage now defaults to AsyncContextFrame, which is a substantially faster implementation. If you use context propagation for request tracing — and if you have an observability stack, you do — this is a real performance improvement you get for free.

The permission model drops the experimental dashes. --permission instead of --experimental-permission.

node --permission --allow-fs-read=./data --allow-net=api.example.com app.js

URLPattern is global. Undici updated, so fetch behavior tracks the platform more closely.

the direction#

Look at what Node has added over the last three major versions: a test runner, a watch mode, .env file support, a permission model, TypeScript type stripping, a SQLite module, and a full fetch stack.

Every one of those was previously a dependency. jest or mocha. nodemon. dotenv. Nothing, because there was no sandbox. ts-node. better-sqlite3. node-fetch or axios.

Node is absorbing its own ecosystem's most common packages into the runtime. This is a direct response to Deno and Bun, both of which shipped batteries-included from day one and made Node's "small core" philosophy look like an excuse.

I think this is correct and overdue. "Small core, rich ecosystem" was a reasonable position in 2012, when the ecosystem was small and trustworthy. In 2025, when a fresh Express app pulls three hundred transitive dependencies and each one is a supply chain risk, every capability moved into the runtime is one fewer package with a postinstall script.

the migration notes#

• Node 24 requires a newer minimum glibc and macOS version. Check your base images.
• Some deprecated APIs finally throw instead of warning. Run your test suite before you upgrade, not after.
• If you are on 20, plan to go to 24 when it hits LTS in October rather than stopping at 22.

the type stripping question#

Node can now run .ts files by erasing types. It does not typecheck. That is the correct division of labor — typechecking belongs in your editor and your CI, not in your production runtime hot path — but it does mean a type error will happily run and fail at runtime.

The workflow that makes sense: tsc --noEmit in CI, node app.ts in production, erasableSyntaxOnly set so you cannot accidentally use syntax that requires a transform.

No build step. That is a real ergonomic win and it has been a long time coming.

the context#

Node.js can now strip TypeScript types and run the resulting JavaScript directly. Deno and Bun have done this for a while. The approach is deliberately dumb — it does not typecheck, it does not transform, it replaces type annotations with whitespace and runs what is left.

That works beautifully for the ninety-five percent of TypeScript that is JavaScript plus annotations. It breaks completely for the parts of TypeScript that generate code:

enum Color { Red, Green }           // emits an object at runtime
namespace Utils { export const x = 1 }  // emits an IIFE
class Point {
  constructor(private x: number) {}  // parameter properties emit assignments
}
declare module "foo" {}              // fine, erasable

You cannot erase an enum. There is nothing to erase to; the enum is runtime code wearing type-shaped syntax.

what the flag does#

erasableSyntaxOnly: true makes the compiler reject any construct that cannot be removed by whitespace substitution. Enums, namespaces with runtime values, parameter properties, and old-style import = are all errors.

{
  "compilerOptions": {
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true,
    "module": "nodenext"
  }
}

Turn it on and your TypeScript is guaranteed to run under any type-stripping runtime with no build step at all.

the alternatives to what it bans#

You are losing very little.

Instead of an enum, a const object with a derived union type — which most codebases already prefer because it produces cleaner types and does not have enum's bizarre bidirectional-mapping behavior:

const Color = { Red: "red", Green: "green" } as const;
type Color = typeof Color[keyof typeof Color];  // "red" | "green"

Instead of parameter properties, an explicit assignment. Two extra lines, and the ES class fields proposal made the ergonomics fine anyway.

Instead of namespaces, modules. You should have done this in 2019.

const enum remains available with preserveConstEnums, but the honest advice is to stop using it — it has never played well with isolated module compilation and it never will.

also in 5.8#

• Checked returns for conditional expressions. Return statements whose type is a conditional now get checked against each branch individually rather than against the collapsed union, which catches a real class of bug.
• --module nodenext supports require() of ESM, tracking Node's own change.
• Faster program updates on the editor path, which you will feel in a large monorepo more than any feature.

the direction#

The build step for TypeScript is dissolving. Between type stripping in runtimes, tsc --noEmit as a pure typechecker in CI, and bundlers that handle TypeScript natively, the days of TypeScript-as-a-compile-target are ending.

What remains is TypeScript as a type system layered on JavaScript — which is what it always claimed to be and only recently became true. Set the flag, delete your enums, and stop thinking about the build.

what's new#

A built-in S3 client. Bun.s3 gives you presigned URLs, streaming reads and writes, and it works against any S3-compatible endpoint — R2, MinIO, Backblaze, the actual thing.

import { s3 } from "bun";

const file = s3.file("uploads/report.pdf");
await file.write(pdfBytes, { type: "application/pdf" });
const url = file.presign({ expiresIn: 3600 });

A built-in Postgres client. Bun.sql is a tagged-template SQL interface with connection pooling, prepared statements, and parameter binding that does not require you to think about $1 ordering.

import { sql } from "bun";
const users = await sql`select * from users where team = ${teamId} limit 20`;

Node compatibility as a first-class metric. Bun now publishes its pass rate against Node's own test suite and treats regressions as bugs. That is a much more honest signal than a feature checklist, and the number went up substantially in this cycle.

Text-based lockfile. bun.lock replaces the binary bun.lockb as the default. Reviewable in a pull request, diffable, mergeable. This was the single most common complaint about adopting Bun in a team setting and it is now gone.

the strategic read#

Node's answer to the same problem has been to add capabilities to the runtime incrementally and carefully: a built-in test runner, --watch, a permission model, and now stable-ish TypeScript stripping. Deno's answer was to bundle everything from the start and then spend years walking back the parts of its opinionated design that made adoption hard.

Bun's answer is to bundle everything and be compatible with Node's ecosystem rather than replacing it. That is a harder engineering problem and a much easier sales problem. Nobody has to rewrite anything. You point bun at an existing Express app and it mostly runs.

the honest caveats#

Bun's ecosystem edge cases still bite. Native modules that assume V8 internals will not work, because Bun is JavaScriptCore. Some observability agents assume Node. Long-tail packages that reach into process.binding or undocumented internals will surprise you.

The pattern for adoption in 2025 looks like: use Bun as the package manager and test runner immediately, because those are drop-in and dramatically faster; use the runtime in production when your dependency tree is one you actually understand.

That is not a hedge. That is just what shipping looks like.