---
title: "Node.js 24.18.0 'Krypton' LTS : Buffer.poolSize à 64 Kio, TurboSHAKE et KangarooTwelve dans Web Crypto, et http.writeInformation pour les codes 1xx arbitraires"
description: "Node.js 24.18.0 'Krypton' (LTS), publié le 2026-06-23, embarque la valeur par défaut Buffer.poolSize à 64 Kio déjà livrée sur Current par la 26.3.0, ajoute à Web Cryptography les algorithmes TurboSHAKE et KangarooTwelve de la RFC 9861 (PR #62183, 1 521 ajouts, 13 fichiers), expose http.writeInformation pour envoyer des codes 1xx arbitraires (PR #63155, 306 ajouts, 7 fichiers), rend accessible au runtime JS le démarrage de la couverture précise de V8 (commit 8c989ec4a3), ajoute l'import-export JWK pour les types de clés post-quantiques ML-KEM et SLH-DSA (PR #62706, 842 ajouts, 39 fichiers), câble en BoringSSL ML-DSA, ML-KEM, ChaCha20-Poly1305 et AES-KW pour Web Crypto (PR #63255), durcit WebCrypto contre la pollution de prototype (PR #63363), aligne les noms d'arguments de clé de crypto.diffieHellman et accepte des données de clé en entrée (PR #62527), annule le comportement 'stream: noop pause/resume on destroyed streams' de la 24.16.0 (PR #63834), et publie dans la foulée un correctif minimal 22.23.1 qui revient sur un changement d'agent http introduit dans la release de sécurité 06-18 et qui rattachait des listeners de stream sur les sockets idle."
date: 2026-06-24
image: "/images/heroes/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake.png"
author: lschvn
tags: ["runtimes", "security", "performance"]
tldr:
  - "Node.js 24.18.0 'Krypton' (LTS), publié le 2026-06-23 par @richardlau, préparé par @sxa, est la première release LTS v24 de juin et la plus grosse du cycle depuis la 24.0.0. C'est la première release de la ligne LTS à embarquer la valeur par défaut [Buffer.poolSize 64 Kio apparue sur Current dans la 26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) (PR #63597, Matteo Collina), que la PR d'origine mesurait à +26 % sur des charges fs.readFileSync de 8 Kio et +23 % sur 16 Kio, et elle apporte huit changements SEMVER-MINOR couvrant crypto, http, inspector et stream."
  - "La release ajoute à Web Cryptography TurboSHAKE et KangarooTwelve de la [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html) (PR #62183, 1 521 ajouts, 13 fichiers), en cohérence avec le draft [WICG webcrypto-modern-algos](https://wicg.github.io/webcrypto-modern-algos/). L'implémentation est un port direct de la primitive keccak1600 d'OpenSSL, livrée derrière le drapeau d'algorithme instable jusqu'à ce qu'OpenSSL supporte nativement ces algorithmes, date à laquelle ils passeront en stable dans `node:crypto`."
  - "Autres travaux marquants : `http.writeInformation` expose une API HTTP/1 générique pour les codes 1xx arbitraires, calquée sur `additionalHeaders` côté HTTP/2 (PR #63155, Tim Perry) ; WebCrypto gagne l'import-export JWK pour les types de clés post-quantiques ML-KEM et SLH-DSA (PR #62706, 842 ajouts, 39 fichiers) ; le build BoringSSL câble désormais ML-DSA, ML-KEM, ChaCha20-Poly1305 et AES-KW (PR #63255) ; et le changement 'stream: noop pause/resume on destroyed streams' de la 24.16.0 est annulé après des casses en production (PR #63834). Le même schéma de correctif sort le même jour en 22.23.1, qui revient sur un changement d'agent http de la release de sécurité v22.23.0 du 06-18 et qui rattachait des listeners de stream sur les sockets idle."
faq:
  - question: "Quel est le changement phare de Node.js 24.18.0 'Krypton' ?"
    answer: "Il y a trois chantiers principaux, selon la surface qui vous concerne. Pour les performances d'exécution, la [valeur par défaut Buffer.poolSize à 64 Kio](https://github.com/nodejs/node/pull/63597) (Matteo Collina) est le titre : elle supprime la falaise des 4 Kio dans l'allocateur slab, où l'inégalité stricte `size < (poolSize >>> 1)` faisait qu'une allocation de 4 Kio ratait elle-même le pool, et étend la couverture du pool aux allocations jusqu'à 32 Kio. La PR mesurait +10 % à +26 % sur des charges fs.readFileSync de 4 à 16 Kio. Pour la crypto, la [PR #62183](https://github.com/nodejs/node/pull/62183) ajoute à Web Cryptography TurboSHAKE et KangarooTwelve de la [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html), la première nouvelle famille de hash livrée par le runtime depuis des années. Pour HTTP, la [PR #63155](https://github.com/nodejs/node/pull/63155) ajoute `response.writeInformation` pour les codes 1xx arbitraires, en remplacement du contournement privé `res._writeRaw` sur lequel les auteurs de proxy s'appuyaient depuis des années."
  - question: "Pourquoi le changement de Buffer.poolSize est-il un backport, et quel est l'impact en performance ?"
    answer: "Le changement de la PR #63597 a d'abord été livré sur la ligne Current dans [Node.js 26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) le 2026-06-01. La valeur par défaut était 8 Kio depuis mai 2015, ce qui prédate les tailles de trame HTTP/2, les tailles modernes de chunk de stream, et la croissance d'environ 10x de la RAM typique citée par la description de la PR. Le test du pool slab est `size < (Buffer.poolSize >>> 1)`, ce qui veut dire qu'avec la valeur par défaut de 8 Kio le seuil est de 4 Kio et qu'une allocation de 4 Kio manque elle-même le pool. La nouvelle valeur par défaut de 64 Kio étend la couverture du pool aux allocations jusqu'à ~32 Kio. Le benchmark de la PR sur fs.readFileSync, mesuré sur 8 workers, montre +10 % à 4 Kio, +26 % à 8 Kio, +23 % à 16 Kio, et les fichiers de 1 Mio ne sont pas affectés. La plupart des utilisateurs en production sur la ligne v24 LTS verront ce gain gratuitement en mettant à jour."
  - question: "Qu'est-ce que TurboSHAKE et KangarooTwelve, et pourquoi leur arrivée dans Node.js est-elle importante ?"
    answer: "TurboSHAKE et KangarooTwelve sont des fonctions de hachage à sortie extensible (XOF) définies dans la [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html), basées sur la même famille de permutations Keccak que SHA-3 et SHAKE. Elles sont plus rapides que SHAKE sur les messages longs et les digests courts de longueur fixe, et KangarooTwelve est le mode tree-hash recommandé par l'IETF pour les applications à haut débit. L'écosystème navigateur suit le même draft via la proposition [WICG webcrypto-modern-algos](https://wicg.github.io/webcrypto-modern-algos/). La PR #62183 ajoute les deux à l'implémentation Web Cryptography de Node.js en utilisant directement les primitives keccak1600 d'OpenSSL ; le travail est protégé par le drapeau unstable jusqu'à ce qu'OpenSSL livre un support natif, date à laquelle il passera en stable dans `node:crypto`. C'est l'une des premières fois que Node.js livre un algorithme Web Crypto avant la release OpenSSL qui le supporte."
  - question: "Que change http.writeInformation pour les auteurs de proxy et d'API ?"
    answer: "Avant la 24.18.0, HTTP/1 n'exposait aucune API publique pour envoyer des codes 1xx arbitraires. Le runtime exposait `res.writeContinue` pour le 100 et `res.writeEarlyHints` pour le 103, et c'était tout ; toute personne ayant besoin d'un 1xx personnalisé ou écrivant un proxy qui devait relayer un 1xx de l'upstream devait passer par la méthode privée `res._writeRaw`, ce que la description de la PR souligne comme étant une pratique utilisée par la propre suite de tests de Node.js. La PR #63155 ajoute `response.writeInformation({ status, headers })`, une API HTTP/1 générique qui reprend la forme de `additionalHeaders` côté HTTP/2 et qui supporte tout code 1xx sauf 101 (qui change de protocole et reste géré par l'événement `upgrade`). Les `writeContinue` et `writeEarlyHints` existants sont refactorés au-dessus de la nouvelle méthode. La branche H1 lève une exception si un statut final a déjà été envoyé ; la branche H2 est un no-op. Les auteurs de proxy disposent d'une seule API qui marche pour les codes définis par l'IETF, les 1xx personnalisés et tout futur 1xx standardisé, sans avoir besoin d'une méthode par statut."
  - question: "Qu'est-ce que le support JWK post-quantique dans Web Crypto ?"
    answer: "La [PR #62706](https://github.com/nodejs/node/pull/62706) (842 ajouts, 39 fichiers, par Filip Skokan) ajoute l'import-export JSON Web Key (JWK) pour les familles de clés post-quantiques [ML-KEM](https://csrc.nist.gov/pubs/fips/203/ipd) (anciennement Kyber) et [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/ipd) (anciennement Sphincs+), toutes deux sélectionnées par le NIST dans les FIPS 203 et 205. Les formats JWK suivent les drafts du [LAMPS WG de l'IETF](https://datatracker.ietf.org/wg/lamps/about/) et les enregistrements JOSE. Combiné au câblage ML-KEM et SLH-DSA que le durcissement crypto de Node.js 26 (PR #63255) a déjà mis dans `node:crypto`, la partie Web Cryptography est désormais alignée avec le travail post-quantique que la ligne 26.x porte depuis plusieurs mois. Le build BoringSSL gagne en plus ChaCha20-Poly1305, AES-KW, ML-DSA et ML-KEM dans Web Crypto (PR #63255), si bien qu'un même binaire Node.js peut désormais servir des JWK RSA, ECDSA, ML-KEM, ML-DSA et SLH-DSA dans le même namespace Web Crypto."
  - question: "Pourquoi le 'stream: noop pause/resume on destroyed streams' de la 24.16.0 a-t-il été annulé ?"
    answer: "La [PR #63834](https://github.com/nodejs/node/pull/63834) (Stewart X Addison) annule le changement qui avait été livré dans la 24.16.0 le 2026-05-21 et qui rendait `pause()` et `resume()` no-op sur les streams détruits. L'intention était de rendre le nettoyage des streams plus idempotent, mais des pipelines HTTP et de spawn de processus réels s'appuyaient sur le fait que `pause()` reste un no-op-puis-clean même après destroy, et le changement produisait des erreurs 'Cannot call method on destroyed stream' sur des chemins de code qui étaient corrects auparavant. L'annulation est commitée sur la ligne v24 LTS le même jour, et un suivi dans [Node.js 22.23.1](https://github.com/nodejs/node/releases/tag/v22.23.1) (aussi le 2026-06-23) revient sur le changement d'agent http introduit dans la release de sécurité v22.23.0 deux semaines plus tôt, qui rattachait des listeners de stream sur les sockets idle de l'agent. Les deux annulations sont sans rapport au niveau API mais sortent ensemble parce qu'elles ont toutes les deux été détectées en production la même semaine."
  - question: "Que contient le travail QUIC de cette release ?"
    answer: "La [PR #63267](https://github.com/nodejs/node/pull/63267) (James M Snell) livre un patch multi-commits d'améliorations QUIC par-dessus le travail libuv qui a été progressivement livré sur la v24 ces deux dernières releases. Le changement visible est la nouvelle option `reusePort` sur `QuicEndpoint`, qui permet à plusieurs processus Node.js de se lier au même port UDP pour distribuer la charge des connexions, et le travail de rate-limiting sur les chemins de version-negotiation et d'immediate-close du QUIC. La description de la PR cite un gain d'environ 10 % en rps lié aux changements de packet handling, et prépare le suivi libuv PR #5116 sur le reuse-port qui est attendu dans une 24.x ultérieure. Le changement s'inscrit dans la même famille que le travail QUIC livré en 24.16.0 et 24.17.0 ; les utilisateurs qui font tourner Node.js comme serveur QUIC en production verront des gains incrémentaux réguliers sur la ligne LTS."
  - question: "Que change la 22.23.1 livrée en parallèle de la 24.18.0 ?"
    answer: "[Node.js 22.23.1 'Jod' (LTS)](https://github.com/nodejs/node/releases/tag/v22.23.1), publiée le même jour à 16 h 44 UTC par @RafaelGSS, est un suivi à deux commits de la release de sécurité v22.23.0 du 06-18. Le premier commit, [41d2ee13be](https://github.com/nodejs/node/commit/41d2ee13be), bascule le job de coverage Windows de la v22 sur `windows-2022` (PR #63940, Richard Lau). Le second, [eaa292549e](https://github.com/nodejs/node/commit/eaa292549e), est le même correctif d'agent http idle-socket que celui livré en 24.18.0 (PR #64004, Matteo Collina) : la release de sécurité v22.23.0 avait ajouté un listener de stream sur les sockets idle de l'agent, ce qui produisait en production un comportement inattendu de 'stream listener sur socket idle' côté clients HTTP. Les utilisateurs de la 22.23.0 doivent passer en 22.23.1 ; les utilisateurs de la 24.17.0 doivent passer en 24.18.0."
  - question: "Y a-t-il des changements cassants dans Node.js 24.18.0 ?"
    answer: "Deux changements de comportement explicitement signalés dans les notes de release. Premièrement, la valeur par défaut Buffer.poolSize à 64 Kio est un changement de comportement : les applications qui benchmarkent l'allocateur lui-même verront des chiffres différents, et un petit nombre de processus longue durée qui s'appuyaient sur la falaise des 4 Kio pour leur accounting mémoire verront une mémoire steady-state légèrement plus élevée. Deuxièmement, l'annulation de 'stream: noop pause/resume on destroyed streams' restaure la sémantique d'avant la 24.16.0, ce qui veut dire que le code qui avait été adapté pour contourner le comportement de la 24.16.0 doit retirer ses contournements. Les changements crypto sont additifs : TurboSHAKE, KangarooTwelve, ML-KEM et SLH-DSA JWK sont de nouveaux algorithmes et ne modifient le comportement d'aucun algorithme existant. Hmac.digest() est ajoutée à la liste des dépréciations documentées sous le code DEP0206 (PR #63121), ce qui n'est pas une cassure runtime mais signale que l'API est en cours de retrait."
  - question: "Quel est le chemin de mise à jour depuis les releases précédentes de la ligne v24 LTS ?"
    answer: "Les utilisateurs sur v24.17.0 (2026-06-18) doivent passer en v24.18.0 ; les nouvelles fonctionnalités et l'annulation du changement stream en sont les raisons. Les utilisateurs sur v24.16.0 doivent passer directement en v24.18.0 pour récupérer l'annulation du stream en une étape. Les utilisateurs sur v24.0.0 à v24.15.0 doivent passer en v24.18.0 pour récupérer l'ensemble du cycle v24 plus le travail Buffer pool et crypto ; la ligne v24 est l'Active LTS actuelle, et le [calendrier de release Node.js 24](https://github.com/nodejs/release) prévoit la maintenance Active LTS jusqu'en octobre 2027. La release embarque aussi une mise à jour de `npm` vers 11.16.0 (PR #63602), un bump de `simdjson` vers 4.6.4 (PR #62811), un bump de `sqlite` vers 3.53.1 (PR #63217) et un cherry-pick V8 (commit 6e56f01c4b)."
---

[Node.js 24.18.0 'Krypton' (LTS)](https://github.com/nodejs/node/releases/tag/v24.18.0), publiée le 2026-06-23 à 23 h 11 UTC par @richardlau et préparée par @sxa, est la plus grosse release de la ligne v24 LTS depuis que cette ligne est passée en Active en octobre 2025. Elle livre huit changements SEMVER-MINOR : la valeur par défaut [Buffer.poolSize à 64 Kio](https://github.com/nodejs/node/pull/63597) backportée depuis Current, [TurboSHAKE et KangarooTwelve](https://github.com/nodejs/node/pull/62183) de la RFC 9861 ajoutés à Web Cryptography, [http.writeInformation](https://github.com/nodejs/node/pull/63155) pour les codes 1xx arbitraires, le démarrage de la [couverture précise de V8](https://github.com/nodejs/node/commit/8c989ec4a3) exposé au runtime JS, et l'import-export JWK pour les familles de clés post-quantiques [ML-KEM](https://github.com/nodejs/node/pull/62706) et SLH-DSA. Le même jour, [Node.js 22.23.1 'Jod' (LTS)](https://github.com/nodejs/node/releases/tag/v22.23.1) livre un suivi à deux commits de la release de sécurité v22.23.0 du 06-18, qui revient sur un changement d'agent http ayant déclenché un comportement inattendu de re-stream côté clients HTTP en production.

La release arrive sur la ligne LTS la même semaine que les [releases de sécurité Node.js de juin 2026](https://nodejs.org/en/blog/vulnerability/june-2026-security-releases/), et le timing est volontaire : la release de sécurité a corrigé 14 CVE sur v18, v20, v22 et v24 le 2026-06-18 (couvertes dans [notre précédent article sur la sécurité Node.js](/articles/2026-06-18--node-js-june-2026-security-releases)), et la 24.18.0 est la prochaine release de fonctionnalité sur la ligne v24 que les utilisateurs en production peuvent absorber en une étape. Le correctif de suivi en v22.23.1 est la seconde moitié de la même semaine, puisque le fix de la v22.23.0 a produit un comportement stream inattendu en charge réelle et que l'équipe a choisi de revenir dessus en v22.23.1 plutôt que d'attendre la v22.24.0.

## Buffer.poolSize : la valeur par défaut passe à 64 Kio

Le changement d'exécution le plus impactant est la hausse de la valeur par défaut `Buffer.poolSize` de 8 Kio à 64 Kio, contribué par Matteo Collina ([#63597](https://github.com/nodejs/node/pull/63597), 7 ajouts, 2 fichiers). Le test du pool slab est `size < (Buffer.poolSize >>> 1)`, ce qui veut dire qu'avec la valeur par défaut de 8 Kio le seuil est de 4 Kio et que l'inégalité stricte fait qu'une allocation de 4 Kio manque elle-même le pool. La valeur par défaut actuelle aide les allocations de 1 octet à 3 999 octets, puis s'arrête brutalement à la frontière alignée sur la page et dimensionnée pour les trames HTTP, où tombent pourtant de nombreuses allocations réelles.

La description de la PR cite trois raisons au changement. La falaise des 4 Kio est la première. La deuxième est que la valeur par défaut est 8 Kio depuis [mai 2015](https://github.com/nodejs/node/commit/63da0dfd3a4460e117240e84b57af2137469497e), ce qui prédate les tailles de trame 16 Kio à 1 Mio de HTTP/2, les tailles modernes de chunk de stream, et la croissance d'environ 10x de la RAM typique. La troisième est que de nombreux appels à `Buffer.allocUnsafe` dans le core (`fs.readFileSync` pour les lectures non-utf8, le parseur HTTP, les chunkers de stream) tombent dans la fourchette 4 Kio à 64 Kio et manquent le pool.

Le benchmark de la PR, exécuté sur 8 threads worker dans un même process sous Linux 6.8 avec glibc 2.39 sur un i7-7700, donne :

| Taille de fichier | pool 8 Kio (défaut) | pool 64 Kio | Δ |
|---:|---:|---:|:---:|
| 512 B | 404k ops/s | 431k ops/s | +7 % |
| 2 Kio | 360k ops/s | 367k ops/s | ~ |
| 4 Kio | 326k ops/s | 360k ops/s | +10 % |
| 8 Kio | 202k ops/s | 254k ops/s | +26 % |
| 16 Kio | 148k ops/s | 181k ops/s | +23 % |
| 64 Kio | 86k ops/s | 87k ops/s | ~ |
| 1 Mio | 8,7k ops/s | 8,6k ops/s | ~ |

La nouvelle valeur par défaut de 64 Kio étend la couverture du pool aux allocations jusqu'à ~32 Kio. C'est la première fois que la valeur par défaut bouge depuis 2015. Le changement n'est pas cassant, il n'affecte que la valeur par défaut, et les applications peuvent toujours définir `Buffer.poolSize` manuellement. Le même changement a déjà été livré sur la ligne Current dans [Node.js 26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) le 2026-06-01 ; la 24.18.0 est la première fois qu'il arrive sur la ligne LTS. Le titre du précédent article est désormais aussi le titre de celui-ci pour les utilisateurs de la v24.

## Web Cryptography gagne TurboSHAKE et KangarooTwelve

Le second titre est l'ajout de [TurboSHAKE et KangarooTwelve](https://github.com/nodejs/node/pull/62183) (PR #62183, 1 521 ajouts, 13 fichiers, Filip Skokan) à l'API Web Cryptography. Les deux sont des fonctions de hachage à sortie extensible de la même famille de permutations Keccak que SHA-3 et SHAKE, standardisées dans la [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html). Elles sont plus rapides que SHAKE sur les messages longs et les digests courts de longueur fixe ; KangarooTwelve est le mode tree-hash recommandé par l'IETF pour les applications à haut débit, et l'écosystème navigateur suit le même draft via la proposition [WICG webcrypto-modern-algos](https://wicg.github.io/webcrypto-modern-algos/).

L'implémentation Node.js est un port direct des primitives keccak1600 d'OpenSSL. Le travail est protégé par le drapeau unstable jusqu'à ce qu'OpenSSL livre un support natif pour les deux primitives ; à ce moment, les algorithmes passeront en stable dans `node:crypto` et la porte Web Crypto sera levée. La PR est l'une des premières fois que Node.js livre un algorithme Web Crypto avant la release OpenSSL qui le supporte, et le ticket amont [openssl/openssl#30304](https://redirect.github.com/openssl/openssl/issues/30304) est le tracker qui commandera la stabilisation.

La release livre aussi un durcissement multi-PR de la stack Web Cryptography. La [PR #63363](https://github.com/nodejs/node/pull/63363) (Filip Skokan) durcit WebCrypto contre la pollution de prototype, refactore le chemin async vers un nouveau mode interne `CryptoJob`, passe directement les handles `CryptoKey` aux jobs KDF, et retire le mot-clé `async` des méthodes Web Crypto là où le travail est en fait synchrone en dessous. La [PR #63255](https://github.com/nodejs/node/pull/63255) (Filip Skokan) câble le build BoringSSL pour que ML-DSA, ML-KEM, ChaCha20-Poly1305 et AES-KW soient disponibles dans Web Cryptography quand Node.js est compilé contre BoringSSL. La [PR #63111](https://github.com/nodejs/node/pull/63111) resserre les slots d'algorithme `CryptoKey` et les slots internes `KeyObject` pour que les deux types ne puissent pas accidentellement partager d'état.

## Support JWK post-quantique pour ML-KEM et SLH-DSA

La [PR #62706](https://github.com/nodejs/node/pull/62706) (842 ajouts, 39 fichiers, Filip Skokan) ajoute l'import-export JSON Web Key pour les familles de clés post-quantiques [ML-KEM](https://csrc.nist.gov/pubs/fips/203/ipd) (anciennement Kyber) et [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/ipd) (anciennement Sphincs+), toutes deux sélectionnées par le NIST dans les FIPS 203 et 205. Les formats JWK suivent les drafts du [LAMPS WG de l'IETF](https://datatracker.ietf.org/wg/lamps/about/) et les enregistrements JOSE.

Combiné au câblage ML-KEM et ML-DSA côté BoringSSL de la PR #63255, la partie Web Cryptography de Node.js est désormais alignée avec le travail post-quantique que la ligne Current porte depuis le début du cycle 26.x. Un même binaire Node.js peut désormais servir des JWK RSA, ECDSA, Ed25519, ML-KEM, ML-DSA et SLH-DSA dans le même namespace Web Crypto, ce qui compte pour le déploiement en production du TLS post-quantique : le même namespace `crypto.subtle` qu'un serveur utilise pour vérifier une signature RSA peut désormais vérifier une signature ML-DSA, et le même chemin `importKey` / `exportKey` qui gère un JWK P-256 peut désormais gérer un JWK ML-KEM-768.

La [PR #62905](https://github.com/nodejs/node/pull/62905) ajoute un garde séparé contre les `key_ops` JWK ML-KEM dupliqués, qui est le genre de cas limite qui remonte dans les tests d'interop avec les implémentations navigateur. La [PR #62626](https://github.com/nodejs/node/pull/62626) est un fix plus petit qui protège d'un overflow `size_t` sur l'architecture 32 bits expérimentale ; le changement s'inscrit dans la même famille que les fixes 64 bits livrés en 24.15.0.

## `http.writeInformation` pour les codes 1xx arbitraires

La [PR #63155](https://github.com/nodejs/node/pull/63155) (306 ajouts, 7 fichiers, Tim Perry) ajoute `response.writeInformation({ status, headers })`, une API HTTP/1 générique pour envoyer des codes 1xx arbitraires. Le runtime exposait auparavant `res.writeContinue` pour le 100 et `res.writeEarlyHints` pour le 103, et c'était tout ; toute personne ayant besoin d'un 1xx personnalisé ou écrivant un proxy qui devait relayer un 1xx de l'upstream devait passer par la méthode privée `res._writeRaw`, ce que la description de la PR signale comme étant une pratique utilisée par la propre suite de tests de Node.js.

La nouvelle méthode reprend la forme de `additionalHeaders` côté HTTP/2 et supporte tout code 1xx sauf 101, qui change de protocole et reste géré par l'événement `upgrade`. Les `writeContinue` et `writeEarlyHints` existants sont refactorés au-dessus de la nouvelle méthode. Il y a une incohérence que la PR conserve en l'état : la branche H1 lève une exception si un statut final a déjà été envoyé, alors que la branche H2 est un no-op. La description de la PR signale cette incohérence comme candidate à un alignement dans un futur bump majeur.

Le fix clôt trois issues anciennes, [#22624](https://github.com/nodejs/node/issues/22624), [#27921](https://github.com/nodejs/node/issues/27921) et [#7588](https://github.com/nodejs/node/issues/7588), qui avaient été fermées en stale au fil des années faute d'API générale. Les auteurs de proxy disposent désormais d'une seule API qui marche pour les codes définis par l'IETF, les 1xx personnalisés et tout futur 1xx standardisé, sans avoir besoin d'une méthode par statut.

## Couverture précise V8 exposée au runtime JS

Le [travail de couverture précise inspector](https://github.com/nodejs/node/commit/8c989ec4a3) (commit 8c989ec4a3, sangwook, SEMVER-MINOR) est le plus petit titre de la release en nombre de lignes et le plus utile pour quiconque fait tourner de la couverture sur la ligne v24 LTS. Le changement expose le signal de démarrage de la couverture précise de V8 au runtime JS via un nouveau binding interne, si bien que `node:inspector` et le test runner peuvent tous les deux démarrer la couverture précise au runtime plutôt que seulement au bootstrap via `NODE_V8_COVERAGE` ou `--experimental-test-coverage`.

La PR complémentaire [#63079](https://github.com/nodejs/node/pull/63079) (sangwook) câble la même primitive dans l'API `run()` du test runner : `run({ coverage: true, isolation: 'none' })` collecte maintenant correctement la couverture, et l'exclusion par défaut des fichiers de test est appliquée de manière cohérente entre la voie CLI et la voie API. La PR corrige un vrai bug dans `test_runner` où la voie API renvoyait une liste de fichiers vide parce que le drapeau de couverture V8 n'était positionné qu'au bootstrap.

Le changement fait partie du même travail de couverture précise qui a été livré progressivement en 24.16.0 et 24.17.0 ; la pièce 24.18.0 est l'exposition finale qui permet au code applicatif de démarrer la couverture à la demande. Pour les utilisateurs qui font tourner `c8` ou `nyc` sur la ligne v24, cela veut dire que le chemin de couverture du test runner est désormais de première classe sur LTS.

## L'annulation stream et le suivi v22.23.1

La release annule un changement de la 24.16.0 : la [PR #63834](https://github.com/nodejs/node/pull/63834) (Stewart X Addison) revient sur le changement 'stream: noop pause/resume on destroyed streams' livré le 2026-05-21. L'intention était de rendre le nettoyage des streams plus idempotent, mais des pipelines HTTP et de spawn de processus réels s'appuyaient sur le fait que `pause()` reste un no-op-puis-clean même après destroy, et le changement produisait des erreurs 'Cannot call method on destroyed stream' sur des chemins de code qui étaient corrects avant le changement.

Le même jour, [Node.js 22.23.1](https://github.com/nodejs/node/releases/tag/v22.23.1) (16 h 44 UTC, @RafaelGSS) livre un suivi connexe : la [PR #64004](https://github.com/nodejs/node/pull/64004) (Matteo Collina) revient sur le changement d'agent http de la release de sécurité v22.23.0, qui ajoutait un listener de stream sur les sockets idle de l'agent et produisait en production un comportement inattendu de re-stream côté clients HTTP. Les utilisateurs de la 22.23.0 doivent passer en 22.23.1 ; le fix arrive en 24.18.0 au même moment, donc les utilisateurs de la 24.17.0 doivent passer en 24.18.0 pour récupérer à la fois l'annulation stream et l'annulation agent.

Les deux annulations sont sans rapport au niveau API mais sortent ensemble parce qu'elles ont toutes les deux été détectées en production la même semaine. Le [calendrier de release Node.js 22](https://github.com/nodejs/release) place la 22.x en Maintenance LTS jusqu'en octobre 2026, et le choix de l'équipe d'émettre un correctif 22.23.1 une semaine après plutôt que d'attendre la 22.24.0 reflète le fait que les branches LTS servent désormais de cibles de production pour des services longue durée.

## Ce que la 24.18.0 ne change pas

La release ne change pas la version majeure de V8, la version majeure de libuv ni l'API publique des addons. La surface Node-API récupère la [PR #62710](https://github.com/nodejs/node/pull/62710) (Yilong Li), qui ajoute le support `SharedArrayBuffer` à `napi_create_typedarray`, un fix petit mais réel pour les modules natifs qui veulent exposer des vues `SharedArrayBuffer` à JS. Les propriétés `Date` de `fs.Stats` deviennent énumérables ([PR #63328](https://github.com/nodejs/node/pull/63328), Livia Medeiros), un fix ancien qui finit par s'aligner avec la spec. SQLite passe en 3.53.1 ([PR #63217](https://github.com/nodejs/node/pull/63217)), `simdjson` en 4.6.4 ([PR #62811](https://github.com/nodejs/node/pull/62811)), et `npm` en 11.16.0 ([PR #63602](https://github.com/nodejs/node/pull/63602)). La release inclut aussi la [PR #62612](https://github.com/nodejs/node/pull/62612), qui ajoute les fichiers des assistants IA au `.gitignore` du repo ; un petit changement méta qui est en soi un signal de l'idée que se font les mainteneurs Node.js de la prochaine génération d'outillage contributeur.

Le calendrier complet de la ligne Node.js 24 LTS prévoit la maintenance Active LTS jusqu'en octobre 2027 et la Maintenance LTS jusqu'en octobre 2028. La 24.18.0 est la deuxième release de juin sur la ligne v24 et la première à livrer le travail Buffer pool et JWK post-quantique qui s'accumulait sur Current depuis deux mois.