Récemment , Node 12 a été baptisé Erbium , dont le support à long terme (LTS) durera d'octobre 2019 à avril 2022.
La nouvelle version a beaucoup de goodies et d'améliorations à l'exécution. De plus, étant donné que sous le capot du V8, le nœud recevra également toutes les améliorations du moteur.
Prise en charge import/export
Le nœud entre en phase 3 sur le chemin des modules ECMAScript . Initialement, cette fonctionnalité n'était disponible qu'avec l' --experimental-modules . Au moment où le nœud passe à LTS, il est prévu de supprimer la nécessité d'utiliser cet indicateur.
La syntaxe utilisant l' import/export devenue préférable lorsque vous travaillez avec des modules pour les développeurs js depuis la standardisation dans ES6, et l'équipe derrière Node a travaillé avec diligence sur le support natif. Cette fonctionnalité était expérimentalement disponible avec le nœud 8.0 à partir de la phase 0. La version actuelle est un grand pas dans cette direction. Les navigateurs les plus populaires prennent déjà en charge cette fonctionnalité avec <script type="module"> .
À partir de la phase 3, trois options d' import partir des modèles ES seront prises en charge:
Les modules Vanilla ne peuvent être exportés que par défaut:
import module from 'cjs-library'
Vous pouvez utiliser import() pour charger en runtime. import() renvoie Promise et fonctionne avec les modèles ES et les bibliothèques CommonJS.
V8
Le noeud 12 s'exécutera initialement sur V8 7.4 et sera finalement mis à niveau vers 7.6. L'équipe V8 a accepté de fournir une ABI (Application Binary Interface). Les améliorations notables de V8 7.4 sont des améliorations de performances pour une exécution JavaScript plus rapide, une meilleure gestion de la mémoire et une prise en charge améliorée de la syntaxe ECMAScript.
Traces de pile asynchrones
Regardons ce code:
async function testAsyncStacktrace() { await killme(); return 42; } async function killme() { await Promise.resolve(); throw new Error('#Feelsbadman'); } testAsyncStacktrace().catch(error => console.log(error.stack));
Sur les anciennes versions, vous obtiendrez quelque chose comme ceci:
Error: #Feelsbadman at killme (test.js:8:11) at process._tickCallback (internal/process/next_tick.js:68:7) at Function.Module.runMain (internal/modules/cjs/loader.js:721:11) at startup (internal/bootstrap/node.js:228:19) at bootstrapNodeJSCore (internal/bootstrap/node.js:576:3)
Comme vous pouvez le voir, le message ne mentionne testAsyncStacktrace . Et maintenant, l' --async-stack-traces est activé par défaut, et le journal ressemblera à ceci:
Error: #Feelsbadman at killme (test.js:8:11) at async testAsyncStacktrace (test.js:2:5)
Appel accéléré lorsque le nombre d'arguments ne correspond pas
En JavaScript, il est parfaitement acceptable d'appeler des fonctions avec moins / plus d'arguments (c'est-à -dire passer moins ou plus de paramètres formels déclarés). Dans le premier cas, il s'agit d'une sous-application et dans le second, d'une sur-application . Dans le cas d'un nombre insuffisant d'arguments, les paramètres ne seront pas undefined , tandis que dans le cas d'un grand nombre de paramètres, ils seront simplement ignorés.
Cependant, les fonctions JavaScript peuvent toujours obtenir les paramètres réels en utilisant les arguments , l'objet de paramètres de repos ou même en utilisant les Function.prototype.arguments non standardisés dans les fonctions en mode bâclé . Par conséquent, les moteurs JavaScript devraient fournir un moyen d'obtenir les paramètres réels. En V8, cela se fait en utilisant la technique d'adaptation des arguments . Malheureusement, ces méthodes affectent les performances.
Dans certains scénarios, la V8 ignore complètement l' adaptation des arguments , réduisant ainsi la surcharge des appels jusqu'à 60%.
Les détails se trouvent dans le document .
Analyse accélérée
Dans Chrome, les scripts suffisamment volumineux sont analysés en streaming dans les threads de travail pendant leur chargement. La version V8 7.4 a résolu le problème des performances de décodage UTF-8, ce qui a entraîné une accélération de 8%.
Chaque goutte dans le diagramme représente l'une des améliorations des performances de l'analyseur de flux.
Attente améliorée
Avec l' --async-stack-traces , l' --harmony-await-optimization est maintenant activé par défaut. Détails ici .
Champs de cours privés
La possibilité d'utiliser des champs privés dans V8 a migré vers le nœud. Ces champs ne sont pas disponibles en dehors de la classe. Pour les créer, vous devez spécifier # avant la variable.
class HelloThere { #hidden = 'Hidden'; get hidden() { return this.#hidden; } set hidden(txt) { this.#hidden = txt; } hi() { console.log(`Hello, ${this.#hidden}`); } }
Lorsque vous essayez d'accéder à #hidden de l'extérieur, vous obtenez une erreur de syntaxe.
const hello = new HelloThere(); hello.#hidden = 'Visible';
DĂ©marrage rapide
Le noeud 12 utilisera le cache pour les bibliothèques intégrées avant de créer et d'incorporer en tant que binaires. En raison de l'utilisation de ce cache dans le thread principal, l'heure de début sera réduite de 30%.
TLS et sécurité
Noda prend désormais en charge TLS 1.3, qui offre une sécurité renforcée et réduit la latence. TLS 1.3 a considérablement changé le protocole et s'intègre activement au réseau. L'introduction de TLS 1.3 augmentera la confidentialité des données utilisateur et accélérera le traitement des demandes en réduisant le temps de prise de contact dans HTTPS. De plus, TLS 1.0 et 1.1 sont désactivés par défaut et les méthodes obsolètes ont été supprimées de la crypto .
Taille de hanche dynamique
Auparavant, la taille de segment V8 par défaut était de 700 Mo (systèmes 32 bits) ou 1400 Mo (systèmes 64 bits). Le nœud va maintenant déterminer les tailles de tas en fonction de la mémoire disponible afin d'optimiser les ressources utilisées de la machine.
La capacité de vider la hanche
Le noeud 12 offre la possibilité de vider des tas, ce qui facilite la détection des problèmes de mémoire. Les détails peuvent être trouvés ici et ici .
Rapports de diagnostic expérimental
Noda propose des outils plus puissants pour diagnostiquer les problèmes (performances, utilisation du processeur, mémoire, plantages, etc.) directement à l'intérieur de l'application, fournissant une fonctionnalité expérimentale pour les rapports.
Améliorations lors de l'utilisation de modules natifs
Le nœud 12 poursuit la tendance à la simplification du travail avec la N-API . Cette version a amélioré la prise en charge, en particulier lorsque vous travaillez avec des threads de travail.
Conclusion
Le nœud 12 a beaucoup d'améliorations. Le CHANGELOG complet peut être consulté sur Github et sur le site lui-même.