La version 20 de Node.js, le moteur d'exécution JavaScript, est dorénavant disponible
La version 20 de Node.js, le moteur d'exécution JavaScript, est désormais disponible, et inclut plusieurs nouveautés, dont un modèle de permission Node.js, pour offrir des performances améliorées
Node.js 20 est maintenant disponible ! Les points forts incluent le nouveau modèle de permission Node.js, un import.meta.resolve synchrone, un test_runner stable, des mises à jour du moteur JavaScript V8 vers 11.3, Ada vers 2.0, et plus encore !
Le projet continue de progresser dans un certain nombre de domaines, avec beaucoup de nouvelles fonctionnalités et de correctifs dans les versions LTS existantes. Pour cette raison, les changements décrits dans le journal des modifications de Node.js 20 ne représentent qu'un petit sous-ensemble des fonctionnalités et des travaux réalisés depuis la dernière version majeure. Ce bulletin de blog ajoutera un contexte supplémentaire sur l'ensemble du travail en relation avec ces changements.
Pour télécharger Node.js 20.0.0, visitez : https://nodejs.org/en/download/current/. Vous pouvez trouver dans ce billet de publication la liste complète des modifications incluses dans cette version.
Pour rappel, Node.js 20 entrera dans le support à long terme (LTS) en octobre, mais d'ici là, il s'agira de la version "Current" pour les six prochains mois. Vous êtes encouragés à explorer les nouvelles fonctionnalités et les avantages offerts par cette dernière version et à évaluer leur impact potentiel sur vos applications.
Modèle de permission
Le modèle de permission Node.js est un mécanisme expérimental permettant de restreindre l'accès à des ressources spécifiques pendant l'exécution.
Dans cette première version contenant le modèle de permission, les fonctionnalités sont fournies avec les capacités suivantes :
- Restreindre l'accès au système de fichiers (lecture et écriture) : Utiliser --allow-fs-read et --allow-fs-write
- Restreindre l'accès à --allow-fs-write : Utiliser --allow-child-process
- Restreindre l'accès aux worker_threads : Utiliser --allow-worker
- Restreindre l'accès aux modules complémentaires natifs (même chose que l'option --no-addons)
Les permissions disponibles sont documentées par le flag --experimental-permission.
Lors du démarrage de Node.js avec l'option --experimental-permission, la possibilité d'accéder au système de fichiers, de créer des processus et d'utiliser node:worker_threads sera restreinte.
Les développeurs utilisant Node.js ont maintenant plus de contrôle sur l'accès au système de fichiers avec l'introduction des drapeaux --allow-fs-read et --allow-fs-write. Ces fonctionnalités expérimentales permettent un contrôle plus granulaire des parties du système de fichiers auxquelles les processus Node.js peuvent accéder.
Pour activer ces flags, les développeurs peuvent utiliser le drapeau --experimental-permission avec les permissions souhaitées. Par exemple, la commande suivante permet d'accéder en lecture et en écriture à l'ensemble du système de fichiers :
Code:
$ node --experimental-permission --allow-fs-read=* --allow-fs-write=* index.js
Les développeurs peuvent également spécifier des chemins spécifiques pour l'accès au système de fichiers en passant des valeurs séparées par des virgules aux flags. Par exemple, la commande suivante permet d'accéder en écriture au dossier /tmp/ :
Code:
$ node --experimental-permission --allow-fs-write=/tmp/ --allow-fs-read=/home/index.js index.js
Les caractères génériques peuvent également être utilisés pour permettre l'accès à plusieurs fichiers ou dossiers à la fois. Par exemple, la commande suivante permet d'accéder en lecture à tous les fichiers et dossiers du répertoire /home/ qui commencent par test :
Code:
$ node --experimental-permission --allow-fs-read=/home/test* index.js
Lorsque le modèle de permission est activé, la nouvelle propriété permission de l'objet process peut être utilisée pour vérifier si une certaine permission a été accordée au moment de l'exécution.
Code:
1
2
| process.permission.has('fs.write'); // true
process.permission.has('fs.write', '/home/nodejs/protected-folder'); // true |
Il est important de noter que ces fonctionnalités sont encore expérimentales et peuvent être modifiées dans les prochaines versions de Node.js.
Les hooks personnalisés du chargeur ESM sont presque stables
Les hooks personnalisés du cycle de vie des modules ES fournis par les chargeurs (--experimental-loader=./foo.mjs) s'exécutent désormais dans un thread dédié, isolé du thread principal. Cela permet aux chargeurs de disposer d'un champ d'application distinct et garantit l'absence de contamination croisée entre les chargeurs et le code de l'application.
Conformément au comportement des navigateurs, import.meta.resolve() retourne désormais de manière synchrone ; notez que les hooks resolve dans les chargeurs utilisateur peuvent rester asynchrones si l'auteur du chargeur le souhaite, et import.meta.resolve retournera toujours de manière synchrone dans le code de l'application.
Ces changements étaient les derniers points en suspens avant de marquer les chargeurs ESM comme stables. Une fois qu'un certain temps se sera écoulé sans que des bogues significatifs aient été signalés par la communauté, les flags des chargeurs, import.meta.resolve et les hooks resolve et load seront marqués comme stables. Cela devrait permettre une adoption plus répandue de l'ESM, car des groupes importants tels que les fournisseurs d'instruments disposeront d'une API stable sur laquelle ils pourront construire des bibliothèques d'analyse et de rapport.
V8 11.3
Comme d'habitude, une nouvelle version du moteur V8 est incluse dans Node.js (mise à jour vers la version 11.3, qui fait partie de Chromium 113), apportant des performances améliorées et de nouvelles fonctionnalités de langage, y compris :
- String.prototype.isWellFormed et toWellFormed
- Des méthodes qui modifient les Array et TypedArray par copie
- ArrayBuffer redimensionnable et SharedArrayBuffer extensible
- RegExp v flag avec set notation + propriétés des chaînes de caractères
- Appel de queue WebAssembly
Test Runner stable
La récente mise à jour de Node.js, version 20, inclut un changement important dans le module test_runner. Le module a été marqué comme stable après une récente mise à jour. Le gestionnaire de test stable comprend les éléments de base pour la création et l'exécution de tests, y compris :
- describe, it/test et hooks pour structurer les fichiers de test
- mocking
- mode watch
- node --test pour exécuter plusieurs fichiers de test en parallèle
Le programme d'exécution des tests comprend également des éléments qui ne sont pas encore stables, notamment les rapporteurs et la couverture du code.
Voici un exemple simple d'utilisation du programme d'exécution des tests :
Code:
1
2
3
4
5
6
7
8
9
| import { test, mock } from 'node:test';
import assert from 'node:assert';
import fs from 'node:fs';
mock.method(fs, 'readFile', async () => "Hello World");
test('synchronous passing test', async (t) => {
// This test passes because it does not throw an exception.
assert.strictEqual(await fs.readFile('a.txt'), "Hello World");
}); |
Performances
Grâce à la nouvelle équipe Node.js Performance, l'accent a été mis sur les performances depuis la dernière version majeure. Node.js 20 comprend de nombreuses améliorations des parties fondamentales du runtime, notamment URL, fetch() et EventTarget.
Le coût de l'initialisation d'EventTarget a été réduit de moitié, ce qui permet un accès plus rapide à tous les sous-systèmes qui l'utilisent. En outre, les appels V8 Fast API ont été exploités pour améliorer les performances d'API telles que URL.canParse() et les minuteries.
Node.js 20 inclut des changements spécifiques, tels que la version 2.0 d'Ada, un analyseur d'URL rapide et conforme aux spécifications, écrit en C++.
En attendant de trouver de nouveaux moyens d'améliorer les performances, l'équipe travaille actuellement à réduire le coût de la conformité aux spécifications en refactorisant pour se débarrasser des contrôles de validation de marque sur les flux, sur URL, les URLSearchParams et le String Decoder. Cela soutient objectif général d'être conforme aux spécifications lorsque cela a du sens.
La préparation des applications à exécutable unique nécessite désormais l'injection d'un Blob
Le projet a travaillé sur la prise en charge des applications à exécutable unique (SEA) au cours de l'année dernière, et la première prise en charge a eu lieu récemment. L'approche continue d'être affinée car la fonctionnalité est encore expérimentale. Dans Node.js 20, la construction d'une application à exécutable unique nécessite désormais l'injection d'un blob préparé par Node.js à partir d'une configuration JSON au lieu d'injecter le fichier JS brut.
Exemple :
sea-config.json
Code:
1
2
3
4
| {
"main": "hello.js",
"output": "sea-prep.blob"
} |
Ceci écrit le blob dans le fichier sea-prep.blob.
Code:
$ node --experimental-sea-config sea-config.json
Ce blob peut maintenant être injecté dans le binaire.
Ce changement a été effectué pour permettre la possibilité d'intégrer plusieurs ressources coexistantes dans le SEA (Single Executable Apps), ce qui ouvre de nouveaux cas d'utilisation.
API Crypto Web
Le projet vise l'interopérabilité avec d'autres environnements JavaScript. Par exemple, dans Node.js 20, les arguments des fonctions de la Web Crypto API sont désormais contraints et validés conformément à leurs définitions WebIDL, comme dans d'autres implémentations de la Web Crypto API. Cela améliore encore l'interopérabilité avec d'autres implémentations de Web Crypto API.
Prise en charge officielle de Windows ARM64
Node.js a un large support de plateforme et d'architecture et les gens semblent vouloir qu'il fonctionne partout. Node.js inclut maintenant des binaires pour ARM64 Windows, permettant une exécution native sur la plateforme. Les paquets MSI, zip/7z et l'exécutable sont disponibles sur le site de téléchargement de Node.js avec toutes les autres plateformes. Le système CI a été mis à jour et tous les changements sont maintenant entièrement testés sur ARM64 Windows, afin d'éviter les régressions et d'assurer la compatibilité.
Progrès sur l'interface système Web Assembly (WASI)
Le projet continue à travailler sur l'implémentation de WASI dans Node.js. Un progrès notable est que, bien qu'expérimentale, une option de ligne de commande n'est plus nécessaire pour activer WASI. Cela devrait faciliter son utilisation. Alors que l'équipe travaillant sur WASI attend avec impatience l'avant-première 2, quelques changements ont également été apportés pour planifier l'avenir. Il s'agit notamment de l'ajout d'une option version lors de l'appel de new WASI(). Dans la version 20.x, l'option version est obligatoire et n'a pas de valeur par défaut. Ceci est important pour que les applications ne prennent pas par défaut une version obsolète au fur et à mesure que de nouvelles versions sont supportées. Cela signifie cependant que tout code qui s'appuie sur la valeur par défaut de la version devra être mis à jour pour demander une version spécifique.
Source : Annonce de Node.js 20
Et vous ?
:fleche: Que pensez-vous des améliorations apportées dans cette version de Node.js ?
:fleche: Quelles fonctionnalités vous paraissent les plus intéressantes ?
:fleche: Comment évaluez-vous les capacités de Node.js par rapport aux autres environnements d'exécution Javascript comme Bun ou Deno ?
Voir aussi
:fleche: La version 17 de Node.js, le moteur d'exécution JavaScript, est disponible, avec OpenSSL 3, bien que Deno, son concurrent, estime que la création des projets Node peut devenir une tâche ardue
:fleche: Bun, un nouveau moteur d'exécution JavaScript, livré avec un client SQLite3 rapide, il apporte un peu de concurrence pour Node et Deno
:fleche: La version 5 de Bun, le moteur d'exécution JavaScript qui transpile, installe et exécute des projets JavaScript et TypeScript, apporte plusieurs améliorations
