JavaScript/WebAssembly 言語機能の実装とリリース

一般的に、V8 は JavaScript および WebAssembly 言語機能について、既に定義された合意に基づく標準に対する Blink Intent プロセスに従います。V8 固有のエラッタは以下に示されています。エラッタに別の指示がない限り、Blink Intent プロセスに従ってください。

JavaScript 機能に関してご質問がある場合は、syg@chromium.org と v8-dev@googlegroups.com にメールでお問い合わせください。

WebAssembly 機能に関してご質問がある場合は、gdeepti@chromium.org と v8-dev@googlegroups.com にメールでお問い合わせください。

エラッタ #

JavaScript 機能は通常、ステージ 3+ まで待つ #

原則として、V8 は JavaScript 機能提案がTC39 でステージ 3 以降に進むまで実装を待ちます。TC39 には独自の合意形成プロセスがあり、ステージ 3 以降は、すべてのブラウザベンダーを含む TC39 の代表者間で、機能提案の実装準備が整ったという明確な合意を示します。この外部の合意形成プロセスにより、ステージ 3+ の機能は、Intent to Ship 以外の Intent メールを送信する必要はありません。

TAG レビュー #

小規模な JavaScript または WebAssembly 機能の場合、TC39 と Wasm CG が既に重要な技術的監督を提供しているため、TAG レビューは必要ありません。機能が大規模または分野横断的である場合（例：他の Web プラットフォーム API への変更や Chromium への変更が必要な場合）、TAG レビューが推奨されます。

V8 フラグと blink フラグの両方が必要 #

機能を実装する際には、V8 フラグと blink base::Feature の両方が必要です。

緊急時に新しいバイナリを配布することなく Chrome が機能を無効にできるように、Blink 機能が必要です。これは通常、gin/gin_features.h、gin/gin_features.cc、および gin/v8_initializer.cc で実装されます。

リリースにはファジングが必要 #

JavaScript および WebAssembly 機能は、リリース前に、すべてのファジングバグを修正した状態で、最低 4 週間または 1 つのリリースマイルストーンの間、ファジングする必要があります。

コードが完成した JavaScript 機能の場合、src/flags/flag-definitions.h の JAVASCRIPT_STAGED_FEATURES_BASE マクロに機能フラグを移動して、ファジングを開始します。

WebAssembly については、WebAssembly リリースチェックリストを参照してください。

Chromestatus とレビューゲート #

blink intent プロセスには、API 所有者の承認を求める Intent to Ship が送信される前に、Chromestatus の機能エントリで承認される必要がある一連のレビューゲートが含まれています。

これらのゲートは Web API 向けに調整されており、一部のゲートは JavaScript および WebAssembly 機能には適用されない場合があります。以下は一般的なガイダンスです。詳細は機能によって異なります。ガイダンスを盲目的に適用しないでください！

プライバシー #

ほとんどの JavaScript および WebAssembly 機能はプライバシーに影響を与えません。まれに、ユーザーのオペレーティングシステムまたはハードウェアに関する情報を明らかにする新しいフィンガープリントベクトルを追加する機能があります。

セキュリティ #

JavaScript と WebAssembly はセキュリティエクスプロイトの一般的な攻撃ベクトルですが、ほとんどの新しい機能は追加の攻撃対象領域を追加しません。ファジングは必須であり、リスクの一部を軽減します。

JavaScript の ArrayBuffer など、既知の一般的な攻撃ベクトルに影響を与える機能、およびサイドチャネル攻撃を可能にする可能性のある機能は、特別な注意が必要であり、レビューする必要があります。

エンタープライズ #

TC39 および Wasm CG での標準化プロセス全体を通して、JavaScript および WebAssembly 機能は既に厳格な後方互換性の精査を受けています。機能が意図的に後方互換性がないことは非常にまれです。

JavaScript の場合、最近リリースされた機能は chrome://flags/#disable-javascript-harmony-shipping で無効にすることもできます。

デバッグ可能性 #

JavaScript および WebAssembly 機能のデバッグ可能性は、機能によって大きく異なります。新しい組み込みメソッドのみを追加する JavaScript 機能には追加のデバッガーサポートは必要ありませんが、新しい機能を追加する WebAssembly 機能には、かなりの追加のデバッガーサポートが必要になる場合があります。

詳細については、JavaScript 機能デバッグチェックリストおよびWebAssembly 機能デバッグチェックリストを参照してください。

不明な場合は、このゲートが適用されます。

テスト #

WPT の代わりに、JavaScript 機能には Test262 テストで十分であり、WebAssembly 機能には WebAssembly 仕様テストで十分です。

JavaScript および WebAssembly 言語機能には、複数の実装で実行される独自の相互運用可能なテストリポジトリがあるため、Web Platform Tests（WPT）を追加する必要はありません。ただし、有益と思われる場合は、自由にいくつか追加してください。

JavaScript 機能の場合、Test262 での明示的な正確性テストが必要です。ステージングディレクトリのテストで十分であることに注意してください。

WebAssembly 機能の場合、WebAssembly 仕様テストリポジトリでの明示的な正確性テストが必要です。

パフォーマンステストの場合、JavaScript は既に Speedometer などの既存のパフォーマンスベンチマークの基礎となっています。

CC する相手 #

すべての「intent to $something」メール（例：「intent to implement」）は、blink-dev@chromium.org に加えて、v8-users@googlegroups.com を CC する必要があります。これにより、V8 の他の埋め込み先も最新情報を入手できます。

仕様リポジトリへのリンク #

Blink Intent プロセスでは、説明者が必要です。新しいドキュメントを作成する代わりに、それぞれの仕様リポジトリへのリンクを自由に使用してください（例：import.meta）。