web-dev-qa-db-ja.com

TypeScript 3.0でプロジェクト参照を使用する方法

TypeScript 3.0には Project References と呼ばれるこの新機能があります。それはそれらの間の*.tsモジュールのより良い相互作用を示唆しています。残念ながら、これは私が公式ドキュメントから得ることができるすべてです????それはかなり明確かつ簡単に書かれているようですが。

誰もが私が正確に理解するのを手伝ってくれますか、それはどのような問題を解決しますか、それはどのように行いますか？私は似たような構造のプロジェクトを持っているので、非常に役立つかもしれません（またはそうでないかもしれません）。前もって感謝します！

UPD：プロジェクトの構造はおおよそ次のとおりです。

project/
    lib/
        index.ts # defines the original code
    test/
        index.spec.ts # requires lib/index.ts
    package.json
    tsconfig.json
typescriptmodule
38
Dmitry Parzhitsky

質問の投票数がますます増えるので、掘り下げて機能を理解することができました。
この回答がお役に立てば幸いです。

TL; DR：

この機能により、プロジェクトの一部を個別のTypeScriptモジュールとして定義できます。特に、これにより、これらのモジュールを個別に構成したり、個別にビルドしたりすることができます。

前

最初、 プロジェクト構造 は、簡略化すると次のようになります。

/
    src/
        entity.ts # exports an entity
    test/
        entity.spec.ts # imports an entity
    tsconfig.json

エンティティは src/entity.tsモジュールで定義 であり、次に test/entity.spec.tsファイルで使用 です。

ルートフォルダーにあるtsconfig.jsonファイルは1つだけであることに注意してください。これは基本的に、このフォルダーには1つの大きなソリッドTypeScriptプロジェクトが含まれていることを示しています。このプロジェクトには、フォルダーに整理されたいくつかのファイルが含まれています。これらのファイルのいくつかは、他のファイルのテストに使用されます。

ただし、この構造には問題があります。プロジェクトをコンパイルするプロセス（つまり、tsc）もテストファイルをコンパイルし、出力にdist/test/entity.spec.{js|d.ts}ファイルを作成します。これは発生しないはずなので、tsconfig.jsonファイルは、外部での使用を目的としたファイル/フォルダーのみを含むように少し変更されています。

{
    "compilerOptions": {
        // compiler options
    },
    "include": [
        "./src"
    ]
}

これで問題は解決しますが、私の場合、/testフォルダー内のすべてのファイルが、開発プロセス中にTypeScriptコンパイラーによって時々無視されることにもなりました。また、この排他的なアプローチはすべての人に適しているとは限りません。

後

機能を利用する の後、プロジェクト構造は次のように変更されました。

/
    src/
        entity.ts # exports an entity
        tsconfig.json
    test/
        entity.spec.ts # imports an entity
        tsconfig.json
    tsconfig-base.json

変更を見てみましょう：

  1. /tsconfig.jsonの名前を/tsconfig-base.jsonに変更すること自体は、かなり重要なことです。ルートフォルダーはTypeScriptプロジェクトではなくなりました。tscにはtsconfig.jsonファイルが存在する必要があるためです。
  2. 一方、src/tsconfig.jsonファイルとtest/tsconfig.jsonファイルを追加すると、srcとtestの両方が、互いに独立した2つの別個のTypeScriptプロジェクトになります。

/{src|test}/tsconfig.jsonファイルの内容は似ています。構成の変更は予期されていないためです。つまり、「厳密さ」、出力フォルダー、およびその他のそのようなパラメーターは保持する必要があります。何もコピー＆ペーストせずにそれらを類似させるために、 すべての設定は任意のファイルに入れられます 、両方の場所からアクセス可能。この場合、ルートフォルダのtsconfig-base.jsonが選択されています。

// the contents of /tsconfig-base.json
{
    "compilerOptions": {
        // compiler options, common to both projects
    }
}

このファイルは「継承」されます/{src|test}/tsconfig.jsonファイルによって、必要に応じて他のオプションが追加されます。

// the contents of /{src|test}/tsconfig.json
{
    "extends": "../tsconfig-base.json",
    "compilerOptions": {
        // additional compiler options, specific to a project
    }
}

このパターンが、実装が不完全なabstract classを定義し、2つの個別の「コンクリート」クラスで拡張するのと似ていることに注目してください。

現在、/srcおよび/testフォルダーは、基本的に、同様の構成の2つの個別のTypeScriptプロジェクトを保持しています。最後に行うことは、2つの間の関係を指定することです。 testはsrcに依存しているため、testはsrcについて何らかの形で「知っている」必要があります。これは2つのかなり明白なステップで行われます。

  • srcが「参照される」ことを許可する 外部から「複合」として宣言することにより：

    // in /src/tsconfig.json
{
    "extends": "../tsconfig-base.json",
    "compilerOptions": {
        // compiler options
        "composite": true
    }
}

  • 参照src from test ：

    // in /test/tsconfig.json
{
    "extends": "../tsconfig-base.json",
    "references": [
        { "path": "../src" }
    ]
}

"include"の/tsconfig-base.json配列 現在は不要 。コードの除外は「新しい境界線の描画」によって行われるためです。

更新：次のセクションは TypeScript 3.7以降古くなっているようです

現在、testプロジェクトには、srcプロジェクトが存在するために*.d.tsファイルが必要です。つまり、テストを実行する前に、srcを個別にビルドしておく必要があります。これは tscの新しいモードを使用 によって実行され、--buildオプションによってトリガーされます。

tsc --build src

このコマンドはsrcプロジェクトをビルドし、testを壊したり、コンパイルエラーを失うことなく、指定した出力フォルダー（この場合は/dist）に出力を配置します。

46
Dmitry Parzhitsky

他のTypeScriptアプリケーションで使用される、開発したTypeScriptライブラリ用です。したがって、たとえば、lodashのようなユーティリティライブラリを作成し、依存するアプリケーションと一緒にアクティブに開発している場合、「tsconfig.json」 `のreferencesを使用すると、ソースコードを参照できます、およびutilソースが変更されたときに依存アプリケーションを自動的に再構築する（IE：tscがutil ts libでソースコードの変更を検出する）

特に私の場合、referencesをnpm linkおよびgit submodulesと組み合わせて使用​​し、ts 2.x日よりもはるかにうまく機能しています。

3
JasonS