トリプルスラッシュディレクティブは、1つのXMLタグを含む1行のコメントです。コメントの内容はコンパイラディレクティブとして使用されます。
トリプルスラッシュディレクティブは、含むファイルの一番上でのみ有効です。トリプルスラッシュディレクティブの前には、他のトリプルスラッシュディレクティブを含む、単一行または複数行のコメントのみを付けることができます。ステートメントまたは宣言の後にトリプルスラッシュディレクティブが検出された場合、通常の単一行コメントとして扱われ、特別な意味を持ちません。
/// <reference path="..." />
/// <reference path="..." /> ディレクティブはこのグループの中で最も一般的です。ファイル間の依存関係の宣言として機能します。
トリプルスラッシュ参照は、コンパイラにコンパイルプロセスに追加のファイルを含めるように指示します。
outまたはoutFileを使用する場合、出力の順序を制御する方法としても機能します。ファイルは、プリプロセスパス後の入力と同じ順序で出力ファイルの場所に書き出されます。
入力ファイルのプリプロセス
コンパイラは、すべてのトリプルスラッシュ参照ディレクティブを解決するために、入力ファイルにプリプロセスパスを実行します。このプロセスでは、追加のファイルがコンパイルに追加されます。
このプロセスは、ルートファイルのセットから開始されます。これらは、コマンドラインまたはtsconfig.jsonファイルのfilesリストで指定されたファイル名です。これらのルートファイルは、指定されたのと同じ順序でプリプロセスされます。ファイルがリストに追加される前に、そのファイル内のすべてのトリプルスラッシュ参照が処理され、そのターゲットが含まれます。トリプルスラッシュ参照は、深さ優先で、ファイル内で検出された順序で解決されます。
相対パスが使用されている場合、トリプルスラッシュ参照パスは、含むファイルに対して相対的に解決されます。
エラー
存在しないファイルを参照することはエラーです。ファイルが自分自身へのトリプルスラッシュ参照を持つこともエラーです。
--noResolve の使用
コンパイラフラグ noResolve が指定されている場合、トリプルスラッシュ参照は無視されます。新しいファイルの追加や、提供されたファイルの順序の変更は行われません。
/// <reference types="..." />
依存関係の宣言として機能する/// <reference path="..." />ディレクティブと同様に、/// <reference types="..." />ディレクティブは、パッケージへの依存関係を宣言します。
これらのパッケージ名の解決プロセスは、import文でのモジュール名の解決プロセスに似ています。トリプルスラッシュ参照タイプディレクティブを簡単に考えると、宣言パッケージ用のimportのようなものです。
例えば、宣言ファイルに/// <reference types="node" />を含めると、このファイルが@types/node/index.d.tsで宣言された名前を使用していることが宣言されます。そのため、このパッケージは宣言ファイルと共にコンパイルに含める必要があります。
これらのディレクティブは、手動でd.tsファイルを作成する場合にのみ使用してください。
コンパイル時に生成された宣言ファイルの場合、コンパイラは自動的に/// <reference types="..." />を追加します。生成された宣言ファイルの/// <reference types="..." />は、結果のファイルが参照されたパッケージからの宣言を使用する場合にのみ追加されます。
.tsファイルで@typesパッケージへの依存関係を宣言するには、コマンドラインまたはtsconfig.jsonでtypesを使用してください。tsconfig.jsonファイルでの@types、typeRoots、typesの使用の詳細については、そちらを参照してください。
/// <reference lib="..." />
このディレクティブにより、ファイルは既存の組み込みlibファイルを明示的に含めることができます。
組み込みのlibファイルは、tsconfig.jsonのlibコンパイラオプションと同様に参照されます(例:lib="lib.es2015.d.ts"ではなくlib="es2015"などを使用します)。
DOM APIやSymbolやIterableのような組み込みのJSランタイムコンストラクタなど、組み込みの型に依存する宣言ファイルの作成者にとって、トリプルスラッシュ参照libディレクティブが推奨されます。以前は、これらの.d.tsファイルでそのような型の前方/重複宣言を追加する必要がありました。
例えば、コンパイル内のファイルの1つに/// <reference lib="es2017.string" />を追加することは、--lib es2017.stringでコンパイルすることと同じです。
ts/// <reference lib="es2017.string" />"foo".padStart(4);
/// <reference no-default-lib="true"/>
このディレクティブは、ファイルをデフォルトライブラリとしてマークします。これは、lib.d.tsとそのさまざまなバリアントの先頭に見られるコメントです。
このディレクティブは、コンパイラに対して、デフォルトライブラリ(つまり、lib.d.ts)をコンパイルに含めないように指示します。ここでの影響は、コマンドラインでnoLibを渡すことと同様です。
また、skipDefaultLibCheckを渡すと、コンパイラは/// <reference no-default-lib="true"/>を持つファイルのチェックのみをスキップすることに注意してください。
/// <amd-module />
デフォルトでは、AMDモジュールは匿名で生成されます。これは、バンドラ(例:r.js)など、他のツールを使用して結果のモジュールを処理する場合に問題を引き起こす可能性があります。
amd-moduleディレクティブを使用すると、コンパイラにオプションのモジュール名を渡すことができます。
amdModule.ts
ts/// <amd-module name="NamedModule"/>export class C {}
AMDの`define`を呼び出す際に、モジュールに`NamedModule`という名前が割り当てられます。
amdModule.js
jsdefine("NamedModule", ["require", "exports"], function (require, exports) {var C = (function () {function C() {}return C;})();exports.C = C;});
/// <amd-dependency />
注記:このディレクティブは非推奨になりました。代わりに
import "moduleName";文を使用してください。
/// <amd-dependency path="x" />は、結果のモジュールのrequire呼び出しに挿入する必要がある非TSモジュール依存関係についてコンパイラに通知します。
amd-dependencyディレクティブには、オプションのnameプロパティも含まれる場合があります。これにより、amd-dependencyのオプションの名前を渡すことができます。
ts/// <amd-dependency path="legacy/moduleA" name="moduleA"/>declare var moduleA: MyType;moduleA.callStuff();
生成されたJSコード
jsdefine(["require", "exports", "legacy/moduleA"], function (require,exports,moduleA) {moduleA.callStuff();});