Node.js 26.4.0 'Current', publié le 2026-06-24 à 23 h 38 UTC par @aduh95 avec @aduh95, @targos et @jasnell comme stewards de release, est la deuxième Current release de juin sur la ligne v26 et la plus grosse du cycle depuis la 26.3.0 du 2026-06-01. Elle livre huit changements SEMVER-MINOR : un sous-système node:vfs minimal (Matteo Collina) plus un suivi qui redirige node:fs/promises vers les instances VFS montées (PR #63537), les package maps pour les hooks de loader ESM (Maël Nison, le créateur de Yarn), certificateCompression TLS par-dessus le travail de compression OpenSSL (Tim Perry), TCP_KEEPINTVL et TCP_KEEPCNT dans net.Socket.setKeepAlive (Guy Bedford), les buffers fournis par l'appelant dans fs.readFile (PR #63634, Matteo Collina), closeIdleConnections qui ferme désormais aussi les sockets pre-request (PR #63470, semimikoh), net.BlockList avancé en Release Candidate (PR #63050), et crypto.argon2 ainsi que crypto.encap / crypto.decap marqués stable (PR #63924, Filip Skokan).
La release arrive deux jours après Node.js 24.18.0 'Krypton' (LTS) du 2026-06-23, et le timing est le schéma habituel : la ligne Current porte le travail expérimental qui finit par être backporté en LTS. Le Buffer.poolSize 64 Kio par défaut en est l'exemple canonique, livré sur Current en 26.3.0 le 2026-06-01 et sur LTS en 24.18.0 il y a deux jours. Le sous-système VFS, les package maps pour les loaders ESM, et la compression de certificat TLS sont du même type de travail : suffisamment significatifs pour mériter leur propre Current release, mais encore assez expérimentaux pour ne pas atteindre la ligne v24 LTS avant au moins un cycle de plus.
node:vfs, un nouveau sous-système core
Le changement le plus significatif en termes d'architecture dans la 26.4.0 est le nouveau sous-système node:vfs. La PR #63115 (Matteo Collina) ajoute une couche VFS in-process minimale que le code applicatif peut monter et démonter à l'exécution. Le sous-système expose quatre fonctions : mount(prefix, vfsInstance), unmount(prefix), getMount(prefix) et getMounts(). Le vfsInstance est un objet JavaScript qui implémente une petite interface async (readFile, stat, readdir, plus une poignée d'autres), et Node.js redirige les appels node:fs/promises dont le chemin commence par le préfixe monté vers l'instance plutôt que vers le système de fichiers de l'OS.
Le suivi PR #63537 (Matteo Collina) câble directement la couche dans node:fs/promises. Un appel readFile('/vfs/project/src/index.ts') sur un préfixe monté avec une instance VFS in-memory qui contient l'arborescence du projet renvoie le contenu in-memory sans toucher au disque. L'intégration est la fondation côté runtime pour l'exécution sandboxée : les outils de build peuvent passer à un loader un système de fichiers virtuel qui contient l'arborescence du projet, les plateformes serverless peuvent passer à un handler de requête un système de fichiers virtuel qui ne contient que la portée de la requête, les serveurs de langage d'IDE peuvent passer à une sonde de debugger un système de fichiers virtuel qui contient le fichier en cours de débogage. Les utilisateurs en production sur la ligne v24 LTS ne verront pas cela avant au moins un cycle de release, mais la ligne Current a maintenant la primitive sur laquelle viendra se brancher le prochain round de travail d'outillage.
L'interface de l'instance VFS est volontairement minimale dans cette première coupe. La description de la PR est explicite : les liens symboliques, le file watching et la résolution real-path sont hors scope et arriveront dans les Current releases suivantes. La PR de documentation complémentaire décrit la surface comme « le plus petit VFS viable qui nous permette de remplacer le monkey-patching fs ad-hoc dans l'outillage » et note que l'API passera par au moins un cycle Current avant d'être candidate à la stabilisation.
Package maps pour les hooks de loader ESM
Le deuxième changement architectural est la PR #62239 (Maël Nison), qui implémente les package maps pour les hooks de loader ESM. Le runtime a déjà une map imports de style package.json qui permet au graphe applicatif de résoudre les spécificateurs bruts (#internal/api, lodash/sortBy, react/jsx-runtime) ; les hooks de loader devaient auparavant réimplémenter la lookup de map eux-mêmes parce que la résolution était interne au module loader. La nouvelle API expose la même résolution comme appel de première classe sur les hooks de loader, si bien qu'un loader qui a besoin de savoir si un spécificateur se résout en un chemin remappé (ou en un sous-chemin) peut lire directement le résultat sans parcourir le package.json lui-même.
Pour les auteurs d'outils de build, c'est la pièce manquante pour implémenter des import maps Node.js-compatibles au-dessus d'un bundler. Le spec des import maps définit déjà le format, et les implémentations navigateur livrent des import maps depuis des années. Node.js avait le champ imports sous-jacent depuis la même période, mais l'API des hooks de loader n'a jamais exposé le chemin de résolution que le runtime hôte utilisait ; les auteurs de loaders devaient parcourir le package.json et réimplémenter la map. Maël Nison, qui a authored le package manager Yarn et était le contributeur principal du mécanisme Yarn resolutions, est l'auteur idoine pour ce travail, et la PR est la première fois que les hooks de loader ESM exposent la machinerie des package maps comme API de première classe.
La description de la PR la présente comme le côté hooks de loader du même travail d'import maps que le build.chunkImportMap de Vite 8.1 livre à la couche build-output (couvert dans notre article sur Vite 8.1 stable). Le chunkImportMap de Vite 8.1 est une feature côté bundler qui émet une import map navigateur pour la résolution des URLs de chunks ; les loader package maps de la 26.4.0 sont le côté runtime hôte qu'un bundler viendrait consommer en tournant sous Node.js. Les deux pièces sont indépendamment utiles, mais elles se placent à des couches différentes de la même stack.
Compression de certificat TLS
Le troisième changement SEMVER-MINOR est la PR #62217 (Tim Perry), qui ajoute une option certificateCompression à tls.createSecureContext et https.Server. L'option prend un tableau d'algorithmes de compression ('zlib' et 'zstd'), et la PR câble l'extension RFC 8879 à travers la configuration de build OpenSSL pour que les primitives de compression soient liées au binaire Node.js. Le commit complémentaire e44b5d487e met à jour la configuration de build OpenSSL pour supporter la compression ; sans cela, le support côté OpenSSL ne serait pas disponible à la couche TLS de Node.js.
La compression de certificat TLS est surtout utile quand la chaîne inclut une grande signature post-quantique, ce qui est la raison pour laquelle Chrome et Firefox l'ont déployée ces derniers mois. Les serveurs qui l'activent sur une chaîne contenant une signature ML-DSA-65 ou ML-DSA-87 (les signatures primaires de la NIST FIPS 204) devraient voir un handshake TLS sensiblement plus court. La PR est aussi la première fois que le build path OpenSSL expose la même surface TLS que celle que le chemin BoringSSL supporte déjà, ce qui veut dire qu'un même binaire Node.js peut servir la même option certificateCompression quel que soit le backend TLS avec lequel il a été build.
TCP_KEEPINTVL et TCP_KEEPCNT dans setKeepAlive
Le quatrième changement SEMVER-MINOR est la PR #63825 (Guy Bedford), qui ajoute TCP_KEEPINTVL et TCP_KEEPCNT aux options acceptées par net.Socket.setKeepAlive(enable, initialDelay). Avant la 26.4.0, setKeepAlive n'acceptait que l'argument de délai initial, et l'intervalle entre probes ainsi que le nombre de probes avant qu'une connexion soit déclarée morte étaient les défauts OS. Sur Linux les défauts sont 75 secondes entre probes et 9 probes avant drop, ce qui veut dire qu'une connexion à moitié ouverte survit ~11 minutes ; sur macOS les défauts sont similaires. Les auteurs de bibliothèques (drivers de bases de données, brokers de messages, runtimes edge, clients QUIC) ne pouvaient pas tuner ces valeurs sans tomber sur un module natif.
Avec les nouvelles options, le code applicatif peut raccourcir l'intervalle entre probes à quelques secondes et le nombre à un petit chiffre, qui est la configuration que les drivers de bases de données en production réclamaient depuis des années. La PR #63951 complémentaire (Guy Bedford) ajoute net.BoundSocket, une primitive synchrone de binding TCP précoce pour les chemins de code qui ont besoin de binder un port avant de yield l'event loop. Les deux pièces sont les premiers changements net substantiels sur la ligne v26 Current et s'inscrivent dans la même famille que le travail TCP keep-alive que la ligne v24.18.0 LTS a livré.
Stabilisation crypto, QUIC, dgram et FFI
Les cinq autres pièces SEMVER-MINOR complètent le tableau. La PR #63924 (Filip Skokan) marque crypto.argon2 (Argon2id, Argon2i, Argon2d) et crypto.encap / crypto.decap (encapsulation de clé pour ML-KEM et RSA-OAEP) comme stable. Les deux étaient derrière un drapeau expérimental depuis le cycle 22.x, et la stabilisation est le prérequis pour que des bibliothèques puissent en dépendre sans les flags. La release ajoute aussi le support WebCrypto cSHAKE (PR #63988, Filip Skokan), qui étend le travail cSHAKE Web Crypto livré sur la ligne v24.
net.BlockList passe en Release Candidate (PR #63050, alphaleadership), la dernière étape avant stable dans la prochaine Current release. Côté QUIC, la PR #63536 (James M Snell) ajoute une API listEndpoints et la PR #63191 (Tim Perry) change l'accesseur de certificat pour renvoyer un handle X509Certificate au lieu du handle OpenSSL brut. dgram reçoit connectSync et bindSync synchrones (PRs #63838 + #63932, Guy Bedford).
Le travail expérimental fast FFI (PR #63068 + PR #63941, Paolo Insogna) arrive pour AArch64 et x86_64, avec la PR #63794 de suivi (Stewart X Addison) qui porte la même machinerie sur riscv64. Le chemin est gardé derrière --experimental-ffi et l'API passera par au moins un cycle Current avant d'être candidate à la ligne LTS.
Autres changements dans la 26.4.0
La release livre une longue traîne de changements plus petits. La PR #63634 (Matteo Collina) ajoute le support de buffer fourni par l'appelant à fs.readFile et fs.readFileSync, la première fois que l'API de lecture de fichier laisse l'appelant passer le buffer destination au lieu de laisser Node.js allouer en interne. La PR #63470 (semimikoh) fait que http.closeIdleConnections ferme aussi les sockets pre-request, corrigeant un vrai bug où des sockets keep-alive idle restaient ouvertes après que la requête qui les possédait s'était terminée.
npm livre la 11.17.0 (PR #63857), sqlite passe en 3.53.2, libffi en 3.6.0 (PR #64040), et acorn en 8.17.0. La release marque aussi Node.js 25 comme End-of-Life dans la doc et livre un long patch d'optimisation stream (Matteo Collina, James M Snell, Trivikram Kamat) qui réduit les allocations sur les chemins chauds WHATWG streams, corrige le stall Utf8Stream après une écriture complète de données multi-octets, et raffine la backpressure stream/iter. La PR #62986 complémentaire corrige le desiredSize de Writable.toWeb() pour les streams en non-object-mode, un vieux bug qui se manifestait dès que l'adaptateur WHATWG streams était utilisé avec un stream binaire.
Le calendrier de release Node.js 26 complet prévoit la maintenance Current jusqu'en octobre 2026, date à laquelle la v26 entrera en Active LTS. Les utilisateurs en production sur la ligne v24 LTS doivent rester sur la 24.18.0 (la release Node.js 24.18.0 'Krypton' LTS que nous avons couverte il y a deux jours) pour au moins le prochain trimestre ; le suivi v24.19.0 reprendra le travail expérimental de la Current 26.x à mesure qu'il se stabilisera.
