最近、ノード12のコードネームはErbium 、その長期サポート（LTS）は2019年10月から2022年4月まで続きます。
新しいバージョンには、ランタイムに対する多くの利点と改善点があります。 さらに、V8のボンネットの下では、ノードはすべてのエンジンの改善も受けます。
import/exportサポート
ノードはECMAScript Modulesへの途中でフェーズ3に入ります。 当初、この機能は--experimental-modulesフラグでのみ使用可能でした。 NodeがLTSに切り替わる頃には、このフラグを使用する必要がなくなる予定です。
import/exportを使用する構文import/export 、ES6での標準化以来、js開発者からのモジュールを使用する場合に推奨され、Nodeの背後にあるチームはネイティブサポートに熱心に取り組みました。 この機能は、フェーズ0からNode 8.0で実験的に利用できました。 現在のリリースは、その方向への大きな一歩です。 ほとんどの一般的なブラウザは、すでに<script type="module"> この機能をサポートしています 。
フェーズ3から、ESモデルからの3つのimportオプションがサポートされます。
Vanillaモジュールは、デフォルトの方法でのみエクスポートできます。
import module from 'cjs-library'
import()を使用して、ランタイムにロードできます。 import()はPromiseを返し、ESモデルとCommonJSライブラリの両方で動作します。
V8
ノード12は最初はV8 7.4で実行され、最終的に7.6にアップグレードされます。 V8チームは、ABI（Application Binary Interface）を提供することに同意しています。 V8 7.4の注目すべき改善点は、JavaScript実行の高速化、メモリ管理の改善、ECMAScript構文サポートの強化のためのパフォーマンスの改善です。
非同期スタックトレース
このコードを見てみましょう：
async function testAsyncStacktrace() { await killme(); return 42; } async function killme() { await Promise.resolve(); throw new Error('#Feelsbadman'); } testAsyncStacktrace().catch(error => console.log(error.stack));
古いバージョンでは、このスタックレースのようなものが得られます：
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)
ご覧のように、メッセージにはtestAsyncStacktrace記載されていません。 そして、 --async-stack-tracesフラグがデフォルトで有効になり、ログは次のようになります。
Error: #Feelsbadman at killme (test.js:8:11) at async testAsyncStacktrace (test.js:2:5)
引数の数が一致しない場合の加速呼び出し
JavaScriptでは、より少ない/より多くの引数で関数を呼び出すことは完全に受け入れられます（すなわち、より少ないまたはより多くの宣言された仮パラメータを渡します）。 前者の場合はアプリケーション不足で、後者の場合はアプリケーション超過です 。 引数の数が不十分な場合、パラメーターはundefinedになりますが、パラメーターの数が多い場合は単に無視されます。
ただし、JavaScript関数は、 arguments 、 rest parametersオブジェクト、または標準化されていない Function.prototype.argumentsをずさんなモード関数で使用しても、実際のパラメーターを取得できます。 その結果、JavaScriptエンジンは実際のパラメーターを取得する方法を提供する必要があります。 V8では、これは引数適応手法を使用して行われます。 残念ながら、そのような方法はパフォーマンスに影響します。
一部のシナリオでは、V8は引数の適応を完全にスキップし、呼び出しのオーバーヘッドを最大60％削減します。
詳細はドキュメントに記載されています 。
加速解析
Chromeでは、読み込み中にワーカースレッドで十分に大きなスクリプトが解析されてストリーミングされます。 V8 7.4はUTF-8デコードパフォーマンスの問題を修正し、8％の高速化をもたらしました。
ダイアグラム内の各ドロップは、ストリームアナライザーのパフォーマンス向上の1つを表しています。
改善されたawait
--async-stack-tracesフラグと--harmony-await-optimizationに、 --harmony-await-optimizationフラグがデフォルトで有効になりました。 詳細はこちら 。
プライベートクラスフィールド
V8でプライベートフィールドを使用する機能は、ノードに移行されました。 このようなフィールドは、クラス外では使用できません。 これらを作成するには、変数の前に#を指定する必要があります。
class HelloThere { #hidden = 'Hidden'; get hidden() { return this.#hidden; } set hidden(txt) { this.#hidden = txt; } hi() { console.log(`Hello, ${this.#hidden}`); } }
外部から#hiddenにアクセスしようとすると、構文エラーが発生します。
const hello = new HelloThere(); hello.#hidden = 'Visible';
クイックスタート
ノード12は、アセンブリの前に組み込みライブラリのキャッシュを使用し、バイナリとして埋め込みます。 メインスレッドでこのキャッシュを使用するため、開始時間が30％短縮されます。
TLSとセキュリティ
Nodaは、TLS 1.3をサポートするようになりました。これにより、セキュリティが強化され、待ち時間が短縮されます。 TLS 1.3はプロトコルを大幅に変更し、ネットワークに積極的に統合しています。 TLS 1.3の導入により、ユーザーデータの機密性が向上し、HTTPSでのハンドシェイクの時間を短縮することで要求処理を高速化できます。 さらに、TLS 1.0および1.1はデフォルトで無効になっており、廃止されたメソッドはcryptoから削除されました。
ダイナミックヒップサイズ
以前は、デフォルトのV8ヒープサイズである700MB（32ビットシステム）または1400MB（64ビットシステム）が使用されていました。 これで、ノードは、マシンの使用済みリソースを最適化するために、使用可能なメモリに基づいてヒープサイズを決定します。
ヒップをダンプする機能
ノード12にはヒープをダンプする機能があり、メモリの問題を簡単に検出できます。 詳細はこちらとこちらをご覧ください 。
実験診断レポート
Nodaは、アプリケーション内で問題（パフォーマンス、CPU使用率、メモリ、クラッシュなど）を診断するためのより強力なツールを提供し、レポート用の実験的な機能を提供します。
ネイティブモジュールを使用する場合の改善
ノード12は、 N-APIを使用した作業を簡素化する傾向を続けています 。 このバージョンでは、特にワーカースレッドを使用する場合のサポートが改善されています。
おわりに
ノード12には多くの改善点があります。 完全なCHANGELOGは、 Githubおよびサイト自体で表示できます。