JavaScript の ES 型構文に関する Microsoft の提案は何を意味しますか

今年初めに Microsoft などから提出された提案が ECMAScript 標準の一部になった場合、JavaScript はすぐに独自の型構文を持つ可能性があります。このイニシアチブでは、JavaScript 言語に「コメントとしての型」のサポートを追加する予定です。これにより、開発者は、エコシステムの他のコンポーネントで使用されるコードに型情報を追加できるようになります。

構文

推奨される構文は次のとおりです。

これは、Microsoft の型付き JavaScript のスーパーセットであるTypeScriptを以前に使用したことがある人にはおなじみです。TypeScript は業界で広く採用されています。この新しい提案は、その利点の一部をより広い JavaScript の世界にもたらすことを目的としています。

オファーではないものは何ですか？

承認された場合、この提案により、上記の型注釈を使用して完全に有効な JavaScript を記述できるようになります。ES 規格に準拠した Web ブラウザー、Node.js、Deno などの JavaScript ランタイムで受け入れられます。

ただし、この提案は実際には JavaScript 言語を拡張するものではありません。型注釈は、JavaScript コンパイラやコードのランタイムに影響を与えない不活性なメタデータです。次のような関数を呼び出すと、実行時に機能します。

アイデアは、公式にサポートされているがエンジンによって完全に無視されている新しい型構文を提案することです。唯一の実装の変更は、型注釈が使用されている場所での型注釈の認識と削除に関するものです。

この提案では、パラメーター、変数、およびクラス プロパティの型に注釈を付けるためのサポートを確立しようとします。また、キーワード、 andinterfaceなどのアサーション演算子、および型をオプションとしてマークする修飾子を追加することも検討します。目標は、これらすべての要素が TypeScript を反映することです。ステージ 0 の提案と同様に、最終的な結果は異なる場合があります。!as?

ポイントは何ですか？

型注釈がプログラムを変更しない場合、明らかな問題は、型注釈を使用する価値があるかどうかです。この提案は、反復時間を短縮し、最新の JavaScript ツール チェーンの負担を軽減する構文の機能により、「はい」と述べています。

タイプ セーフなコードを記述するには、現在、プロジェクトに依存関係を追加し、手動のコンパイル手順を必要とする別の言語フレーバーである TypeScript を使用する必要があります。このコードは、配布用の最終的な JavaScript コードが生成される前に、モジュール ビルダーやトランスパイラーなどの他のツールを通過できます。これは、複数の可動部品を備えた複雑なツール チェーンを構成します。

JavaScript は本質的に緩く型付けされた言語ですが、強力な型付けの利点は現在、コミュニティによって広く認識されています。これは、TypeScript プロジェクトに関連するダイナミクスから見ることができます。静的型付けは、2021 年の State of JS 調査の「不足している機能」の質問でも明らかにリーダーでした。

JavaScript 自体に型構文を追加すると、コードをコンパイルしなくても、TypeScript の利点の一部を得ることができます。これにより、プロジェクトのセットアップと保守が簡素化され、JavaScript が進化して最新の開発手法に適合します。

ここ数年、ますます多くのコードが「純粋な JavaScript」に戻り始めています。レガシー ブラウザの衰退により、トランスパイルの必要性がかつてより少なくなりました。最新の実装のほとんどは、クラス、アロー関数、ブロック変数、/などの機能を完全にサポートしています。JavaScript には、ブラウザーを含むすべてのエンジンで機能する完全なモジュール システムもあります。asyncawait

ほんの数年前までは、これらの機能をユーザーのデバイスで動作するという確信を持ってコードに書き込むには、長い一連のツールが必要でした。当面の間、開発者は、<script>タグ付きファイル参照を使用して元の JavaScript モデルに戻すことで、これらのビルド プロセスを安全に脇に置くことができます。

型は、言語自体でサポートされていない JavaScript エコシステムの数少ない残りの領域の 1 つです。好き嫌いは別として、多くのチームやプロジェクトにとって、型が JavaScript 開発の不可欠な要素になっていることは否定できません。構文提案は、この事実を正式に認めています。既存のコードを壊したり、パフォーマンスに影響を与える実行時の型チェックを適用したりすることなく、JavaScript である程度の型サポートを提供しようとします。

型は実際に何をすべきか?

「型」の役割は言語によって異なります。汎用デーモン化機能は、特定の変数に格納されるデータの型を表現する型の機能です。次に、追加の意味、機能、および動作がこのベースに重ねられます。

C# や Java などの静的に型付けされたコンパイル済み言語では、コンパイル時に型が適用されます。コードに型の非互換性がある場合、プログラムはコンパイルできません。PHP など、オプションで厳密に型指定されたインタープリター型言語では、型は実行時に適用されます。値の型が使用されているコンテキストと互換性がない場合、プログラムはエラーをスローします。

組み込み型システムの範囲をどこまで拡張すべきかについて、JavaScript コミュニティで活発な議論が行われています。この提案は、その役割を最も基本的な要素、つまり期待される値の型の単純なドキュメントに限定します。これは、実行時に無視される消去型構文としての TypeScript の位置付けとよく一致します。

このモデルの目的は、開発者がコードを書いているときに、潜在的なバグについて即座にフィードバックを提供することです。互換性のある IDE で通常の JavaScript を記述すると、型の問題に関する情報を取得できます。必要に応じて、TypeScript、静的アナライザー、パッケージャーなどの補助ツールを使用して、ソース コードをオンデマンドで監査することもできます。これにより、タイプの問題がある場合、継続的インテグレーション パイプラインでのデプロイがブロックされる可能性があります。

当分の間、これらの機能は JavaScript を最も一般的な開発者のニーズに合わせるのに十分であるように思われます。イントロスペクションやリフレクションなど、他の言語に見られる機能は、JavaScript エコシステムでは通常必要ありません。これは、開発者が TypeScript の消去アプローチに慣れているためです。

既存の代替: Docblocks

提案された消去された注釈構文に似たものが既に存在することに注意してください。おなじみの JSDoc タグは、通常、プレーンな JavaScript コードに型情報を追加するために使用されます。

JSDoc コメントは、さまざまな一般的なツールでサポートされています。ただし、それらは言語の標準化された部分ではなく、コードがどのように機能するかの詳細 (予想される型) を、残りのドックブロックを構成する人間向けのドキュメントと組み合わせる必要があります。

JSDoc 構文も非常に冗長です。必須のタグ名に加えて、通常、上記の例のパラメーター名など、コードに既に存在する要素を繰り返す必要があります。関数シグネチャのパラメーターを変更する場合は、JSDoc タグも変更することを忘れないでください。

新しい構文はドックブロックと機能的に同等かもしれませんが、より合理化されたエクスペリエンスを提供します。型は、個別に作成して維持する必要があるドキュメント ブロックではなく、ソース コードの一部としてターゲットの隣に存在します。

次は何ですか？

ブルームバーグ、イグワリア、および数人の独立した寄稿者を含む Microsoft TypeScript チームと寄稿者は、2022 年 3 月の TC39 プレナリーでフェーズ 0 の提案を提示しました。その後、提案はステージ 1 に移行しました。ただし、採用はまだ先のことであり、エンジン内での実装は「何年も」行われない可能性があります。

この提案の主な目標は、型付けされていない JavaScript コードのロングテールと、より静的に型付けされた開発エクスペリエンスに対する現在の需要とのバランスを取ることです。非推奨の完全にオプションの構文を使用すると、下位互換性が保証されますが、採用とエコシステムの統合を促進する効果がなくなる可能性が高くなります。これに関する議論は、提案が標準化の過程を進むにつれて、新しい意見や視点とともに成長するように見えます.