Une montée de version Node.js a l'air calme jusqu'à ce qu'une dépendance appelle une API que le nouvel environnement a retirée. La version 26, entrée en support à long terme en octobre 2026, est de ces versions. Elle active une meilleure façon de traiter les dates, rafraîchit le moteur JavaScript et le client HTTP, et supprime d'anciennes surfaces. Les équipes britanniques qui font tourner des services en production sur Node devraient la traiter comme un changement planifié, pas comme un numéro dans un Dockerfile.
La version est disponible depuis mai. Le support long est le moment où beaucoup d'entreprises l'autorisent en production. C'est le bon moment pour avoir déjà fait tourner l'application, les modules natifs et la construction dans un environnement de préproduction qui ressemble au vrai.
Ce qui est sorti le 5 mai 2026
Node.js 26 est sorti le 5 mai 2026. Il active l'API Temporal par défaut, met le moteur JavaScript V8 à la version 14.6, et fait passer Undici, le client HTTP de Node, à la version 8. La version retire ou déprécie aussi d'anciennes API. L'historique des versions de Node confirme quelles lignes sont encore supportées, et la note sur le calendrier de versions explique comment le projet attend que les équipes passent d'une version à l'autre.
Node.js a indiqué que la version 26 entrerait en support à long terme en octobre 2026. Pour une entreprise britannique, le support long est la voie de production sensée, parce que c'est la ligne qui reçoit des correctifs plus longtemps. Ce n'est pas une promesse que du code écrit pour Node 20 ou 22 tournera sans changement. Les notes de version sont la liste de compatibilité. Un journal parcouru pour le mot « fonctionnalité » et pas pour « retiré » est la façon dont les montées de version surprennent un vendredi.
Temporal est une façon plus claire de parler du temps
Temporal est un ensemble moderne d'API de date et d'heure, pensé comme une alternative plus solide à l'objet Date de JavaScript. Le traitement des dates est délicat parce que les applications mélangent fuseaux, dates de calendrier, durées et horodatages exacts, et Date rend ces notions faciles à confondre. Temporal offre des types dédiés, pour que le code dise laquelle il veut dire.
Activer Temporal par défaut ne réécrit pas les appels Date existants. Cela rend la nouvelle API disponible sans drapeau, ce qui est le moment où les équipes peuvent commencer à l'utiliser dans le code nouveau. Une heure de réservation, une date de publication et une durée « cette offre dure trois jours » sont des faits de types différents. Les services britanniques qui affichent des heures aux clients, surtout autour de l'heure d'été, savent déjà comment un seul objet Date peut glisser. Faire passer le code nouveau vers Temporal est un bon usage de la montée de version. Réécrire chaque ancien appel dans la même livraison n'est pas obligatoire, et c'est un changement plus large que le saut d'exécution.
Les retraits sont la partie qui casse la construction
Node.js 26 retire http.Server.prototype.writeHeader() et plusieurs modules de flux hérités, parmi d'autres dépréciations et retraits. Une application qui appelle encore writeHeader, ou une dépendance qui importe encore un flux hérité, échouera sur la version 26 même si la logique métier va bien. Le correctif peut être un petit changement dans votre code, ou l'attente d'une version de bibliothèque. Découvrez-le en préproduction.
- Lire les notes officielles pour les retraits, pas seulement pour le titre Temporal.
- Faire tourner l'application, ses modules natifs et la construction de production sur Node 26 en préproduction.
- Vérifier le comportement du client HTTP là où l'application dépend des réglages d'Undici.
- Chercher dans les dépendances les API retirées avant de planifier la production.
- Déployer par étapes si le service est assez grand pour qu'une bascule totale cache un défaut.
Un déploiement par étapes rend un comportement inattendu visible avant que tous les utilisateurs ne le rencontrent. C'est une pratique de livraison ordinaire, et une montée d'exécution est une livraison. La reconstruction du stockage GitHub rappelle, la même saison, que les plateformes de développement subissent plus de charge à cause du changement automatisé. Une montée Node veut encore qu'un humain regarde la première tranche en production.
Utiliser la montée de version pour ranger les bords
Un changement d'exécution planifié est un moment raisonnable pour revoir le traitement des dates, mettre à jour les dépendances, lancer des contrôles de sécurité et ajouter des tests autour des services qui feraient mal s'ils se comportaient mal. C'est un mauvais moment pour glisser une refonte sans rapport. Gardez la montée de version sur l'exécution, les dépendances qu'elle force, et les tests qui prouvent les chemins importants. Les bugs de date et les API retirées sont assez de périmètre pour une livraison.
Les équipes qui sautent la préproduction parce que « ce n'est que Node » sont celles qui rencontrent writeHeader en production. Les notes officielles existent pour que l'approximation soit inutile. Supposez que la montée n'est pas transparente tant que les tests ne l'ont pas dit. Incluez le pipeline de construction dans cet essai. Un module natif qui compile sur l'ordinateur d'un développeur peut encore échouer dans l'image que vous déployez, et un fichier de verrouillage qui se résout autrement sur Node 26 n'apparaîtra pas dans une revue de code qui ne l'a jamais installé.
Monter de version selon un calendrier que vous tenez
Le développement logiciel d'un service britannique comprend l'exécution sur laquelle il tourne, pas seulement les fonctions du dépôt. L'hébergement cloud est l'endroit où cette exécution est vraiment épinglée, construite et déployée. Laisser la version à une image par défaut est la façon dont un retrait devient une panne.
Web Works Rise construit avec Next.js, React et TypeScript sur Node, depuis une équipe menée au Royaume-Uni à Birmingham et un hub de développement en Tunisie. Si Node 26 est la prochaine exécution de production et que vous voulez qu'elle soit testée avant la bascule, parlez à l'équipe des services, des modules natifs et de la logique de date qui doivent continuer à se comporter.