質問

TypeScript 3.0の新機能として プロジェクトリファレンス . これは *.ts モジュール間のより良い相互作用を示唆しています。残念ながら、これは私が公式のドキュメントから得ることができたすべてです。

どなたか、それがどのような問題を解決し、どのようにそれを行い、そしてどのように私はそれから利益を得るのか、正確に理解するのを助けていただけませんか？私は同様の構造を持つプロジェクトを持っているので、それはそのために非常に役に立つかもしれません (または、そうでないかもしれません)。事前にありがとうございました。

UPD：プロジェクト構成はだいたいこんな感じです。

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

どのように解決するのですか？

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つの大きな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 に変更することは、それだけでかなり大きな意味を持ちます。 tsc には tsconfig.json ファイルが存在する必要があります。
2. 一方 src/tsconfig.json と test/tsconfig.json の両ファイルは src と test を、互いに独立した 2 つの TypeScript プロジェクトに分割しました。

の内容は /{src|test}/tsconfig.json ファイルの内容は、設定に変更がないため、似ています。つまり、"strictness"、出力フォルダ、および他のそのようなパラメータは、維持されるはずです。何もコピーペーストすることなく、それらを類似させるために はすべての設定を任意のファイル に格納し、両方の場所からアクセスできるようにします。 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プロジェクトを保持します。最後に、両者の関係を指定します。 というのも test に依存しているので src は、その test については、何らかの形で "know" しなければなりません。 src . これは非常に明白な2つのステップで行われます。

• 許可 src を "参照" することができます。 として宣言することで、外部から参照されるようになります。

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

• 参照 src から test :

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

は "include" の配列は /tsconfig-base.json は不要になりました。 は、コードの除外が "新しいボーダーを描く" によって行われるため、今は必要ありません。

UPDATE: 以下のセクションは、次のように古くなっているようです。 TypeScript 3.7

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

tsc --build src

このコマンドは src プロジェクトをビルドし、指定された出力フォルダに出力を置きます（この例では /dist を破壊することなく、指定された出力フォルダ (この場合は test を壊すことなく、またコンパイルエラーもなく。