Discussion :

[Stéphane le calme]

Node.js 15 est disponible et apporte le support de npm 7, une implémentation expérimentale AbortController
ainsi qu'une mise à jour du moteur JavaScript V8 qui passe en version 8.6

L'équipe de développement de Node.js a annoncé la disponibilité de la version 15. Node.js 15 vient donc remplacer Node.js 14 en tant que version « actuelle », tandis que Node.js 14 sera promu LTS (long-term support - support à long terme) plus tard ce mois-ci. Étant donné qu'il s'agit d'un numéro de version impair, Node.js 15 ne sera pas promu en LTS. Il faut donc garder cela à l'esprit étant donné que le projet sous l'égide de la Fondation OpenJS recommande généralement l'utilisation d'une ligne de version LTS pour les déploiements en production.

Voici quelques-unes des améliorations / nouveautés apportées par cette version :

AbortController

Node.js 15 propose une implémentation expérimentale d'AbortController. AbortController est une classe d'utilitaire globale utilisée pour signaler l'annulation dans certaines API basées sur Promise, et qui s'appuie sur l'API Web AbortController:

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
const ac = new AbortController();
ac.signal.addEventListener('abort', () => console.log('Aborted!'),
{ once: true });
ac.abort();
console.log(ac.signal.aborted);  // Prints True

Dans l'exemple ci-dessus, l'événement abort est déclenché lorsque ac.abort() est appelé. L'AbortController ne déclenchera l'événement abort qu'une seule fois. Les écouteurs d'événements attachés à AbortSignal doivent utiliser l'option {once: true} (ou l'équivalent de l'API EventEmitter - once()) pour garantir que l'écouteur d'événements est supprimé une fois que l'événement abort est géré.

N-API 7

N-API est une API pour la création d'addons natifs. Il est indépendant du runtime JavaScript sous-jacent (par exemple, V8) et est maintenu dans le cadre de Node.js lui-même.

Pourquoi utiliser des addons natifs ? Voici quelques raisons :

• Calculs lourds : Comme le code natif a de meilleures performances que le JavaScript, il est logique de déplacer des charges de calcul importantes vers un addon natif. Il faut cependant faire attention au léger overhead lorsqu'on passe du contexte JavaScript à C++ : il est généralement négligeable, mais il réduira les performances s’il est trop fréquent.
• Code asynchrone : Node.js est exécuté sur un seul thread, l’event loop. Il délègue des tâches bloquantes à d’autres threads, des workers du pool de workers (“Worker Pool”). Lors de l’écriture d’un addon natif, vous pouvez et devez également créer des workers pour vos tâches lourdes ou des tâches I/O bloquantes.
• Binding de bibliothèques C/C++ : Si vous souhaitez utiliser une bibliothèque C ou C++ dans votre code Node.js, vous pouvez binder les fonctionnalités de la bibliothèque afin de pouvoir l’utiliser dans Node.js.

Pour cette version, l'équipe explique « Alors que nous rétroportons les nouvelles versions de N-API vers les autres versions de LTS Node.js, il convient de mentionner que N-API 7 est nouveau depuis la dernière version majeure et apporte des méthodes supplémentaires pour travailler avec ArrayBuffers. »

npm 7

npm est le gestionnaire de paquets officiel de Node.js. Depuis la version 0.6.3 de Node.js, npm fait partie de l'environnement et est donc automatiquement installé par défaut. npm fonctionne avec un terminal et gère les dépendances pour une application. Il permet également d'installer des applications Node.js disponibles sur le dépôt npm.

Node.js 15 est livré avec une nouvelle version majeure de npm qui a été présentée la semaine dernière : npm 7.

npm 7 est livré avec des fonctionnalités très attendues et demandées, notamment:

• Les espaces de travail : ensemble de fonctionnalités de l'interface de ligne de commande npm qui prennent en charge la gestion de plusieurs packages à partir d'un package racine unique de niveau supérieur.
• L'installation automatique des dépendances entre pairs : Dans certains cas, vous souhaitez exprimer la compatibilité de votre package avec un outil ou une bibliothèque hôte, sans nécessairement faire une require de cet hôte. Ceci est généralement appelé plugin. Notamment, votre module peut exposer une interface spécifique, attendue et spécifiée par la documentation hôte.
  
  Par exemple:
  
  

  Code JavaScript :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  {
    "name": "tea-latte",
    "version": "1.3.5"
    "peerDependencies": {
      "tea": "2.x"
    }
  }

  
  Cela garantit que votre paquet tea-latte peut être installé avec la deuxième version majeure du paquet hôte tea uniquement. Le package hôte est automatiquement installé si nécessaire. npm install tea-latte pourrait éventuellement générer le graphe de dépendances suivant:
  
  

  ├── tea-latte@1.3.5
  └── tea@2.2.0

  Essayer d'installer un autre plugin avec une exigence contradictoire provoquera une erreur. Pour cette raison, il est nécessaire de s'assurer que vos exigences en matière de plug-in sont aussi larges que possible et de ne pas les verrouiller à des versions de correctifs spécifiques.
  
  Avant npm 7, les développeurs devaient gérer et installer leurs propres dépendances entre pairs. Le nouvel algorithme de dépendance entre pairs garantit qu'une dépendance entre pairs correspondante est trouvée au niveau ou au-dessus de l'emplacement de la dépendance entre pairs dans l'arborescence node_modules.
• package-lock v2 et support de yarn.lock: L'équipe a expliqué que son nouveau format package-lock va apporter la possibilité de faire des builds reproductibles de manière déterministe et inclut tout ce dont npm aura besoin pour faire des builds de l'arborescence entière des packages. Avant npm 7, les fichiers yarn.lock étaient ignorés, le cli npm peut désormais utiliser yarn.lock comme source de métadonnées de package et de conseils de résolution.

unhandledRejection« À partir de Node.js 15, le mode par défaut pour unhandledRejection est changé en throw (de warn). En mode throw, si un hook unhandledRejection n'est pas défini, le unhandledRejection est déclenché comme une exception non interceptée. Les utilisateurs qui ont un hook unhandledRejection ne devraient voir aucun changement de comportement, et il est toujours possible de changer de mode à l'aide de l'indicateur de processus --unhandled-rejection=mode.

« Node.js a émis un UnhandledPromiseRejectionWarning par défaut pour de nombreuses versions et la décision de changer le mode à lancer a été acceptée sur la base des résultats de l'enquête Node.js User Insights: Unhandled Promise Rejections, et enfin par le vote du comité directeur technique Node.js. »

V8 8.6

Le moteur JavaScript V8 a été mis à jour vers la version V8 8.6 (le moteur V8 8.4 est le dernier disponible dans Node.js 14). Outre les ajustements et améliorations des performances, la mise à jour V8 apporte également les fonctionnalités de langage suivantes :

• Promise.any() MDN (de V8 8.5)
• AggregateError MDN (de V8 8.5)
• String.prototype.replaceAll() MDN (de V8 8.5)
• Opérateurs d'affectation logique &&=, ||= et ??= MDN (de V8 8.5)

Télécharger Node.js v15.0.0

Source : note de version

[johanpetrikovsky]

Merci pour l'info

[Stan Adkens]

Node.js 16 est maintenant disponible, et vient avec une mise à niveau du moteur JavaScript V8,
Des binaires préconstruits pour les puces Apple et des API stables supplémentaires

L’équipe derrière Node.js a publié le 20 avril la version 16, qui apporte des binaires pour les puces d'Apple et des API stables supplémentaires au populaire runtime JavaScript. C’est la toute première version du moteur JavaScript à être livrée avec des binaires préconstruits pour Apple Silicon qui intègre également la version V8 9.0 et des fonctions timer qui retournent les objets Promise. Node.js 16 remplace Node.js 15 en tant que version actuelle, et restera la version actuelle pendant les six prochains mois, avant d’être promue au niveau LTS (support à long terme) en octobre prochain.

Le runtime JavaScript version 8 a été mis à jour de la version 8.6 à 9.0. L'équipe a également créé des binaires pour les puces Apple avec l'aide du projet MacStadium, a expliqué l'équipe. Cette version est donc la première à intégrer des binaires préconstruits pour les puces ARM des Mac. L'outil fournit des fichiers d’archive – tarballs – séparés pour les architectures Intel et ARM. En revanche, le fichier d’installation pour MacOS sera livré comme un binaire « fat » qui couvre les deux architectures. Node.js 16 suit la sortie en octobre 2020 de Node.js 15.

Parmi les autres nouveautés et améliorations de Node.js 16, citons la stabilisation de l'API Timers Promises, fournissant un ensemble alternatif de fonctions timer qui renvoient des objets Promise, supprimant la nécessité d'utiliser util.promisify().

En outre, comme toujours, une nouvelle version du moteur JavaScript V8 apporte des ajustements et des améliorations en termes de performances, tout en permettant à Node.js de rester à jour avec les caractéristiques du langage JavaScript. Dans Node.js v16.0.0, le moteur V8 est mis à jour à V8 9.0 – à partir de V8 8.6 dans Node.js 15. Cette mise à jour apporte les indices de correspondance RegExp ECMAScript, qui fournissent les indices de début et de fin de la chaîne capturée. Le tableau d'indices est disponible via la propriété .indices des objets match lorsque l'expression régulière possède l'indicateur /d, lit-on dans l’article de blog écrit avec la contribution du comité directeur technique de Node.js.

Les fonctionnalités produites dans le cadre des récentes versions de Node.js 15 qui sont maintenant dans Node.js 16 comprennent Node-API version 8, Stable Source Maps v3, et les implémentations atob (buffer.atob(data)) et btoa (buffer.btoa(data)) de la plateforme Web pour la compatibilité avec les API de la plateforme Web existante.

En tant que nouvelle version majeure, c'est aussi le moment où l’équipe introduit les nouvelles dépréciations du runtime. Selon l’article de blog, le projet Node.js vise à minimiser la perturbation de l'écosystème pour tout changement de rupture. Le projet utilise pour cela un outil nommé CITGM (Canary in the Goldmine), pour tester l'impact de tout changement de rupture (y compris les dépréciations) sur un grand nombre de modules populaires de l'écosystème afin de fournir des informations supplémentaires avant d'introduire ces changements.

Parmi les dépréciations notables dans Node.js 16, citons la dépréciation au moment de l'exécution de l'accès à process.binding() pour un certain nombre de modules de base, tels que process.binding('http_parser').

Node.js 16 sera promu au niveau support à long terme en octobre et baptisé "Gallium"

« Une nouvelle version majeure est la somme des efforts de tous les contributeurs du projet et des collaborateurs de Node.js, nous aimerions donc profiter de cette occasion pour leur dire un grand merci. En particulier, nous aimerions remercier le groupe de travail Node.js Build pour s'assurer que nous avons l'infrastructure prête à créer et à tester les versions et à faire les mises à jour nécessaires à nos chaînes d'outils pour Node.js 16 », a écrit l'équipe Node.js dans son billet de blog.

Node.js 16 est téléchargeable depuis nodejs.org ou en utilisant Node Version Manager sur Unix pour l'installer avec nvm install 16. Node.js 16 remplace Node.js 15 en tant que version actuelle, Node 16 restant la version actuelle pendant les six prochains mois, puis étant promue au support à long terme en octobre. Une fois promue au support à long terme, la version sera désignée par le nom de code "Gallium". La fin de vie de Node.js 16.x est prévue pour le 30 avril 2024.

Node.js 12, quant à lui, sera pris en charge jusqu'en avril 2022 et Node.js 14 restera en support à long terme jusqu'en avril 2023. Enfin, Node.js 10 ne bénéficiera plus de support dès la fin de ce mois (avril 2021).

Sur les plateformes Linux, le niveau GCC (Gnu C Compiler) minimum pour le build des projets Node.js est GCC 8.3. Les détails sur les outils et compilateurs supportés sont accessibles dans le fichier BUILDING.md.

Au niveau des runtimes JavaScript, Node.js doit maintenant partager la vedette avec Deno qui est conduit par Ryan Dahl (qui a contribué à la création de Node.js) et qui prévoit de fournir une alternative plus sécurisée à ce dernier. La version 1.9 de Deno remonte au 13 avril, la v.1.8 à mars. Au début du mois, Ryan Dahl et Bert Belder (l’autre cofondateur de Deno) ont par ailleurs annoncé qu’ils montaient une société pour dynamiser l'écosystème JavaScript et améliorer leur projet avec un capital de départ suffisant de 4,9 millions de dollars pour recruter une équipe d’ingénieurs à plein temps.

Pour expliquer leur démarche, Ryan Dahl a expliqué dans un billet publié en fin mars que JavaScript côté serveur est « désespérément fragmenté, profondément lié à une mauvaise infrastructure et irrévocablement dirigé par des comités qui ne sont pas incités à innover ».

Avec l’investissement, Deno va poursuivre le développement de runtimes personnalisés et sécurisés pour différentes applications, notamment des interfaces utilisateurs type Electron, des fonctions de serverless pour Cloudflare Worker, des scripts intégrés pour les bases de données… Pour rassurer la communauté, Deno précise que le projet reste sous licence MIT. « Notre société s’appuiera sur le projet open source, sans chercher à le monétiser directement », indique le message.

Vous pouvez télécharger Node.js v16.0.0 ici.

Source : Node.js

Et vous ?

Que pensez-vous de Node.js 16 ?
Quels sont les changements qui vous intéressent ?


Voir aussi :

Node.js 15 est disponible et apporte le support de npm 7, une implémentation expérimentale AbortController, Ainsi qu'une mise à jour du moteur JavaScript V8 qui passe en version 8.6
Un développeur JavaScript estime que l'écosystème Node.js est « chaotique et peu sûr », et voici pourquoi
La Version 1.9 de Deno, le runtime pour exécuter JavaScript et TypeScript, est disponible, elle améliore les appels de commande dans Rust et apporte de nouvelles fonctionnalités