Quoi de neuf dans Node.js 20 —

Version 20 de Node.js a été publié le 18 avril 2023. Il aborde certains problèmes et critiques déjà « résolus » par Pas et Chignondont un nouveau modèle d’autorisation et une écurie testeur natif. Cet article examine les nouvelles options disponibles pour les développeurs utilisant le runtime JavaScript le plus utilisé au monde.

Contenu:

1. Le calendrier de publication de Node.js
2. Nouveau modèle d’autorisation
3. Coureur de test natif
4. Compilation d’une seule application exécutable
5. Moteur JavaScript V8 mis à jour
6. Mises à jour diverses

Le calendrier de publication de Node.js

Node.js a un calendrier de publication de six mois :

• Les versions paires d’avril (14, 16, 18, etc.) sont stables et reçoivent des mises à jour de support à long terme (LTS) pendant trois ans.

• Les versions impaires d’octobre (15, 17, 19, etc.) sont plus expérimentales et les mises à jour se terminent souvent après un an.

En général, vous devez opter pour la version LTS paire, sauf si vous avez besoin d’une fonctionnalité spécifique dans une version expérimentale et que vous avez l’intention de mettre à niveau ultérieurement. Cela dit, Node.js 20 est nouveau et le site Web vous conseille de continuer avec la version 18 pendant que l’équipe de développement corrige les problèmes de dernière minute.

Node.js 20 a les nouvelles fonctionnalités suivantes…

Nouveau modèle d’autorisation

En cours node somescript.js n’est pas sans risque. Un script peut tout faire : supprimer des fichiers essentiels, envoyer des données privées à un serveur ou exécuter un mineur de crypto-monnaie dans un processus enfant. Il est difficile de garantir que votre propre code ne cassera rien : pouvez-vous être certain que tous les modules et leurs dépendances sont sûrs ?

Le nouveau Node.js (expérimental) Modèle d’autorisation limite ce que le script peut faire. Pour l’utiliser, ajoutez le --experimental-permission signaler votre node ligne de commande suivi de :

1. --allow-fs-read pour accorder un accès en lecture aux fichiers. Vous pouvez limiter l’accès en lecture à :

   • répertoires spécifiques : --allow-fs-read=/tmp/
   • fichiers spécifiques : --allow-fs-read=/home/me/data.json
   • ou modèles de fichiers génériques : --allow-fs-read=/home/me/*.json

2. --allow-fs-write pour accorder un accès en écriture aux fichiers avec des modèles de répertoire, de fichier ou de caractères génériques identiques.

3. --allow-child-process permettre processus enfants comme l’exécution d’autres scripts peut-être écrits dans d’autres langues.

4. --allow-worker permettre fils de travailqui exécutent le code Node.js en parallèle avec le thread de traitement principal.

Dans l’exemple suivant, somescript.js peut lire des fichiers dans le /home/me/data/ annuaire:

node --experimental-permission --allow-fs-read=/home/me/data/ somescript.js

Toute tentative d’écriture d’un fichier, d’exécution d’un autre processus ou de lancement d’un web worker génère un ERR_ACCESS_DENIED erreur.

Vous pouvez vérifier les autorisations dans votre application à l’aide du nouveau process.permission objet. Par exemple, voici comment vérifier si le script peut écrire des fichiers :

process.permission.has('fs.write');

Voici comment vérifier si le script peut écrire dans un fichier spécifique :

if ( !process.permission.has('fs.write', '/home/me/mydata.json') ) {
  console.error('Cannot write to file');
}

La gestion des autorisations JavaScript a été introduite pour la première fois par Pas, qui offre un contrôle précis de l’accès aux fichiers, aux variables d’environnement, aux informations sur le système d’exploitation, à la mesure du temps, au réseau, aux bibliothèques chargées dynamiquement et aux processus enfants. Node.js n’est pas sécurisé par défaut, sauf si vous ajoutez le --experimental-permission drapeau. Ceci est moins efficace, mais garantit que les scripts existants continuent de s’exécuter sans modification.

Coureur de test natif

Historiquement, Node.js était un environnement d’exécution minimal permettant aux développeurs de choisir les outils et les modules dont ils avaient besoin. L’exécution de tests de code nécessitait un module tiers tel que Moka, AVou Est. Bien que cela ait donné lieu à de nombreux choix, il peut être difficile de faire le meilleur prendre une décision et changer d’outil n’est peut-être pas facile.

D’autres runtimes adoptaient une vision alternative et offraient des outils intégrés considérés comme essentiels pour le développement. Pas, Chignon, Alleret Rouiller tous offrent des testeurs intégrés. Les développeurs ont un choix par défaut mais peuvent opter pour une alternative lorsque leur projet a des exigences spécifiques.

Node.js 18 a introduit une expérience testeur qui est désormais stable en version 20. Il n’est pas nécessaire d’installer un module tiers, et vous pouvez créer des scripts de test :

• dans votre projet /test/ annuaire
• en nommant le fichier test.js, test.mjsou test.cjs
• en utilisant test- au début du nom de fichier — comme test-mycode.js
• en utilisant test à la fin du nom de fichier précédé d’un point (.), trait d’union (-) ou un trait de soulignement (_) – tel que mycode-test.js, mycode_test.cjsou mycode.test.mjs

Vous pouvez ensuite importer node:test et node:assert et écrivez des fonctions de test :

import { test, mock } from 'node:test';
import assert from 'node:assert';
import fs from 'node:fs';

test('my first test', (t) => {
  assert.strictEqual(1, 1);
});

test('my second test', (t) => {
  assert.strictEqual(1, 2);
});


mock.method(fs, 'readFile', async () => 'Node.js test');
test('my third test', async (t) => {
  assert.strictEqual( await fs.readFile('anyfile'), 'Node.js test' );
});

Faites les tests avec node --test test.mjs et examinez la sortie :

✔ my first test (0.9792ms)
✖ my second test (1.2304ms)
  AssertionError: Expected values to be strictly equal:

  1 !== 2

      at TestContext.<anonymous> (test.mjs:10:10)
      at Test.runInAsyncScope (node:async_hooks:203:9)
      at Test.run (node:internal/test_runner/test:547:25)
      at Test.processPendingSubtests (node:internal/test_runner/test:300:27)
      at Test.postRun (node:internal/test_runner/test:637:19)
      at Test.run (node:internal/test_runner/test:575:10)
      at async startSubtest (node:internal/test_runner/harness:190:3) {
    generatedMessage: false,
    code: 'ERR_ASSERTION',
    actual: 1,
    expected: 2,
    operator: 'strictEqual'
  }

✔ my third test (0.1882ms)
ℹ tests 3
ℹ pass 2
ℹ fail 1
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 72.6767

Vous pouvez ajouter un --watch drapeau pour relancer automatiquement les tests lorsque le fichier change :

node --test --watch test.mjs

Vous pouvez également exécuter tous les tests trouvés dans le projet :

node --test

Test natif est un ajout bienvenu au runtime Node.js. Il y a moins besoin d’apprendre différentes API tierces, et je n’ai plus d’excuse quand oubli pour ajouter des tests à des projets plus petits !

Compilation d’une seule application exécutable

Les projets Node.js nécessitent le runtime pour s’exécuter. Cela peut constituer un obstacle lors de la distribution d’applications à des plates-formes ou à des utilisateurs qui ne peuvent pas facilement installer ou maintenir Node.js.

La version 20 propose une fonctionnalité expérimentale qui permet de créer un application exécutable unique (SEA) que vous pouvez déployer sans dépendances. Le manuel explique le processus, bien qu’il soit un peu compliqué:

1. Vous devez avoir un projet avec un script à entrée unique. Il doit utiliser CommonJS plutôt que les modules ES.

2. Créez un fichier de configuration JSON utilisé pour créer votre script dans un blob qui s’exécute dans le runtime. Par exemple, sea-config.json:

   {
     "main": "myscript.js",
     "output": "sea-prep.blob"
   }
   

3. Générer le blob avec node --experimental-sea-config sea-config.json.

4. Selon votre OS, vous devez ensuite copier le node exécutable, supprimez la signature du binaire, injectez le blob dans le binaire, signez-le à nouveau et testez l’application résultante.

Pendant que cela fonctionne, vous êtes limité aux anciens projets CommonJS et ne pouvez cibler que le même système d’exploitation que celui que vous utilisez. Il est certain de s’améliorer, étant donné la qualité supérieure compilateur deno peut créer un exécutable pour n’importe quelle plate-forme en une seule commande à partir de fichiers source JavaScript ou TypeScript.

Vous devez également être conscient de la taille du fichier exécutable résultant. Un célibataire ou Individual console.log('Hello World'); génère un fichier de 85 Mo, car Node.js (et Deno) doit ajouter l’ensemble du moteur JavaScript V8 et des bibliothèques standard. Des options pour réduire la taille des fichiers sont envisagées, mais il est peu probable qu’elles descendent en dessous de 25 Mo.

La compilation ne sera pas pratique pour les petits outils de ligne de commande, mais c’est une option plus viable pour les projets plus importants tels qu’une application de serveur Web complète.

Moteur JavaScript V8 mis à jour

Node.js 20 inclut la dernière version du Moteur V8qui inclut les fonctionnalités JavaScript suivantes :

Mises à jour diverses

Les mises à jour et améliorations suivantes sont également disponibles :

Résumé

Node.js 20 est une avancée majeure. Il s’agit d’une version plus importante et implémente certaines des meilleures fonctionnalités de Deno.

Cependant, cela soulève la question: devriez-vous utiliser Deno à la place ?

Deno est super. Il est stable, prend en charge nativement TypeScript, réduit les temps de développement, nécessite moins d’outils et reçoit des mises à jour régulières. En revanche, il existe depuis moins de temps, a moins de modules et ce sont souvent des imitations moins profondes des bibliothèques Node.js.

Deno et Bun valent la peine d’être envisagés pour de nouveaux projets, mais il existe des milliers d’applications Node.js existantes. Deno et Bun facilitent la transition du code, mais il n’y aura pas toujours un avantage clair à s’éloigner de Node.js.

La bonne nouvelle est que nous avons un écosystème JavaScript florissant. Les équipes d’exécution apprennent les unes des autres et l’évolution rapide profite aux développeurs.