Thirteen notable changes in one LTS minor is a lot. Node.js 24.19.0 shipped on August 3, 2026, and the usual advice for an LTS update ("it's a patch, install it") undersells it.
So I installed 24.18.0 and 24.19.0 side by side from nodejs.org and ran the new APIs against both. I'll say plainly what I did and didn't test: the five things below I ran on a Linux x64 container; the rest I read in the changelog and the v24 docs and haven't executed.
What Is Actually New in Node.js 24.19.0?
The notable-changes list in the v24 changelog, trimmed to what an application developer might touch:
| Change | Flag | I ran it |
|---|---|---|
blob.textStream() | none | yes |
fs.readFile() with a caller-supplied buffer | none | yes |
--experimental-import-text | yes | yes |
httpValidation option on http.createServer() | none | yes |
socket.setKeepAlive() with interval and count | none | read only |
stream.compose marked stable (docs) | none | read only |
ReadableStreamTee exported | none | read only |
perf_hooks per-iteration event loop delay sampling | none | read only |
TLS: certificateCompression, negotiated groups reported | none | read only |
Everything in the left column was added in a SEMVER-MINOR commit except the stream.compose documentation change. None of the entries is SEMVER-MAJOR. That's the headline: lots of surface, no removals.
Does blob.textStream() Work on 24.18.0?
No. That's the cleanest before-and-after in the release.
const b = new Blob(['cafe ', 'ok']);
let s = '';
for await (const chunk of b.textStream()) {
s += chunk;
}
console.log(s);On 24.19.0 this prints cafe ok. On 24.18.0 it throws b.textStream(...) is not a function or its return value is not async iterable. The docs describe it as the same thing as piping blob.stream() through a UTF-8 TextDecoderStream, which you've probably written by hand once or twice. Small win. Real one.
What Does the readFile Buffer Option Change?
fs.readFile() can now write into a buffer you hand it, instead of allocating a fresh one. The docs show readFile(path, { buffer: buf }), and a function form, buffer: (size) => Buffer.alloc(size).
I read a 25-byte file with a 16 KiB preallocated buffer on both versions. The contents were right on both, because 24.18.0 silently ignores the unknown option. The difference is where the bytes live. On 24.19.0 the returned buffer shares memory with mine (result.buffer === buf.buffer was true). On 24.18.0 it was false, a new allocation every call.
Does that matter? For a script that reads one config file, no. For a server that reads thousands of small files a second, reusing one buffer takes pressure off the allocator and the garbage collector. I haven't benchmarked that, so I won't give you a percentage.
One trap: the same code runs on 24.18.0 without an error and just doesn't reuse memory. If you rely on the sharing (say, you reuse buf immediately after), pin your minimum version in engines.
Is Importing a .txt File Ready to Use?
Not yet. My honest take: this is the feature I'd least build on right now.
import message from './message.txt' with { type: 'text' };
console.log(message);Without a flag on 24.19.0 I got ERR_UNKNOWN_FILE_EXTENSION. With node --experimental-import-text, it printed the file contents plus an ExperimentalWarning. On 24.18.0 the flag doesn't exist at all (bad option). The docs label it Stability 1.0, early development, and say the module exposes only a default export. It's a nice syntax for SQL snippets or prompt templates. A flag plus a warning on every start is not something to ship in production.
An LTS minor that adds thirteen features is still safe to install, but it isn't a patch, and the safe habit is to read the notable list before the upgrade instead of after the first odd bug.
What Does httpValidation Do to Incoming Headers?
This is the one I'd read twice if you run a public HTTP server. http.createServer() takes a new httpValidation option with three values per the docs: 'strict' (the default), 'relaxed' (aligns with the Fetch spec) and 'insecure' (same as insecureHTTPParser: true, and you can't combine the two).
I sent a raw request over a TCP socket with a single 0x01 byte inside a header value, against a server in each mode:
| Mode | 24.18.0 | 24.19.0 |
|---|---|---|
| default | 400 | 400 |
strict | 400 | 400 |
relaxed | 400 | 200 |
insecure | 400 | 200 |
On 24.18.0 the option is ignored, so every row is a 400. On 24.19.0 the default stayed strict, and only relaxed and insecure let the control character through. Good: nothing tightened under you.
There was one surprise. The docs say strict mode rejects any non-ASCII character in a header value. A single latin-1 0xE9 byte (the "e" with an acute accent) got a 200 in every mode, strict included. I didn't dig into why, so treat that doc sentence as looser than it reads and don't use strict mode as your only filter for non-ASCII input.
What About Keep-Alive, Streams and TLS?
Read, not run, so take these as the changelog's word. socket.setKeepAlive() now accepts interval and count, which map to TCP_KEEPINTVL and TCP_KEEPCNT, and has an options-object form: socket.setKeepAlive({ enable: true, initialDelay: 1000, interval: 1000, count: 10 }). Values are in milliseconds but applied in whole seconds, rounded down. If you've ever lost a long-lived connection to a cloud load balancer that drops idle flows, those two knobs are the reason to care.
stream.compose is now documented as stable, which matters if you build pipelines like the ones in our streams and backpressure guide. The TLS additions (certificate compression, reporting negotiated groups) are for people running their own TLS termination.
Should You Upgrade, and to What?
Yes, but not to 24.19.0 itself. By October 14, 2026 the 24.x line had reached 24.22.0, and the in-between releases kept adding things like updated root certificates (NSS 3.126 in 24.21.0) and an OpenSSL bump to 3.5.8. Install the newest 24.x.
The calendar matters more than any single feature. Per the official release schedule, Node 24 moves to maintenance on October 20, 2026, Node 26 is scheduled to become LTS on October 28, 2026, and Node 22 reaches end of life on April 30, 2027. If you're still on Node 20, support ended on April 30, 2026, and the Node.js 20 to 24 migration guide is the place to start. For the earlier line, see the notes on 24.18.0, and for the feature side of the v24 line, our Node 24 features guide.
My rule for an LTS minor: upgrade a branch, run the suite, grep your code for anything touching the APIs above, merge. That's an afternoon, not a project.