--- title: "Node.js 26.4.0 'Current' bringt das node:vfs-Subsystem (Matteo Collina), ESM-Loader-Package-Maps (Maël Nison), TLS-Zertifikatkompression, TCP_KEEPINTVL/TCP_KEEPCNT und argon2 als stabil" description: "Node.js 26.4.0 (Current), veröffentlicht am 2026-06-24 von @aduh95, liefert acht SEMVER-MINOR-Änderungen: ein minimales node:vfs-Subsystem, das vom Anwendungscode bereitgestellte virtuelle Dateisysteme einhängt (PR #63115, Matteo Collina) sowie ein Folgepatch, das node:fs/promises an eingehängte VFS-Instanzen weiterleitet (PR #63537), Package-Maps für ESM-Loader-Hooks, die Bare-Spezifier durch die Loader-Hooks routen (PR #62239, Maël Nison), TLS certificateCompression, das die zlib- und zstd-Kompression aus RFC 8879 durch die OpenSSL-Build-Konfiguration verkabelt (PR #62217, Tim Perry), TCP_KEEPINTVL- und TCP_KEEPCNT-Unterstützung in net.Socket.setKeepAlive (PR #63825, Guy Bedford), vom Aufrufer bereitgestellte Buffer in fs.readFile / fs.readFileSync (PR #63634, Matteo Collina), closeIdleConnections, das nun auch Pre-Request-Sockets schließt (PR #63470, semimikoh), net.BlockList auf Release-Candidate-Stabilität vorgerückt (PR #63050), und crypto.argon2 + KEM encap/decap als stabil markiert (PR #63924, Filip Skokan). Die Release ergänzt außerdem WebCrypto-cSHAKE (PR #63988), QUIC listEndpoints (PR #63536) und X509Certificate-Handles (PR #63191), dgram connectSync / bindSync (PRs #63838 + #63932, Guy Bedford), net.BoundSocket für frühes TCP-Binding (PR #63951), einen experimentellen schnellen FFI-Aufrufpfad für AArch64 und x86_64 (PRs #63068 + #63941, Paolo Insogna), npm 11.17.0 (PR #63857), sqlite 3.53.2 und libffi 3.6.0." date: 2026-06-25 image: "/images/heroes/2026-06-25--node-js-26-4-current-vfs-loader-package-maps.png" author: lschvn tags: ["runtimes", "tooling", "security"] tldr: - "Node.js 26.4.0 'Current', veröffentlicht am 2026-06-24 von @aduh95, ist die erste Release der 26.x-Linie, die ein minimales `node:vfs`-Subsystem ergänzt ([PR #63115](https://github.com/nodejs/node/pull/63115), Matteo Collina) und `node:fs/promises` an vom Anwendungscode eingehängte VFS-Instanzen weiterleitet ([PR #63537](https://github.com/nodejs/node/pull/63537)). Die zwei VFS-PRs landen in derselben Woche wie die [Node.js 24.18.0 'Krypton' LTS-Release](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake), was bedeutet, dass die Sandboxing-Primitiven der Current-Linie nur noch einen Zyklus von der LTS-Linie entfernt sind, die Produktionsnutzer tatsächlich ausrollen." - "Die zweite zentrale SEMVER-MINOR-Arbeit ist [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison, der Yarn-Erfinder), die Package-Maps für ESM-Loader-Hooks implementiert. Loader-Autoren können nun dieselbe `imports`-Map lesen, die Node.js bereits verwendet, um Bare-Spezifier im Anwendungsgraphen aufzulösen, und es ist das erste Mal, dass die ESM-Loader-Hooks die Package-Map-Maschinerie als erstklassige API freilegen. Die Release ergänzt außerdem TLS certificateCompression oberhalb der OpenSSL-Kompressionsarbeit ([PR #62217](https://github.com/nodejs/node/pull/62217), Tim Perry) und legt TCP_KEEPINTVL und TCP_KEEPCNT in `net.Socket.setKeepAlive` offen ([PR #63825](https://github.com/nodejs/node/pull/63825), Guy Bedford)." - "Weitere konkrete Änderungen: `crypto.argon2` und `crypto.encap` / `crypto.decap` werden als stabil markiert ([PR #63924](https://github.com/nodejs/node/pull/63924), Filip Skokan); WebCrypto erhält cSHAKE und Nicht-Byte-Digest-Längen ([PR #63988](https://github.com/nodejs/node/pull/63988)); `net.BlockList` rückt in den Release-Candidate-Status ([PR #63050](https://github.com/nodejs/node/pull/63050)); QUIC legt eine `listEndpoints`-API offen und liefert X509Certificate-Handles statt roher OpenSSL-Handles ([PR #63536](https://github.com/nodejs/node/pull/63536), [PR #63191](https://github.com/nodejs/node/pull/63191)); `dgram` erhält synchrone `connectSync` / `bindSync` ([PRs #63838](https://github.com/nodejs/node/pull/63838) + [#63932](https://github.com/nodejs/node/pull/63932), Guy Bedford); ein experimenteller schneller FFI-Aufrufpfad kommt für AArch64 und x86_64 ([PRs #63068](https://github.com/nodejs/node/pull/63068) + [#63941](https://github.com/nodejs/node/pull/63941), Paolo Insogna); npm liefert 11.17.0, sqlite geht auf 3.53.2, libffi auf 3.6.0, und die [Node.js-25-Linie wird in der Doku als End-of-Life markiert](https://github.com/nodejs/node/pull/63692)." faq: - question: "Was ist die wichtigste Neuerung in Node.js 26.4.0 'Current'?" answer: "Es gibt zwei Schwerpunkte, je nachdem, welche Schicht einen betrifft. Für die Laufzeit-Architektur ist das neue [node:vfs-Subsystem](https://github.com/nodejs/node/pull/63115) (Matteo Collina) der Aufmacher: eine minimale VFS-Schicht, die vom Anwendungscode eingehängt und ausgehängt werden kann, plus ein Folgepatch ([PR #63537](https://github.com/nodejs/node/pull/63537)), das `node:fs/promises`-Aufrufe an die eingehängten VFS-Instanzen weiterleitet, statt auf die echte Festplatte zuzugreifen. Das ist das Fundament, auf dem künftige gesandboxte Datei-APIs in Node.js aufsetzen werden. Für das ESM-Loader-Ökosystem implementiert [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison, der Yarn-Erfinder) Package-Maps für ESM-Loader-Hooks, das erste Mal, dass Loader-Hooks eine erstklassige API erhalten, um dieselbe `imports`-Map zu lesen, die der Host-Runtime zur Auflösung von Bare-Spezifiern dient. Werkzeug-Autoren (Vite, Rolldown, esbuild, swc, oxc) und Framework-Autoren, die ihre eigenen Loader bauen, bekommen zum ersten Mal einen einheitlichen Pfad durch die Loader-Hooks." - question: "Was macht das node:vfs-Subsystem, und warum ist es wichtig?" answer: "Das neue `node:vfs`-Subsystem ist eine minimale In-Process-VFS-Schicht, die vom Anwendungscode zur Laufzeit ein- und ausgehängt werden kann. Die [PR #63115](https://github.com/nodejs/node/pull/63115) ergänzt das Subsystem selbst: eine kleine In-Process-Registry eingehängter VFS-Instanzen sowie das öffentliche `node:vfs`-Modul, das `mount`, `unmount`, `getMount` und `getMounts` freilegt. Die [PR #63537](https://github.com/nodejs/node/pull/63537) verkabelt die Schicht direkt in `node:fs/promises`, sodass ein `readFile`-Aufruf auf einem Pfad, der mit einem eingehängten Präfix beginnt, an die VFS-Instanz weitergeleitet wird statt ans Betriebssystem. Das Stück ist das laufzeitseitige Fundament für gesandboxte Ausführung: Build-Werkzeuge können einem Loader ein virtuelles Dateisystem übergeben, das den Projektbaum enthält, Serverless-Plattformen können einem Request-Handler ein virtuelles Dateisystem übergeben, das nur den Request-Scope enthält, und IDE-Spracheserver können einer Debugger-Sonde ein virtuelles Dateisystem übergeben, das die zu debuggende Datei enthält. Die VFS-Instanz-Schnittstelle ist in diesem ersten Schnitt bewusst minimal; reichhaltigere Semantiken (Symlinks, File-Watching, Real-Path-Auflösung) werden in späteren Current-Releases erwartet." - question: "Wie funktionieren Package-Maps für ESM-Loader-Hooks?" answer: "Die [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison) implementiert Package-Maps für die ESM-Loader-Hooks. Die Runtime hat bereits eine `imports`-Map im `package.json`-Stil, die es dem Anwendungsgraphen erlaubt, Bare-Spezifier (`#internal/api`, `lodash/sortBy`) aufzulösen; Loader-Hooks mussten den Map-Lookup zuvor selbst neu implementieren, weil die Auflösung intern zum Module-Loader erfolgte. Die neue API legt dieselbe Auflösung als erstklassigen Aufruf auf den Loader-Hooks offen, sodass ein Loader, der wissen muss, ob ein Spezifier zu einem remappten Pfad (oder zu einem Subpfad) aufgelöst wird, das Ergebnis direkt lesen kann, ohne die `package.json` selbst zu durchlaufen. Für Build-Werkzeug-Autoren ist das das fehlende Stück, um Node.js-kompatible Import-Maps oberhalb eines Bundlers zu implementieren; die [Import-Map-Spec](https://html.spec.whatwg.org/multipage/webappapis.html#import-maps) definiert bereits das Drahtformat, und Node.js legt nun dieselbe Form offen, die Browser-Import-Maps konsumieren. Die PR-Beschreibung rahmt es als die Loader-Hooks-Seite derselben Import-Map-Arbeit, die [Vite 8.1s `build.chunkImportMap`](https://github.com/vitejs/vite/releases/tag/v8.1.0) auf der Build-Output-Schicht ausliefert." - question: "Was ist TLS-Zertifikatkompression, und wann hilft sie?" answer: "TLS-Zertifikatkompression ist die [RFC 8879](https://www.rfc-editor.org/rfc/rfc8879)-Erweiterung, die es dem TLS-Handshake erlaubt, die Server-Zertifikatskette in komprimierter Form zu senden. Sie ist vor allem dann nützlich, wenn die Kette eine große Post-Quanten-Signatur enthält, was derselbe Grund ist, aus dem Chrome und Firefox sie im letzten Jahr ausgerollt haben. Die [PR #62217](https://github.com/nodejs/node/pull/62217) (Tim Perry) ergänzt eine `certificateCompression`-Option auf `tls.createSecureContext` und `https.Server`, die ein Array von Kompressionsalgorithmen (`'zlib'` und `'zstd'`) akzeptiert, und aktualisiert die OpenSSL-Build-Konfiguration, sodass die OpenSSL-Kompressionsprimitiven in das Node.js-Binary gelinkt werden. Der zugehörige Commit `e44b5d487e` aktualisiert die OpenSSL-Build-Konfiguration zur Unterstützung der Kompression; ohne das wäre der OpenSSL-seitige Support auf der Node.js-TLS-Schicht nicht verfügbar." - question: "Warum ist die Freilegung von TCP_KEEPINTVL und TCP_KEEPCNT wichtig?" answer: "Die [PR #63825](https://github.com/nodejs/node/pull/63825) (Guy Bedford) ergänzt `TCP_KEEPINTVL` und `TCP_KEEPCNT` zu den von `net.Socket.setKeepAlive(enable, initialDelay)` akzeptierten Optionen. Vor 26.4.0 akzeptierte `setKeepAlive` nur das Initial-Delay-Argument, und das Intervall zwischen Probes sowie die Anzahl der Probes, bevor die Verbindung als tot deklariert wurde, waren OS-Defaults. Unter Linux sind die Defaults 75 Sekunden zwischen Probes und 9 Probes bis zum Abbruch, was bedeutet, dass eine halboffene Verbindung ~11 Minuten überlebt; unter macOS sind die Defaults ähnlich. Bibliotheksautoren (Datenbanktreiber, Message-Broker, Edge-Runtimes, QUIC-Clients) konnten diese Werte nicht tunen, ohne auf ein natives Modul zurückzugreifen. Mit den neuen Optionen kann der Anwendungscode das Probe-Intervall auf wenige Sekunden und die Anzahl auf eine kleine Zahl verkürzen, was die Konfiguration ist, die Produktions-Datenbanktreiber seit Jahren wollten. Die zugehörige [PR #63951](https://github.com/nodejs/node/pull/63951) ergänzt `net.BoundSocket`, eine synchrone Primitive für frühes TCP-Binding für Codepfade, die einen Port binden müssen, bevor sie an die Event-Loop yielden." - question: "Was stabilisiert die Release auf der Crypto-Seite?" answer: "Die [PR #63924](https://github.com/nodejs/node/pull/63924) (Filip Skokan) markiert `crypto.argon2` (Argon2id, Argon2i, Argon2d) und `crypto.encap` / `crypto.decap` (Key-Encapsulation für ML-KEM und RSA-OAEP) als stabil. Beide standen seit dem 22.x-Zyklus hinter einem experimentellen Flag, und die Stabilisierung ist die Voraussetzung dafür, dass Bibliotheken ohne die Flags `--experimental-argon2` und `--experimental-encap-decap` davon abhängen können. Die Release ergänzt außerdem WebCrypto-cSHAKE-Unterstützung ([PR #63988](https://github.com/nodejs/node/pull/63988), Filip Skokan), was Node.js mit demselben cSHAKE in Einklang bringt, das die [Node.js-24.18.0-LTS-Web-Crypto-Arbeit](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) erweitert hat. net.BlockList rückt in den Release-Candidate-Status ([PR #63050](https://github.com/nodejs/node/pull/63050), alphaleadership), der letzte Schritt vor stabil in der nächsten Current-Release." - question: "Was ist die Fast-FFI-Arbeit, und warum ist sie in 26.x Current statt in LTS?" answer: "Die [PR #63068](https://github.com/nodejs/node/pull/63068) und [PR #63941](https://github.com/nodejs/node/pull/63941) (Paolo Insogna) ergänzen eine experimentelle schnelle FFI-Aufruf-API für AArch64 und x86_64. Die Arbeit legt ein `node:ffi`-Modul offen, das JavaScript das Aufrufen nativer C-Funktionen ohne den Weg über `node-addon-api` erlaubt, mit den Kosten eines indirekten Aufrufs statt des V8-/libuv-/N-API-/nan-Round-Trips, den der bestehende Addon-Pfad nimmt. Der Benchmark in der PR-Beschreibung zitiert etwa 50 % der Aufruf-Latenz des bestehenden Addon-Pfads auf x86_64 Linux. Das Feature ist zuerst in 26.x Current, weil die API-Oberfläche (Aufrufkonvention, libffi-Backend-Verkabelung, Lifetime-Regeln) noch geformt wird; die [Folge-PR #63794](https://github.com/nodejs/node/pull/63794) portiert dieselbe Maschinerie auf riscv64 und andere Architekturen. Produktionsnutzer auf der v24-LTS-Linie brauchen nicht zu handeln; der Pfad ist hinter `--experimental-ffi` verborgen, und die API wird mindestens einen Current-Zyklus durchlaufen, bevor sie für die LTS-Linie kandidiert." - question: "Welche QUIC-Arbeit liefert die 26.4.0?" answer: "Drei QUIC-Änderungen landen auf der Current-Linie. Die [PR #63536](https://github.com/nodejs/node/pull/63536) (James M. Snell) ergänzt eine `listEndpoints`-API, die die aktuell vom QuicEndpoint genutzten lokalen UDP-Endpunkte zurückgibt. Die [PR #63191](https://github.com/nodejs/node/pull/63191) (Tim Perry) ändert den QUIC-Zertifikats-Accessor so, dass er einen JavaScript-`X509Certificate`-Handle statt des rohen OpenSSL-Handles zurückgibt, den die frühere Alpha freilegte, was eine langjährige Beschwerde von QUIC-Nutzern schließt, die die Zertifikatskette inspizieren wollten, ohne durch `tls.getPeerCertificate` zu gehen. Die [PR #63946](https://github.com/nodejs/node/pull/63946) und [PR #63950](https://github.com/nodejs/node/pull/63950) (Tim Perry) beheben zwei echte Bugs: ein `get_reader`-Problem, das Daten auf FIN droppte, und einen Reader-Backpressure-Deadlock auf inaktiven Verbindungen. Die QUIC-Arbeit sitzt auf dem [Node.js-24.18.0-libuv-reuse-port-Folgepatch](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) und der QUIC-CI-Arbeit auf, die seit zwei Monaten auf der v24-Linie landet." - question: "Was sollten Nutzer auf der v24-LTS-Linie heute tun?" answer: "Für Produktionsnutzer auf der v24-LTS-Linie ändert sich nichts; v26.4.0 ist die Current-Linie, und die neuen Features (VFS, Package-Maps, TLS-Zertifikatkompression, Fast-FFI) werden Monate brauchen, um zurückportiert zu werden. Die vor zwei Tagen ausgelieferte v24.18.0-Release bleibt das empfohlene stabile Ziel. Die zwei Folgepatches, die auf der v24-Seite zu beobachten sind, sind das VFS-Subsystem (das irgendwann in die LTS-Linie wandern wird) und die TLS-Zertifikatkompression (die das [Node.js-Sicherheitsrelease von Juni 2026](/articles/2026-06-18--node-js-june-2026-security-releases) für die v22-Linie abgedeckt hat). Die v24.18.0-LTS-Linie wird diese Punkte aufnehmen, sobald die Current-Linie sie stabilisiert hat, was derselbe Zyklus ist, der den [Buffer.poolSize-64-KiB-Default](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) nach zwei Monaten auf Current auf v24.18.0 gebracht hat." - question: "Was liefert die 26.4.0 sonst noch?" answer: "Einige kleinere Stücke sind erwähnenswert. Die [PR #63634](https://github.com/nodejs/node/pull/63634) (Matteo Collina) ergänzt die Unterstützung vom Aufrufer bereitgestellter Buffer für `fs.readFile` und `fs.readFileSync`, das erste Mal, dass die File-Read-API es dem Aufrufer erlaubt, den Ziel-Buffer zu übergeben, statt Node.js intern allokieren zu lassen. Die [PR #63470](https://github.com/nodejs/node/pull/63470) (semimikoh) sorgt dafür, dass `http.closeIdleConnections` auch Pre-Request-Sockets schließt, was einen echten Bug behebt, bei dem inaktive Keep-Alive-Sockets eine Verbindung offenhielten, nachdem der Request, der sie besaß, abgeschlossen war. npm liefert 11.17.0 ([PR #63857](https://github.com/nodejs/node/pull/63857)), sqlite geht auf 3.53.2, libffi auf 3.6.0 ([PR #64040](https://github.com/nodejs/node/pull/64040)), und acorn auf 8.17.0. Die Release markiert außerdem [Node.js 25 als End-of-Life in der Dokumentation](https://github.com/nodejs/node/pull/63692) und liefert einen langen Stream-Optimierungspatch (Matteo Collina, James M. Snell, Trivikram Kamat), der Allokationen auf den WHATWG-Streams-Hot-Paths reduziert, den Utf8Stream-Stall nach einem vollständigen Schreibvorgang von Multi-Byte-Daten behebt und die `stream/iter`-Backpressure verfeinert. Die zugehörige [PR #62986](https://github.com/nodejs/node/pull/62986) behebt `Writable.toWeb()` `desiredSize` für Non-Object-Mode-Streams, ein langjähriger Bug, der immer dann auftauchte, wenn der WHATWG-Streams-Adapter mit einem binären Stream verwendet wurde." --- [Node.js 26.4.0 'Current'](https://github.com/nodejs/node/releases/tag/v26.4.0), veröffentlicht am 2026-06-24 um 23:38 UTC von @aduh95 mit @aduh95, @targos und @jasnell als Release-Stewards, ist die zweite Current-Release im Juni auf der v26-Linie und die größte des Zyklus seit [26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) am 2026-06-01. Sie liefert acht SEMVER-MINOR-Änderungen: ein minimales [node:vfs-Subsystem](https://github.com/nodejs/node/pull/63115) (Matteo Collina) plus ein Folgepatch, das `node:fs/promises` an eingehängte VFS-Instanzen weiterleitet ([PR #63537](https://github.com/nodejs/node/pull/63537)), [Package-Maps für ESM-Loader-Hooks](https://github.com/nodejs/node/pull/62239) (Maël Nison, der Yarn-Erfinder), [TLS certificateCompression](https://github.com/nodejs/node/pull/62217) oberhalb der OpenSSL-Kompressionsarbeit (Tim Perry), `TCP_KEEPINTVL` und `TCP_KEEPCNT` in [net.Socket.setKeepAlive](https://github.com/nodejs/node/pull/63825) (Guy Bedford), vom Aufrufer bereitgestellte Buffer in `fs.readFile` ([PR #63634](https://github.com/nodejs/node/pull/63634), Matteo Collina), `closeIdleConnections`, das nun auch Pre-Request-Sockets schließt ([PR #63470](https://github.com/nodejs/node/pull/63470), semimikoh), `net.BlockList` auf Release-Candidate-Stabilität vorgerückt ([PR #63050](https://github.com/nodejs/node/pull/63050)), und `crypto.argon2` sowie `crypto.encap` / `crypto.decap` als stabil markiert ([PR #63924](https://github.com/nodejs/node/pull/63924), Filip Skokan). Die Release landet zwei Tage nach [Node.js 24.18.0 'Krypton' (LTS)](https://github.com/nodejs/node/releases/tag/v24.18.0) am 2026-06-23, und das Timing folgt dem üblichen Muster: Die Current-Linie trägt die experimentelle Arbeit, die irgendwann in LTS zurückportiert wird. Der [Buffer.poolSize-64-KiB-Default](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) ist das kanonische Beispiel, das auf Current in [26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) am 2026-06-01 und auf LTS in 24.18.0 vor zwei Tagen ausgeliefert wurde. Das VFS-Subsystem, die Package-Maps für ESM-Loader und die TLS-Zertifikatkompression sind Arbeit derselben Art: bedeutsam genug, um ihre eigene Current-Release zu verdienen, aber noch experimentell genug, um die v24-LTS-Linie nicht vor mindestens einem weiteren Zyklus zu erreichen. ## `node:vfs`, ein neues Kernsubsystem Die architektonisch bedeutsamste Änderung in 26.4.0 ist das neue `node:vfs`-Subsystem. Die [PR #63115](https://github.com/nodejs/node/pull/63115) (Matteo Collina) ergänzt eine minimale In-Process-VFS-Schicht, die vom Anwendungscode zur Laufzeit ein- und ausgehängt werden kann. Das Subsystem legt vier Funktionen offen: `mount(prefix, vfsInstance)`, `unmount(prefix)`, `getMount(prefix)` und `getMounts()`. Die `vfsInstance` ist ein JavaScript-Objekt, das eine kleine Async-Schnittstelle implementiert (`readFile`, `stat`, `readdir`, plus eine Handvoll weiterer), und Node.js leitet `node:fs/promises`-Aufrufe, deren Pfad mit dem eingehängten Präfix beginnt, an die Instanz statt an das Betriebssystem-Dateisystem weiter. Das Folgepatch [PR #63537](https://github.com/nodejs/node/pull/63537) (Matteo Collina) verkabelt die Schicht direkt in `node:fs/promises`. Ein `readFile('/vfs/project/src/index.ts')`-Aufruf auf einem Präfix, der mit einer In-Memory-VFS-Instanz eingehängt wurde, die den Projektbaum enthält, gibt die In-Memory-Inhalte zurück, ohne die Festplatte anzufassen. Die Integration ist das laufzeitseitige Fundament für gesandboxte Ausführung: Build-Werkzeuge können einem Loader ein virtuelles Dateisystem übergeben, das den Projektbaum enthält, Serverless-Plattformen können einem Request-Handler ein virtuelles Dateisystem übergeben, das nur den Request-Scope enthält, IDE-Spracheserver können einer Debugger-Sonde ein virtuelles Dateisystem übergeben, das die zu debuggende Datei enthält. Produktionsnutzer auf der v24-LTS-Linie werden dies nicht vor mindestens einem Release-Zyklus sehen, aber die Current-Linie hat nun die Primitive, auf der die nächste Runde Werkzeug-Arbeit aufsetzen wird. Die VFS-Instanz-Schnittstelle ist in diesem ersten Schnitt bewusst minimal. Die PR-Beschreibung ist explizit, dass Symlinks, File-Watching und Real-Path-Auflösung außerhalb des Scopes liegen und in späteren Current-Releases landen werden. Die zugehörige Dokumentations-PR beschreibt die Oberfläche als „das kleinste tragfähige VFS, das es uns erlaubt, ad-hoc-fs-Monkey-Patching in Werkzeugen zu ersetzen", und merkt an, dass die API mindestens einen Current-Zyklus durchlaufen wird, bevor sie für die Stabilisierung kandidiert. ## Package-Maps für ESM-Loader-Hooks Die zweite architektonische Änderung ist die [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison), die Package-Maps für die ESM-Loader-Hooks implementiert. Die Runtime hat bereits eine `imports`-Map im `package.json`-Stil, die es dem Anwendungsgraphen erlaubt, Bare-Spezifier (`#internal/api`, `lodash/sortBy`, `react/jsx-runtime`) aufzulösen; Loader-Hooks mussten den Map-Lookup zuvor selbst neu implementieren, weil die Auflösung intern zum Module-Loader erfolgte. Die neue API legt dieselbe Auflösung als erstklassigen Aufruf auf den Loader-Hooks offen, sodass ein Loader, der wissen muss, ob ein Spezifier zu einem remappten Pfad (oder zu einem Subpfad) aufgelöst wird, das Ergebnis direkt lesen kann, ohne die `package.json` selbst zu durchlaufen. Für Build-Werkzeug-Autoren ist das das fehlende Stück, um Node.js-kompatible Import-Maps oberhalb eines Bundlers zu implementieren. Die [Import-Map-Spec](https://html.spec.whatwg.org/multipage/webappapis.html#import-maps) definiert bereits das Drahtformat, und die Browser-Implementierungen liefern Import-Maps seit Jahren aus. Node.js hatte das zugrundeliegende `imports`-Feld über denselben Zeitraum, aber die Loader-Hooks-API legte nie den Auflösungspfad offen, den die Host-Runtime verwendete; Loader-Autoren mussten die `package.json` durchlaufen und die Map neu implementieren. Maël Nison, der den Package-Manager Yarn authored hat und Hauptbeitragender zum [Yarn-`resolutions`](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/)-Mechanismus war, ist der richtige Autor für diese Arbeit, und die PR ist das erste Mal, dass die ESM-Loader-Hooks die Package-Map-Maschinerie als erstklassige API freilegen. Die PR-Beschreibung rahmt es als die Loader-Hooks-Seite derselben Import-Map-Arbeit, die [Vite 8.1s `build.chunkImportMap`](https://github.com/vitejs/vite/releases/tag/v8.1.0) auf der Build-Output-Schicht ausliefert (behandelt in [unserem Vite-8.1-Stable-Artikel](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode)). Vite 8.1s chunkImportMap ist eine Bundler-seitige Funktion, die eine Browser-Import-Map für die Chunk-URL-Auflösung emittiert; die Loader-Package-Maps von 26.4.0 sind die Host-Runtime-Seite, die ein Bundler konsumieren würde, wenn er unter Node.js läuft. Die beiden Stücke sind unabhängig nützlich, sitzen aber auf unterschiedlichen Schichten desselben Stacks. ## TLS-Zertifikatkompression Die dritte SEMVER-MINOR-Änderung ist die [PR #62217](https://github.com/nodejs/node/pull/62217) (Tim Perry), die eine `certificateCompression`-Option zu `tls.createSecureContext` und `https.Server` ergänzt. Die Option nimmt ein Array von Kompressionsalgorithmen (`'zlib'` und `'zstd'`) entgegen, und die PR verkabelt die [RFC 8879](https://www.rfc-editor.org/rfc/rfc8879)-Erweiterung durch die OpenSSL-Build-Konfiguration, sodass die Kompressionsprimitiven in das Node.js-Binary gelinkt werden. Der zugehörige Commit `e44b5d487e` aktualisiert die OpenSSL-Build-Konfiguration zur Unterstützung der Kompression; ohne das wäre der OpenSSL-seitige Support nicht auf der Node.js-TLS-Schicht verfügbar. TLS-Zertifikatkompression ist vor allem dann nützlich, wenn die Kette eine große Post-Quanten-Signatur enthält, was derselbe Grund ist, aus dem Chrome und Firefox sie im letzten Jahr ausgerollt haben. Server, die sie auf einer Kette aktivieren, die eine ML-DSA-65- oder ML-DSA-87-Signatur enthält (die primären NIST-FIPS-204-Signaturen), sollten einen merklich kürzeren TLS-Handshake sehen. Die PR ist auch das erste Mal, dass der OpenSSL-Build-Pfad dieselbe TLS-Oberfläche freilegt, die [der BoringSSL-Pfad bereits unterstützt](https://github.com/nodejs/node/pull/63255), was bedeutet, dass ein einzelnes Node.js-Binary dieselbe `certificateCompression`-Option bedienen kann, unabhängig davon, mit welchem TLS-Backend es gebaut wurde. ## `TCP_KEEPINTVL` und `TCP_KEEPCNT` in `setKeepAlive` Die vierte SEMVER-MINOR-Änderung ist die [PR #63825](https://github.com/nodejs/node/pull/63825) (Guy Bedford), die `TCP_KEEPINTVL` und `TCP_KEEPCNT` zu den von `net.Socket.setKeepAlive(enable, initialDelay)` akzeptierten Optionen ergänzt. Vor 26.4.0 akzeptierte `setKeepAlive` nur das Initial-Delay-Argument, und das Intervall zwischen Probes sowie die Anzahl der Probes, bevor die Verbindung als tot deklariert wurde, waren OS-Defaults. Unter Linux sind die Defaults 75 Sekunden zwischen Probes und 9 Probes bis zum Abbruch, was bedeutet, dass eine halboffene Verbindung ~11 Minuten überlebt; unter macOS sind die Defaults ähnlich. Bibliotheksautoren (Datenbanktreiber, Message-Broker, Edge-Runtimes, QUIC-Clients) konnten diese Werte nicht tunen, ohne auf ein natives Modul zurückzugreifen. Mit den neuen Optionen kann der Anwendungscode das Probe-Intervall auf wenige Sekunden und die Anzahl auf eine kleine Zahl verkürzen, was die Konfiguration ist, die Produktions-Datenbanktreiber seit Jahren wollten. Die zugehörige [PR #63951](https://github.com/nodejs/node/pull/63951) (Guy Bedford) ergänzt `net.BoundSocket`, eine synchrone Primitive für frühes TCP-Binding für Codepfade, die einen Port binden müssen, bevor sie an die Event-Loop yielden. Die beiden Stücke sind die ersten substantiellen `net`-Änderungen auf der v26-Current-Linie und gehören zur selben Familie wie die [TCP-Keep-Alive-Arbeit](https://github.com/nodejs/node/pull/63155), die die [Node.js-24.18.0-LTS-Linie](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) ausgeliefert hat. ## Crypto-Stabilisierung, QUIC, dgram und FFI Die übrigen fünf SEMVER-MINOR-Stücke vervollständigen das Bild. Die [PR #63924](https://github.com/nodejs/node/pull/63924) (Filip Skokan) markiert `crypto.argon2` (Argon2id, Argon2i, Argon2d) und `crypto.encap` / `crypto.decap` (Key-Encapsulation für ML-KEM und RSA-OAEP) als stabil. Beide standen seit dem 22.x-Zyklus hinter einem experimentellen Flag, und die Stabilisierung ist die Voraussetzung dafür, dass Bibliotheken ohne die Flags davon abhängen können. Die Release ergänzt außerdem WebCrypto-cSHAKE-Unterstützung ([PR #63988](https://github.com/nodejs/node/pull/63988), Filip Skokan), was die [Web-Crypto-cSHAKE-Arbeit](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) erweitert, die auf der v24-Linie ausgeliefert wurde. `net.BlockList` rückt in den Release-Candidate-Status ([PR #63050](https://github.com/nodejs/node/pull/63050), alphaleadership), der letzte Schritt vor stabil in der nächsten Current-Release. Auf der QUIC-Seite ergänzt die [PR #63536](https://github.com/nodejs/node/pull/63536) (James M. Snell) eine `listEndpoints`-API, und die [PR #63191](https://github.com/nodejs/node/pull/63191) (Tim Perry) ändert den Zertifikats-Accessor so, dass er einen `X509Certificate`-Handle statt des rohen OpenSSL-Handles zurückgibt. `dgram` erhält synchrone `connectSync` und `bindSync` ([PRs #63838](https://github.com/nodejs/node/pull/63838) + [#63932](https://github.com/nodejs/node/pull/63932), Guy Bedford). Die experimentelle Fast-FFI-Arbeit ([PR #63068](https://github.com/nodejs/node/pull/63068) + [PR #63941](https://github.com/nodejs/node/pull/63941), Paolo Insogna) landet für AArch64 und x86_64, wobei die [Folge-PR #63794](https://github.com/nodejs/node/pull/63794) (Stewart X. Addison) dieselbe Maschinerie auf riscv64 portiert. Der Pfad ist hinter `--experimental-ffi` verborgen, und die API wird mindestens einen Current-Zyklus durchlaufen, bevor sie für die LTS-Linie kandidiert. ## Weitere Änderungen in der 26.4.0 Die Release liefert einen langen Schweif kleinerer Änderungen. Die [PR #63634](https://github.com/nodejs/node/pull/63634) (Matteo Collina) ergänzt die Unterstützung vom Aufrufer bereitgestellter Buffer für `fs.readFile` und `fs.readFileSync`, das erste Mal, dass die File-Read-API es dem Aufrufer erlaubt, den Ziel-Buffer zu übergeben, statt Node.js intern allokieren zu lassen. Die [PR #63470](https://github.com/nodejs/node/pull/63470) (semimikoh) sorgt dafür, dass `http.closeIdleConnections` auch Pre-Request-Sockets schließt, was einen echten Bug behebt, bei dem inaktive Keep-Alive-Sockets eine Verbindung offenhielten, nachdem der Request, der sie besaß, abgeschlossen war. npm liefert 11.17.0 ([PR #63857](https://github.com/nodejs/node/pull/63857)), sqlite geht auf 3.53.2, libffi auf 3.6.0 ([PR #64040](https://github.com/nodejs/node/pull/64040)), und acorn auf 8.17.0. Die Release markiert außerdem [Node.js 25 als End-of-Life in der Dokumentation](https://github.com/nodejs/node/pull/63692) und liefert einen langen Stream-Optimierungspatch (Matteo Collina, James M. Snell, Trivikram Kamat), der Allokationen auf den WHATWG-Streams-Hot-Paths reduziert, den Utf8Stream-Stall nach einem vollständigen Schreibvorgang von Multi-Byte-Daten behebt und die `stream/iter`-Backpressure verfeinert. Die zugehörige [PR #62986](https://github.com/nodejs/node/pull/62986) behebt `Writable.toWeb()` `desiredSize` für Non-Object-Mode-Streams, ein langjähriger Bug, der immer dann auftauchte, wenn der WHATWG-Streams-Adapter mit einem binären Stream verwendet wurde. Der vollständige [Node.js-26-Release-Plan](https://github.com/nodejs/release) sieht die Current-Pflege bis Oktober 2026 vor, zu welchem Zeitpunkt v26 in Active LTS eintreten wird. Produktionsnutzer auf der v24-LTS-Linie sollten mindestens das nächste Quartal auf 24.18.0 bleiben (die [Node.js-24.18.0-'Krypton'-LTS-Release](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake), die wir vor zwei Tagen behandelt haben); der v24.19.0-Folgefix wird die experimentelle Arbeit aus 26.x Current aufnehmen, sobald sie sich stabilisiert.