Node.js 25: Native Stripping of TypeScript Types

Node.js 25 dropped yesterday. V8 14.1, faster JSON.stringify for large payloads, native Uint8Array base64/hex conversion. Solid release. But honestly, the headline for me is the TypeScript type stripping story finally reaching its conclusion.

Type stripping—Node.js natively running .ts files by ripping out type annotations at parse time—shipped unflagged in Node.js 23.6 but still carried the “experimental” label. With 25.2 (landing shortly after this initial release), that label goes away. Stable. No flags, no warnings. You run node script.ts and it just works.

Node.js 24: The Krypton LTS Cycle Begins

Node.js 24 landed on May 6th. Two days in, I’ve already migrated one personal project and started testing at work. The release is dense — V8 13.6, npm 11, Undici 7, a simplified permission model — but the part that interests me most isn’t any single feature. It’s the pattern these features reveal.

Node is maturing. Not in the “it’s boring now” sense. In the “it takes infrastructure seriously” sense. And that’s exactly what it needs to do to stay relevant.

Node.js 23: Experimental TypeScript Stripping

Node.js 23 dropped on October 16, and buried in the release notes between the V8 update and the require() changes is the feature TypeScript developers have been asking about for years: native TypeScript execution. You can now run node --experimental-strip-types app.ts and it works.

Mostly.

The implementation is more interesting than the headlines suggest, and the limitations matter more than the blog announcements let on. Let me walk through what’s actually happening under the hood and why it matters (or doesn’t) for your projects.

Node.js 22: Experimental ESM Require and V8 v12.4

The Node.js 22 release candidates have been floating around for a few weeks, and the headline feature is exactly what the community’s been screaming for since ESM first showed up: you can finally require() an ES module.

Well. Sort of. Behind a flag. And only if there’s no top-level await. But still — progress.

I’ve been running the RC against our codebase at DreamFlare to see what breaks and what actually gets easier. Here’s what jumped out.

Node.js 20: Permission Model and Test Runner Stability

Node.js has always operated on a trust-everything model. Your code, your dependencies, your dependencies’ dependencies — they all get the same unrestricted access to the filesystem, network, and child processes. A malicious package in your node_modules can read your SSH keys, exfiltrate environment variables, or spawn arbitrary processes. No guardrails. No questions asked.

Node.js 20, released April 18, starts changing that.

The Permission Model #

The new --experimental-permission flag lets you restrict what your Node.js process can do at runtime. Want to prevent filesystem writes outside a specific directory? Done. Want to block child process spawning entirely? Also done. Worker thread creation? Controllable.

Node.js 18: Native Fetch API and Experimental Test Runner

Node.js 18 dropped on April 19th, and for the first time in a while, I’m genuinely excited about a Node release. Not because of performance improvements or security patches — those are table stakes — but because of two features that address long-standing gaps in the platform: a global fetch API and a built-in test runner.

Both are experimental. Both have caveats. And both signal a direction for Node.js that I think is overdue.

Node.js 17: OpenSSL 3.0 and Improved Stack Traces

Node.js 17 drops next week, and the headline change is one that’ll cause some headaches: OpenSSL 3.0 replaces OpenSSL 1.1.1.

This isn’t a minor version bump. OpenSSL 3.0 tightens restrictions on which algorithms and key sizes are allowed by default. If your application (or more likely, one of your dependencies) uses algorithms that OpenSSL 3.0 considers legacy, you’ll start seeing ERR_OSSL_EVP_UNSUPPORTED errors. No deprecation warning period — just errors.

As a Current (non-LTS) release, Node 17 won’t run in most production environments. That’s actually the point. It gives the ecosystem time to find and fix compatibility issues before OpenSSL 3.0 ships in Node.js 18 LTS, which is the release that’ll matter for production workloads.

Node.js 16: Timers Promises and Apple Silicon support

Node.js 16 drops April 20th. I’ve been poking around the dev branch and the pre-release notes, and there’s enough here to warrant a proper look. Not a paradigm shift — more like a collection of practical fixes for real friction points.

Here’s what stands out.

Timers Promises Goes Stable #

This is the one I’m most excited about. The Timers Promises API has been experimental since Node.js 15, and it graduates to stable in v16.

AWS Lambda support for Node.js 14 release

AWS announced Node.js 14 support for Lambda on February 3rd. Two days ago. I’ve already started evaluating the migration path for our serverless workloads at TaskRabbit.

Node.js 14 has been the active LTS release since October 2020, so this wasn’t a surprise. But Lambda runtime support typically lags LTS availability by several months—Node 12 followed the same pattern—and the gap means teams running Lambda in production have been stuck on Node 12 while the ecosystem moves forward. That gap closes now.

Deno vs. Node: A Runtime Choice for 2021

Ryan Dahl released Deno 1.0 in May. If you don’t know the backstory—Dahl created Node.js, spent years watching it evolve in directions he regretted, then built Deno as a corrective. The “10 Things I Regret About Node.js” talk from JSConf EU 2018 is worth watching if you haven’t seen it. He lays out every design decision he wanted to undo, and honestly? It’s compelling stuff.

Five months post-launch, I’ve been kicking Deno’s tires as part of our 2021 technical planning at TaskRabbit. We’re a Node shop through and through—TypeScript, Express, GraphQL, the whole deal. So this isn’t some academic exercise for me. If Deno’s ready, it could actually simplify parts of our stack. If it’s not, I need to know exactly why—and more importantly, when it might be.

Node.js 15: Introduction to AbortController

If you’ve done any work with fetch in the browser, you’ve probably used AbortController. It’s the standard Web API for cancelling asynchronous operations—pass an AbortSignal to a fetch call, call abort() when you want to cancel, and the browser throws an AbortError. Clean, composable, and it works.

Node.js hasn’t had this. And honestly? The absence of a built-in cancellation primitive has been one of those quiet pain points that every backend developer just… works around. Some use timeouts. Some use custom event emitters. Some reach for p-cancelable or similar libraries. None of it is standardized—every team invents their own slightly different pattern.

Node.js 6.14.7: Security Patches and Dependency Audits

Last month, the Node.js project shipped security releases for versions 10, 12, and 14. If you’re running Node 6 in production—and I know some of you are—you got nothing.

Node.js 6 reached End-of-Life in April 2019. That was over a year ago. No more patches, no more backports, no more security fixes. The June 2020 releases addressed TLS session reuse vulnerabilities, HTTP request smuggling vectors, and DNS rebinding issues across the active release lines. Node 6? Exposed to all of them, with zero official remediation path.

Stable Workers Threads in Node.js for High-CPU tasks

Node.js is single-threaded. Everyone knows this.

It’s also the source of the most common misconception about Node: that it can’t do CPU-intensive work. It can. Worker Threads have been stable since Node.js 12 LTS (April 2019), and they give you actual parallelism — not the cooperative multitasking of the event loop, but real OS-level threads running JavaScript in parallel.

So why, a year later, do most teams I talk to still haven’t touched them?

Node.js 14: Diagnostic Reports and Internationalization

Node.js 14 lands April 21. I’ve been poking at the dev branch for a few weeks now, and two things keep standing out: Diagnostic Reports graduating to stable, and full ICU internationalization data shipping by default.

Neither is glamorous. Both are the kind of thing that makes Node.js meaningfully better in production — which is exactly what I care about.

Diagnostic Reports Go Stable #

Diagnostic Reports have been experimental since Node.js 11. The concept is straightforward: when something goes wrong (a crash, a hang, a weird performance cliff you can’t explain), you generate a JSON report that captures the full state of the process. Stack traces, heap statistics, resource usage, libuv handle information, environment variables, loaded native modules. Everything you’d want in a post-mortem.

The Case for Modular Monoliths in Distributed Teams

Every architecture conversation I’ve had in the last two years eventually arrives at the same question: “When do we move to microservices?”

Not if. When.

I think that’s the wrong framing. At TaskRabbit, I manage a team of nine engineers spread across four time zones. We’ve been through the architecture discussion more than once, and what I keep coming back to is this: the coordination overhead of microservices might actually be worse than the monolith problems they’re supposed to solve.