おやまあー！

：+1：

うん！ これは、提供したユースケースに最適です。 私たちが使用するツールに、コードがどのように消費されることを意図しているかについてのより良いビューを提供することは、間違いなく正しいことです。 誤って.d.tsファイルにF12するたびに、子猫の首を絞めたくなる！

ジョナサン、

親切なフィードバックとこれを引き受けることを決定してくれてありがとう。 TypeScriptは非常に優れたツールであり、この機能は、懸念事項の厳密な分割に依存する巨大なプロジェクト（たとえば、AzureポータルやプロジェクトMonacos 100klocを超える世界と多くの独立したチーム）。 言い換えれば、これは本当に「普通の人々」を助けるでしょう。 また、 @ NoelAbrahams （＃2180）など、他の人がすでにこのためのものを提案しているので、ここで独創性を主張することはできません。 これは私がしばらくの間必要としていたものです。

あなたの提案は素晴らしいと思います。 私が今閉じている私の提案（＃3394）に対して私が見る唯一の欠点は、参照のためのフォールバックメカニズムの欠如です。

ここで詳しく説明した次の実際のシナリオについて考えてみます。https：

別のプロジェクトcsproj2tsに依存するTypeScriptプロジェクトgrunt-tsがあります。 grunt-tsで作業する人は、機能の範囲が非常に限られているため、csproj2tsでも作業したいと思うことはほとんどありません。 ただし、私のような人にとっては、両方のプロジェクトで同時に作業し、リファクタリングを実行したり、定義に移動したり、プロジェクト全体のすべての参照を検索したりできると便利です。

私が提案をしたとき、依存関係オブジェクトは名前付きフォールバックを持つオブジェクトリテラルであることを提案しました。 あなたの提案にもっと一致するバージョンは次のようになります：

"dependencies": {
   "csproj2ts": ["../csproj2ts","node_modules/csproj2ts/csproj2ts.d.ts"],
   "SomeRequiredLibrary": "../SomeRequiredLibraryWithNoFallback"
}

それを単純化して配列のままにするために、grunt-ts tsconfig.jsonファイルの将来の仮想dependenciesセクションの次の代替実装を提案します。

"dependencies": [
   ["../csproj2ts","node_modules/csproj2ts/csproj2ts.d.ts"],
   "../SomeRequiredLibraryWithNoFallback"
]

dependencies内の各配列タイプのアイテムの解決ルールは次のようになります。それぞれにある_first_アイテムが使用され、残りは無視されます。 文字列タイプのアイテムは、ジョナサンの提案が述べているように処理されます。

これは実装が非常に複雑なソリューションですが、開発者（およびライブラリの作成者）に_はるかに大きな_柔軟性を提供します。 csproj2tsで開発する必要がない（したがって../csproj2ts/tsconfig.jsonファイルがない）開発者の場合、依存関係はコンパイルコンテキストに追加される定義ファイルになります。 ../csproj2ts/tsconfig.jsonファイルを_do_している開発者の場合、提案は上記で説明したとおりに機能します。

上記の例では、 "../SomeRequiredLibraryWithNoFallback"は既存の提案と同じように存在する必要があり、存在しないとコンパイラエラーになります。

よろしくお願いします。

ここには、分解する必要のある2つの問題があり、ビルドがあり、言語サービスのサポートがあります。

ビルドの場合、tsconfigがこれに適した場所ではないと思います。 これは明らかにビルドシステムの問題です。 この提案では、typescriptコンパイラは次のビジネスに関与する必要があります。

• 依存関係を理解する
• アサートの最新チェック
• 構成管理（リリースとデバッグ）

これらはすべて明らかにビルドシステムの責任です。 これらは難しい問題であり、MSBuild、grunt、gulpなど、それを実行するツールがすでに存在します。
tsconfigとtscがビルドドライバーになったら、すべてのCPUを使用して無関係のサブツリーをビルドするか、プロジェクトごとにビルド後およびビルド前のコマンドを実行し、場合によっては他のプロジェクトもビルドする必要があります。 繰り返しになりますが、私はそれらが何をするのかが得意なビルドツールがそこにあると思います、そして私たちがそれを再現する必要はありません。

言語サービスについては、
ツールが複数のtsconfigファイルについて知っていて、それから推測してさらに役立つことができるのは問題ないと思いますが、それはビルドに影響を与えるべきではありません。 私は次のようなことを考えます：

"files" : [
    "file1.ts",
    {
        "path": "../projectB/out/projectB.d.ts",
         "sourceProject": "../projectB/"
     }
]

tscは「パス」のみを調べますが、ツールは他の情報を調べて、できる限り役立つように努めることができます。

私は問題の存在を認めますが、ビルドとツールの一括処理が正しい解決策であるとは思いません。 tsconfig.jsonは、ビルドシステムにならないように、構成バッグ（つまり、応答ファイルの代わりのjson）のままにする必要があります。 1つのtsconfig.jsonは、1回のtsc呼び出しを表します。 tscは、単一のプロジェクトコンパイラとして残す必要があります。

VSのMSBuildプロジェクトは、ビルドシステムを使用してIDE機能をビルドする例ですが、大きすぎるため、pplはこれに満足していません。

お返事ありがとう、モハメド。 私が理解しているかどうかを確認するために言い換えさせてください。

• マルチプロジェクトビルドを調整するタスクは、専用のビルドツールのドメインのままである必要があると思います。
• TypeScript言語サービスのこの提案には何かがあると思います。
• このtsconfig.json tsc --projectを実行することは、 tsc file1.ts ../project/out/project.d.tsを実行することと同じだと思います。 ただし、そのようなプロジェクトをVSまたはTypeScript言語サービスを使用する別のエディターで開くと、「定義に移動」して、開発者を機能が定義された_実際のTypeScriptファイル_に移動できます（ projectB.d.ts定義ではありません）。

私はその権利を持っていますか？

もしそうなら、これは非常に公平だと思います。 私の最初の提案（https://github.com/Microsoft/TypeScript/issues/3394）では、出力される場所から出力された結果をコピーするステップが含まれていなかったため、私のアイデアは不完全であると言いました参照ライブラリ内で、参照ライブラリが実行時にそれらを予期する場所。 「本当に必要なのは言語サービスのサポートなのに、なぜ建物の途中まで行くのか」ということだと思います。

あなたの例でデータを少し変更するために、あなたはこのようなものを喜んでサポートしますか？

"files" : [
    "file1.ts",
    {
        "path": "externalLibraries/projectB.d.ts",
         "sourceProject": "../projectB/"
     }
]

現在のプロジェクトには、デフォルトで使用されるprojectBの定義が付属していると想定されていますが、projectBの実際のソースが使用可能な場合は、代わりに実際のソースが使用されます。

@nycdotnetあなたはそれを正しく要約しました。 緩く結合され、異なるビルドツールと異なるIDEを組み合わせて組み合わせることができるシステムを作成したいのですが、それでも優れた設計時のエクスペリエンスを得ることができます。

いいね！

私は@mhegazyに同意し

ファイルとパッケージの解決は、使用しているビルドシステム（browserify、systemjs、webpackなど）の責任であるため、ツールが機能するには、言語サービスが他のビルドシステム/プラットフォームと同じ方法でファイルを解決できる必要があります。使っている。 これは、ビルドシステムごとにカスタムLanguageServicesHostを実装するか、tsconfig.jsonに正しいマッピングエントリを生成するツールを提供することを意味します。 これらのいずれかが許容されます。

@nycdotnet複数のフォールバックパスのユースケースは、 npm link ../csproj2tsを使用した方が適切だと思いますか？

私は@mhegazyに同意し、コンパイラー/トランスパイラーとは別にビルドを維持する必要があります。 セクションに* .tsファイルがリストされていない場合でもスキャンされると想定して、ファイルセクションにtsconfig-> tsconfig依存関係を含めるのが好きです。 例えば

"ファイル"：[
{{
"パス"： "externalLibraries / projectB.d.ts"、
"sourceProject"： "../projectB/"
}
]

tsconfig.jsonファイルを含むディレクトリとサブディレクトリ内のすべてのtsファイルが引き続き含まれます。

@dbaeumer次に、別のプロパティに配置したいですよね？ 現在、ファイルが定義されている場合、それは常に使用され、include * .ts部分は無視されます。

@mhegazyは必ずしも別のセクションである必要はありませんが、最終的には明確になります。 tsconfig-> tsconfigの依存関係を使用する場合、避けたいのはすべてのファイルを強制的にリストすることです。 上記の例では、コンパイラにフィードするための* .tsファイルをリストしません。

これは大いに必要だと思います。 ただし、ビルドの質問は避けられないと思います。 これは、この提案と一緒にビルドシステムを実装する必要があるという意味ではありませんが、提案されたような構成で機能するいくつかの優れたガイダンスを検討する必要がありました。 正しく理解することは簡単ではありません（そして、Visual Studioでそれを解決する必要があります）。

上記の提案（.d.tsとソースの両方が参照されている場合）では、.d.tsが古くなっている（つまり、再構築する必要がある）かどうかを検出しますか？ リファクタリング/名前の変更などの操作はプロジェクト間で機能しますか（つまり、次のビルドで上書きされる.d.tsファイルだけでなく、参照されているプロジェクトソースの名前を更新します）？ GoToDefは、参照されているプロジェクトの元のコード（プロジェクト全体の巨大な.d.tsファイルの途中ではありません）に移動しますか？ これらは、参照されたプロジェクトのソースを解決し、場合によっては分析する必要があることを意味しているように思われます。その場合、.d.tsは役に立ちますか？

現在の一般的なソリューションでは、一方のプロジェクトのビルド出力として.d.tsがあり、もう一方のプロジェクトの入力として参照されます。 これはビルドには問題なく機能するため、変更する必要はありません。

問題は編集シナリオです。 編集中に生成されたファイルを調べたくない。 私が提案する解決策は、生成された.d.tsがどこから来たのかについての「ヒント」を提供することです。 言語サービスは.d.tsをロードせず、代わりにヒントパスから「プロジェクト」をロードします。 このように、goto defは.d.tsの代わりに実装ファイルに移動し、同様にエラーはコンパイルを必要とせずに機能します。

名前の変更などの操作は、あるプロジェクトから別のプロジェクトに「伝播」し、同様に参照を検索します。

現在、tsconfig.jsonファイルを見つけるのは完全にホスト（IDEなど）次第ですが、TSはそれを読み取って解析するためのAPIを提供します。 複数のtsconfig.jsonが階層的に配置されている場合、これが機能することをどのように想像しますか？ ホストはまだ初期ファイルの解決に責任がありますが、他のファイルの解決には責任がありませんか、それともホストはすべてのtsconfigの解決に責任がありますか？

利便性/慣習と柔軟性の間にはトレードオフがあるようです。

これは、＃2568で説明されているように（または少なくとも相対的なインポートがある）d.tsファイルをビルドする機能から始まりませんか？

@spionここに依存関係があるかどうかわかりません。 プロジェクトの複数の出力を持つことができますが、単一の選択ファイルではありません。 ビルドシステムはそれを認識し、依存プロジェクトへの入力としてそれらを配線できる必要があります。

@mhegazyおっと、ごめんなさい。 この問題をもう一度見てみると、これは言語サービスに関連しているようです。 私は以下を読みました

• 中規模プロジェクト：標準ビルドと共有コンポーネントを使用するプロジェクト

そして、プロジェクトの一部が外部モジュールであるnpm / browserify（またはwebpack）ビルドworfklowsのより良いサポートに関連していると自動的に想定しました。

AFAIK外部モジュール用の.d.tsファイルを生成する方法はまだありませんか？ その場合、言語サービスが外部モジュールをインポートするプロジェクトをリンクできる唯一の方法は、tsconfig.jsonに次のようなものを含めることです。

{ 
  "provides": "external-module-name"
}

これは、プロジェクトが別のtsconfig.json参照されたときにLSに通知します。

AFAIK外部モジュール用の.d.tsファイルを生成する方法はまだありませんか？

私はこれが真実だとは思いません。 tsc --m --dを呼び出すと、それ自体が外部モジュールである宣言ファイルが生成されます。 解決ロジックは.tsを見つけようとしますが、そうでない場合は同じ名前の.d.tsを見つけます。

@spion TypeScriptは、 @ mhegazyが言ったように、外部モジュール用のd.tsファイルを生成できますが、これにより、ライブラリのTypeScript定義が通常消費される方法とは異なり、定義とソースファイルの比率が1：1になります。 これを回避する1つの方法は、次のTypeStrongライブラリです： https ：

@mhegazy申し訳ありませんが、私は「アンビエント外部モジュール」を意味していました。つまり、TypeScriptでexternal-module-nameを記述し、そのクラスの1つを別のモジュールからインポートした場合：

import {MyClass} from 'external-module-name'

tsc 'external-module-name'を宣言する適切な.d.tsファイルを生成させる方法はありません

@nycdotnet私はdts-bundleとdts-generatorを知っていますが、それでも言語サービスが他のプロジェクトのソースを知っている場合は、インポートを正しく追跡できるようにするために提供するモジュール名も知っている必要があります

この機能のステータスはどうなっていますか？ これは中規模のプロジェクトにとって重要なオプションのようです。 特定の「requirejs」構成を使用して、さまざまなフォルダーにソースがあるプロジェクトをどのように構成しますか？

@llgcodeはhttps://github.com/Microsoft/TypeScript/issues/5039をご覧ください。これはtypescript@nextで入手できるはずです。

中規模のプロジェクトで必要な方法でサブプロジェクトをコンパイルするタスクを含むgulpfileを作成するのは、それほど難しいことではありません。 私はこれを小規模なプロジェクトでも行っています。 私がtsconfig.jsonを使用する唯一の理由は、VSCodeのためです

まず、私はgulpを使用しません。 次に、これは、毎回再コンパイルしたくない大きなプロジェクトになる可能性があります。 しかし、gulpで良い解決策がある場合は、これを行う方法を教えてください。

@llgcodeええと、 gulp.task()を使用して、必要な数のタスクを定義するgulpfile.jsを作成します。 タスク内では、 gulp.src()を含む入力ファイルのストリームを取得し、コンパイル、連結、ミニファイ、ソースマップ、アセットのコピーなどの変換のパイプラインを介してそれらを.pipe()取得できます。 NodeモジュールとNPMモジュールで可能なことは何でもします。
複数のプロジェクトをコンパイルする必要がある場合は、これを行うタスクを定義するだけです。 複数のtsconfig.jsonを使用する場合は、gulp -typescriptでサポートされています。または、jsonファイルを読み取ることもできます。 インクリメンタルビルドも可能です。 プロジェクトがどのように構成されているか、異なるリポジトリにプロジェクトがあり、サブモジュールを使用しているかどうかなどはわかりません。 しかし、gulpは100％柔軟性があります。

わかりました、ありがとうは素晴らしいツールのようです。 require（ "mylibs / lib"）のようなマッピングでrequireがあり、ファイルがたとえばproject / src / lib.jsフォルダーにある場合、アトムでは完了が機能せず、typescriptまたはgulpがどのように解決されるかわかりません「mylibs」とローカルパスを使用して行われるマッピング/構成。 したがって、＃5039のこの新しいオプションパスは、この問題の良い解決策だと思います。

@llgcode gulpを使用すると、グロブを含むすべてのファイル（.d.tsファイルを含む）を取得できます。https： //www.npmjs.com/package/gulp-typescript#resolving-filesを参照して

TypeScriptはここで多くのことを行おうとしていると思います。これはトランスパイラーであり、ビルドツールではありません。 提案で言及されているような「依存関係」の管理は、実際にはパッケージマネージャーまたはバージョン管理システムのタスクであり、それらを相互に接続することはビルドツールのタスクです。

@felixfbecker同意しません。 私が知っているすべてのコンパイラ（型チェック付き）には、このようなオプションがあります。 例えば：
gcc->ファイルを含める
java->クラスパスとソースパス
行く-> GOPATH
python-> PYTHONPATH
コンパイラー/トランスパイラーは、トランスパイルする必要のあるソースファイルを知る必要があります。どのソースファイルが単にinclude / libファイルであるかを知る必要があります。
ファイルが変更されたときに何をすべきかを知るには、gulpのようなビルドツールが必要です。

@llgcodeで同意します。 また、コンパイラとして公開するだけでなく、TypeScriptは言語サービスとしても公開します。言語サービスは、IDEに構文の強調表示（実際の検出）と完了機能を提供します。 また、依存関係ツリーをたどる必要があります。

@ llgcode @ unional有効なポイント。 また、ヘルプを作ることであることが一つのことfilesあなたが含めたいすべてのフォルダ内のすべてのファイルを定義することができるようにグロブを受け入れるtsconfig.jsonにプロパティを。 しかし、私はあなたがどこから来ているのか、そしてなぜ大規模なプロジェクトに複数のtsconfig.jsonが必要なのかを理解しています。

CommonJSのAFAIKこれは、 node_modulesおよびnpm link ../path/to/other-project介してすでにサポートされています

プロジェクト間でライブラリを再利用し始めるとすぐにnpmリンクが機能しません。 独自の2つの別々のプロジェクト間で共通のライブラリを使用する場合（rxjsを例にとると）、typescriptは「ObservableはObservableに割り当て可能ではない」ことを示します。 これは、同じライブラリであるにもかかわらず、インクルードパスが2つの異なるnode_modulesフォルダーへのシンボリックリンクフォルダーをたどっているためです。 回避策により、基本的に大規模プロジェクトオプションに戻って、gulpタスクまたはローカル/プライベートnpmリポジトリが構築されます。

@EricABCは、おそらくアンビエント外部モジュール宣言を使用しているためです。この場合、新しくサポートされたnode_modulesベースの.d.tsファイルの定義も含める必要があります。 それ以外は、TSタイプは構造的にチェックされるだけなので問題はないはずです。したがって、構造が一致している限り、TSタイプが異なるモジュールからのものであるか、異なる名前であるかは問題ではありません。

ありがとう@spion 、それがファイルベースであると仮定しただけで、あなたが私を苦痛から救うつもりのようです。

また、tsconfig.jsonのfilesプロパティにglobsを受け入れさせることも役立つ可能性があります...

議論中のincludeプロパティがあります

質問と備考：

• dependenciesは、tscで許可されているため、完全なtsconfig.jsonパスを許可する必要があります
• filesすでに存在し、問題がないのに、なぜ新しいキーワード（ dependencies ）を導入するのですか？
  例：

{
    "compilerOptions": {
        // ...
    },
    "files": [
        "../common/tsconfig.json", // <== takes the `files` part of the tsconfig.json
        "../common/tsconfig.util.json", // <==
        "core.ts",
        "sys.ts"
    ]
}

• 依存関係tsconfig.jsonがcompilerOptionsも指定している場合はどうなりますか？

さらに進んで/ワイルドにしましょう:-)そしておそらく（将来的に） compilerOptions 、 exclude ...が別のtsconfig.jsonを参照することを許可します：

// File app/tsconfig.json
{
    "compilerOptions": "../common/tsconfig.compilerOptions.json",
    "files": [
        "../common/tsconfig.json",
        "../common/tsconfig.util.json",
        "core.ts",
        "sys.ts"
    ],
    "exclude": "../common/exclude.json"
}

// File ../common/tsconfig.compilerOptions.json
{
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true,
        "sourceMap": true
    }
}

// File ../common/exclude.json
{
    "exclude": [
        "node_modules",
        "wwwroot"
    ]
}

// File ../common/tsconfig.util.json
{
    "files": [
        "foo.ts",
        "bar.ts"
    ]
}

ロジックがあります： files 、 compilerOptions 、 exclude ...他のtsconfig.jsonファイルを参照でき、他のtsconfigから一致するキーワード部分のみを「取得」します.jsonファイル=>簡単でスケーラブル。 したがって、必要に応じてtsconfig.jsonを複数のファイルに分割し、それらを再利用できます。

あなたの議論の一部を読んで、この「言語サービス」/ goto定義を正しくすることが最も関連性があります。 JavaScriptデバッガーはsourceMapsを使用します。 さて、tscが.jsだけでなく.d.tsファイルにもsourceMapデータを生成した場合...

それを超えて、tsconfig.jsonファイル内から子プロジェクトのビルドをトリガーすることにはあまりメリットがありません。 この基本的な種類のビルド時の依存関係が必要な場合は、単純なシェルスクリプトで十分です。 一方、インテリジェントなインクリメンタルビルディングが必要な場合、提案されたアプローチは単純すぎるように思われます。 多くのシナリオで、tscは、とりわけ1つのビルドステップにすぎません。 tsconfig.jsonにtscの依存関係を書き込むのは奇妙ですが、残りのファイルには他のファイルがありますか？ 繰り返しになりますが、tscが唯一のビルドステップである単純な場合、シェルスクリプトが実行します。

とにかく、.jsファイルと同じように.d.tsファイルでソースマッピングを生成するのはどうですか？

単にノードモジュール+ npmリンクを使用しますが、機能しないのはmoduleResolution：ノードがES6モジュールと互換性がないことだけです。これにより、インライン化/ツリーシェイクの最適化が可能になります（＃11103も参照）。

話題から外れるわけではありませんが、いくつかの点で、これは複数のノードパッケージプロジェクトをローカルで操作するという課題と並行しているように見えます。 「npmlink」を使うほど簡単ではないと思います。 ビルドスクリプトが異なる場合があります。すべてを正しい順序で実行する必要があります。段階的に実行するのは難しく、監視モードを使用するのは難しく、デバッグも難しく、ソースマップの解決も難しくなります。 選択したエディターによっては、これはさらに難しい場合があります。

通常、私はあきらめて、すべてを1つの巨大なプロジェクトにまとめ、安定したら別々のパッケージに分割しますが、それは課題に直面する頻度が少ないために役立ちます。 私は全体の経験が本当に、本当に迷惑だと思います。 私は何かが足りないのですか？

ですから、これがどうなるにせよ、私はこの開発体験全体に対して最終的にエレガントなソリューションを手に入れることができることを願っています。

これは私たちの日常の仕事に最適だという点で、ただチャイムを鳴らしてください！

Web開発の性質上、複数のtsプロジェクトがあり、各プロジェクトには、単一のjsファイル（ --outFile ）にコンパイルされた複数のtsファイルが含まれています。 これらは、アプリのようなプロジェクト（特定のことを行うか、特定の機能を追加する）またはlibのようなプロジェクト（アプリの再利用可能なコード）のいずれかです。 多くの場合、これらのtsプロジェクトの複数に同時に取り組み、アプリの開発を容易にするためにライブラリを拡張します。 しかし、私の仲間の開発者の誰もが、いつでもローカル環境にすべてのtsプロジェクトを持っているとは思いません。

ワークフローを改善するために、現在のオプションは次のとおりです。

• すべてを1tsプロジェクトに投入します
  
  
  
  • .tsファイルを直接参照できます。これは、d.tsファイルを使用するよりもはるかに優れています。
  
  
  • ただし、アプリのモジュール性（機能またはページ固有）を維持しながら、インターウェブ経由で要求されるjsファイルを制限する必要があるため、ファイルのセットをマッピングおよび連結するための外部ツールが必要です。
  
  
  • 前述のように、これらのtsプロジェクトのすべてが常にすべての人に必要なわけではないため、ファイルシステムに大きな肥大化が生じます。 プロジェクトXで作業している人はプロジェクトA、B、Dが必要かもしれませんが、Yで作業している人はAとCが必要かもしれません。
  
  
• プロジェクトを分離しておく（現在の状況）
  
  
  
  • .tsファイルを直接含めると出力に追加されるため、他のts-projectsからコンパイルされたd.tsファイルを参照する必要があります。 自分のソースコードに直接f12を入れることができれば、はるかに高速になります。
  
  
  • また、これらのプロジェクトの複数を同時にコンパイルするためのツール/スクリプトを追加する必要があります。 現在、複数の端末からtsc -d -wコマンドを開始するか、tsconfigが見つかったすべてのサブディレクトリに対してそれを実行するスクリプトを起動します。
  
  
  • 他のツールがこれに役立つことを理解しています（例：gulp）、またはtsconfigsのファイルグロブで何かを理解できるかもしれませんが、それはd.tsファイルの最初の問題には役立ちません。
  
  

私たちのプロジェクトは、ライブラリの開発をアプリから厳密に分離するのに十分な大きさではありませんが、すべてを単純にまとめることができるほど小さくはありません。 私たちはtypescriptで優雅なオプションを欠いていることに気づきます。

dependenciesがその両方の世界で最高のオプションになることができれば、それは驚くべきことです。 の機能依存関係のすべてのtsファイルにタグを付けますが、その依存関係自体のtsconfigに従って出力をコンパイルします。

このトピックに関する更新はありますか？ 互いに独立してコンパイルする複数のtypescriptプロジェクトを作成するにはどうすればよいですか？ tsconfig.jsonでそのような依存関係をどのように説明できますか？

これは、「プロジェクト参照のサポート」というタイトルで、将来のセクションのロードマップに含まれるようになりました。 したがって、 .tsconfigファイルは、依存関係として別の.tsconfigファイルをリンクできると思います。

このトピックに関する更新はありますか？ 互いに独立してコンパイルする複数のtypescriptプロジェクトを作成するにはどうすればよいですか？ tsconfig.jsonでそのような依存関係をどのように説明できますか？

ビルドの依存関係は、ビルドシステムでエンコードする必要があります。 gulp、grunt、broccoli、msbuild、basalなどのビルドシステムは、このようなケースを処理するために構築されています。
タイプ情報の場合、一方のプロジェクトの出力には.d.tsが含まれている必要があり、それはもう一方のプロジェクトへの入力として渡される必要があります。

@mhegazy私たちのプロジェクトはこのように機能します。 私たちは、各パッケージはpackage.jsonで独自の依存関係を持っている、とのものと同じ依存関係、レルナmonorepoにパッケージの数を持っている"types"自分でプロパティtsconfig.json 。 各プロジェクトは--outFileコンパイルされ（ESモジュールにまだ移動されていない古いプロジェクトです）、 "typings" package.jsonキーはバンドルされた.d.ts指します

バンドル/ウォッチングにはgulpを使用します。

ほとんどの部分で機能しますが、いくつかの問題があります。

• ＃15488や＃15487などの問題があるため、参照を正しく機能させるには、明示的なリンクが必要です。
• Go-to-definitionを使用すると、バンドルされた.d.tsファイルに移動します。 理想的には、これにより別のプロジェクトのソースに移動します。
• フルビルドを実行する最速の方法はlerna run build --sort （事実上各ディレクトリでtsc ）です。これは、パッケージごとに1つのTypeScriptコンパイラプロセスを生成し、多くの繰り返し作業を実行するため、追加のオーバーヘッドがあります。 。

私たちも他の人が説明したのと同じ状況にあるので、私はこの問題に注意を払っています。
それぞれがtsconfig.jsonファイルを持つ複数の「プロジェクト」。

@mhegazyが指摘したように、ビルドプロセスが機能しています。各プロジェクトは.d.tsファイルを発行し、それが依存プロジェクトの入力として使用されます。

本当の問題はIDEのサポートです。参照を探すとき、それらは単一のtsconfig.jsonの範囲内でのみ見つかります。 さらに悪いことに、 tsconfig.jsonスコープ外の依存ファイルは再コンパイルされないため、変更されたファイルのカスケード効果はプロジェクト間で伝播しません。 これは私たちのプロジェクトのメンテナンスにとって非常に悪いことであり、IDEでキャッチされた可能性のあるビルドエラーを引き起こすことがあります。

おやまあー

これが欲しい更新されたシナリオには、Reactコンポーネントが含まれます。 当社のすべてのアプリケーションでUIコンポーネントを適切にレンダリングするJSXモジュール（原子、分子、および有機体）を含むコンポーネントリポジトリがあります。 このコンポーネントリポジトリは、すべてのフロントエンド開発者が個々のアプリケーションで作業するときに使用されます。 特定のアプリケーションのUIを編集し、共通のUIコンポーネントリポジトリに「定義に移動」できるTypeScript言語サービスエクスペリエンスがあれば、それはとても素晴らしいことです。 今日、これらのコンポーネントを個別にバンドルしてコピーする必要があります。 これは、私が修正してもらいたい「独自のプロジェクト配管を作成する」問題です（.NETの世界では、ソリューションの下にプロジェクトがあるという非常に素晴らしい話があります）。

プロジェクトリファレンス：TypeScriptの組み込みスケーラビリティ

序章

TypeScriptは数十万行のプロジェクトにスケールアップしましたが、組み込みの動作としてこの種のスケールをネイティブにサポートしていません。 チームはさまざまな効果の回避策を開発しており、大規模なプロジェクトを表すための標準化された方法はありません。 タイプチェッカーのパフォーマンスは時間の経過とともに大幅に改善されましたが、TSが合理的に取得できる速度に関しては依然として厳しい制限があります。
インタラクティブなシナリオで言語サービスが「無限に」スケールアップするのを防ぐ32ビットアドレス空間などの制約。

直感的には、フロントエンドコンポーネントでJSXの1行を変更しても、500,000LOCプロジェクトのコアビジネスロジックコンポーネント全体を再タイプチェックする必要はありません。 プロジェクト参照の目的は、開発者にコードを小さなブロックに分割するためのツールを提供することです。 ツールが一度に小さな作業チャンクで動作できるようにすることで、応答性を向上させ、コア開発ループを強化できます。

現在のアーキテクチャでは、パフォーマンスやメモリ消費の大幅な改善という点で、「フリーランチ」がほとんど残っていないと考えています。 代わりに、このパーティショニングは明示的なトレードオフであり、先行作業を犠牲にして速度を向上させます。 開発者は、システムの依存関係グラフについて推論するために時間を費やす必要があり、ツールをさらに強化するまで、特定のインタラクティブ機能（プロジェクト間の名前変更など）が利用できない場合があります。

このシステムによって課せられる主要な制約を特定し、プロジェクトのサイズ設定、ディレクトリ構造、およびビルドパターンのガイドラインを確立します。

シナリオ

考慮すべき3つの主要なシナリオがあります。

相対モジュール

一部のプロジェクトでは、相対的なインポートを広範囲に使用../../core/utils/otherModようなパスを見つけるのが一般的ですが、これらのリポジトリでは通常、よりフラットなディレクトリ構造が推奨されます。

例

KhanAcademyのペルセウスプロジェクトの例を次に示します。

https://github.com/Khan/perseus/blob/master/src/components/graph.jsxから適応

const Util = require("../util.js");
const GraphUtils = require("../util/graph-utils.js");
const {interactiveSizes} = require("../styles/constants.js");
const SvgImage = require("../components/svg-image.jsx");

観察

ディレクトリ構造はプロジェクト構造を意味しますutil 、 styles 、およびcomponentsがおそらく独自のプロジェクトであると推測できます。 ただし、これらのディレクトリが非常に小さく、実際には1つのビルドユニットにグループ化される可能性もあります。

モノレポ

モノリポジトリは、非相対パスを介してインポートされる多数のモジュールで構成されます。 サブモジュール（ import * as C from 'core/thing ）からのインポートが一般的である可能性があります。 常にではありませんが、通常、各ルートモジュールは実際にはNPMで公開されます。

例

https://github.com/angular/angular/blob/master/packages/forms/src/validators.tsから適応

import {InjectionToken, ɵisObservable as isObservable, ɵisPromise as isPromise} from '@angular/core';
import {forkJoin} from 'rxjs/observable/forkJoin';
import {map} from 'rxjs/operator/map';
import {AbstractControl, FormControl} from './model';

観察

除算の単位は、必ずしもモジュール名の先頭部分である必要はありrxjsは、スコープ付きパッケージ（ @angular/core ）と同様に、実際にはそのサブパーツ（ observable 、 operator ）を個別にコンパイルします。

アウトファイル

TypeScriptは、入力ファイルを単一の出力JavaScriptファイルに連結できます。 参照ディレクティブ、またはtsconfig.jsonのファイル順序は、結果のファイルの決定論的な出力順序を作成します。 これが新しいプロジェクトに使用されることはめったにありませんが、古いコードベース（TypeScript自体を含む）の間では依然として普及しています。

例

https://github.com/Microsoft/TypeScript/blob/master/src/compiler/tsc.ts

/// <reference path="program.ts"/>
/// <reference path="watch.ts"/>
/// <reference path="commandLineParser.ts"/>

https://github.com/Microsoft/TypeScript/blob/master/src/harness/unittests/customTransforms.ts

/// <reference path="..\..\compiler\emitter.ts" />
/// <reference path="..\harness.ts" />

観察

この構成を使用する一部のソリューションは、個別のscriptタグ（または同等のもの）を介して各outFileをロードしますが、他のソリューション（TypeScript自体など）は、モノリシック出力を構築しているため、前のファイルを連結する必要があります。

プロジェクトリファレンス：新しい分離ユニット

実際のプロジェクトとの相互作用からのいくつかの重要な観察：

• TypeScriptは、実装（.d.ts以外）コードが50,000 LOC未満のプロジェクトをチェックする場合、通常「高速」（<5-10s）です。
• .d.tsファイル、特にskipLibCheck未満のファイルは、タイプチェックとメモリコストの点でほぼ「無料」です。
• ほとんどすべてのソフトウェアは、50,000LOC未満のコンポーネントに細分化できます
• ほとんどすべての大規模なプロジェクトでは、適度なサイズのサブコンポーネントを生成する方法で、ディレクトリごとにファイルの構造化をすでに課しています。
• ほとんどの編集は、ソリューション全体の再チェックまたは再送信を必要としないリーフノードまたはニアリーフノードコンポーネントで行われます。

これらをまとめると、一度に1つの50,000 LOCチャンクの実装コードのみをタイプチェックすることが可能である場合、インタラクティブなシナリオでは「遅い」対話はほとんどなく、メモリが不足することはほとんどありません。

依存ユニットの実装コードがチェックされていない2つのTypeScriptコンパイルユニット間の新しい種類の依存関係を宣言する新しい概念であるプロジェクトリファレンスを紹介します。 代わりに、決定論的な場所から.d.ts出力をロードするだけです。

構文

新しいreferencesオプション（TODO：Bikeshed！）がtsconfig.json追加されました：

{
  "extends": "../tsproject.json",
  "compilerOptions": {
    "outDir": "../bin",
    "references": [
      { "path": "../otherProject" }
    ]
  }
}

references配列は、このプロジェクトから参照する他のプロジェクトのセットを指定します。
各referencesオブジェクトのpathは、 tsconfig.jsonファイルまたはtsconfig.jsonファイルを含むフォルダーを指します。
他のオプションは、それらのニーズを発見したときにこのオブジェクトに追加される場合があります。

セマンティクス

プロジェクト参照により、次の動作が変更されます。

• モジュール解決がプロジェクトのrootDirのサブディレクトリにある.tsファイルに解決される場合、outDirにある.d.tsファイルに解決されます。
  
  
  
  • この解決に失敗した場合は、おそらくそれを検出して、単純な「ファイルが見つかりません」ではなく、よりスマートなエラー（ Referenced project "../otherProject" is not builtなど）を発行できます。
  
  
• 他に何もありません（TODO：これまでのところ？）

参照プロジェクトのパフォーマンスに関する制限

ビルドのパフォーマンスを大幅に向上させるには、プロジェクト参照を検出したときのTypeScriptの動作を必ず制限する必要があります。

具体的には、次のことが当てはまるはずです。

• 参照されているプロジェクトの入力.tsファイルを読み取ったり解析したりしないでください
• 参照されているプロジェクトのtsconfig.jsonのみをディスクから読み取る必要があります
• 最新のチェックでは、上記の制約に違反する必要はありませ

これらの約束を守るために、私たちはあなたが参照するプロジェクトにいくつかの制限を課す必要があります。

• declarationは自動的にtrue設定されます。 この設定を上書きしようとするとエラーになります
• rootDirは、入力ファイルのセットから推測されるのではなく、デフォルトで"." （ tsconfig.jsonファイルを含むディレクトリ）になります。
• files配列を指定する場合は、すべての入力ファイルの名前を指定する必要があります
  
  
  
  • 例外：型参照の一部として含まれるファイル（例： node_modules/@types内のファイル）は指定する必要はありません
  
  
• 参照されるプロジェクトには、それ自体がreferences配列（空の場合もあります）が必要です。

なぜ"declaration": true ？

プロジェクト参照は、実装ファイル（.ts）の代わりに宣言ファイル（.d.ts）を使用することにより、ビルド速度を向上させます。
したがって、当然、参照されるプロジェクトではdeclaration設定がオンになっている必要があります。
これは"project": trueによって暗示されます

なぜrootDirですか？

rootDirは、入力ファイルを出力ファイル名にマップする方法を制御します。 TypeScriptのデフォルトの動作は、入力ファイルの完全グラフの共通ソースディレクトリを計算することです。 たとえば、入力ファイルのセット["src/a.ts", "src/b.ts"]は、出力ファイル["a.js", "b.js"]を生成します。
ただし、入力ファイルのセット["src/a.ts", "b.ts"]は、出力ファイル["src/a.js", "b.js"]を生成します。

入力ファイルのセットを計算するには、すべてのルートファイルとそのすべての参照を再帰的に解析する必要があります。
これは大規模なプロジェクトでは高額です。 しかし、今日、既存のプロジェクトを悪い方法で壊さずにこの動作を変更することはできないため、この変更はreferences配列が提供されている場合にのみ発生します。

循環性なし

当然、プロジェクトは循環性のあるグラフを形成しない場合があります。 （TODO：ビルドオーケストレーションの悪夢以外に、これが実際に引き起こす問題は何ですか？）これが発生した場合、形成された循環パスを示すエラーメッセージが表示されます。

TS6187: Project references may not form a circular graph. Cycle detected:
    C:/github/project-references-demo/core/tsconfig.json ->
    C:/github/project-references-demo/zoo/tsconfig.json ->
    C:/github/project-references-demo/animals/tsconfig.json ->
    C:/github/project-references-demo/core/tsconfig.json

tsbuild

この提案は、「実際の」ビルドシステムでどのように使用されるかについて意図的にあいまいです。 .tsコードのコンパイルにtsc以外のものを導入せずに、50,000LOCの「高速」境界を超えて拡張するプロジェクトはほとんどありません。

「 barがまだ構築されていないため、 foo構築できない」というユーザーシナリオは、コンピューターが処理する必要がある明らかな「フェッチする」種類のタスクです。開発者の精神的負担よりも。

gulp 、 webpackなどのツール（またはそれぞれのTSプラグイン）は、プロジェクト参照を理解してビルドし、最新のチェックを含め、これらのビルドの依存関係を正しく処理することを期待しています。

これが可能であることを確認するために、次の動作を示すTypeScriptビルドオーケストレーションツールのリファレンス実装を提供し

• 高速な最新チェック
• プロジェクトグラフの順序
• 並列化を構築する
• （TODO：その他？）

このツールはパブリックAPIのみを使用する必要があり、ビルドツールの作成者がプロジェクト参照を実装する正しい方法を理解するのに役立つように十分に文書化されている必要があります。

TODO

この提案を完全に完了するために記入するセクション

• 既存のプロジェクトをどのように移行するか
  
  
  
  • 基本的には、 tsconfig.jsonファイルをドロップしてから、ビルドエラーを修正するために必要な参照を追加するだけです。
  
  
• baseUrlへの影響
  
  
  
  • 実装を困難にしますが、エンドユーザーへの影響は事実上ありません
  
  
• ネスティングプロジェクトの簡単な説明（TL; DR許可する必要があります）
• 「大きすぎる」プロジェクトを、消費者を壊すことなく小さなプロジェクトに細分化するシナリオの概要
• レルナのシナリオを理解する
  
  
  
  • 利用可能なデータポイント（N = 1）は、ビルドがすでにこのように効果的に構造化されているため、これは必要ないと述べています
  
  
  • 人々がこれをどのように行うかをよりよく理解するために、より多くの例または反例を見つけてください
  
  
• Webpack / Babel / Rollupなどを介してJSを配管している人には、 dtsEmitOnly設定が必要ですか？
  
  
  
  • 多分references + noEmitこれを意味します
  
  

素晴らしい！

レルナのシナリオを理解する

• 利用可能なデータポイント（N = 1）は、ビルドがすでにこのように効果的に構造化されているため、これは必要ないと述べています

「これ」は、提案またはリファレンスビルドの実装を指しますか？ lernaを使用してビルドを実行することもできますが（私のチームは実行します）、TS（またはこの提案からビルドされたツール）がそれ自体を処理する場合、それは厄介ではるかに効率的です。

TODOセクションは、提案全体のTODOです。

良い！

参照されるプロジェクトには、それ自体が参照配列（空の場合もあります）が必要です。

これは本当に必要ですか？ そのようなパッケージに.d.tsファイルがあれば十分ではないでしょうか？
（その場合、 tsconfig.jsonも必要ないかもしれませんか？）

私のユースケース： outDir使用しない（サードパーティなどの）プロジェクトを考えてみましょう。したがって、 .ts 、 .js 、 .d.tsが隣になります。 TSは現在、 .d.tsを使用する代わりに、 .tsをコンパイルしようとします。

outDirを使用しない理由は、 import "package/subthing"スタイルのインポートをより簡単に許可するためです。そうでない場合は、 import "package/dist/subthing"とoutDir: "dist"ます。
また、NPMパッケージまたはそのソースリポジトリを直接使用できるようにします（たとえば、 npm link ）。

（ package.jsonがmain内のディレクトリの指定を許可していると便利ですが、残念ながら...）

Webpack / Babel / Rollupなどを介してJSをパイプしている人には、dtsEmitOnly設定が必要ですか？

絶対！ これは現時点で大きな欠けている部分です。 現在、 outFileを使用すると単一のd.tsファイルを取得できますが、モジュールに切り替えてバンドラーを使用すると、これが失われます。 モジュールのエントリポイント（ export as namespace MyLib ）に対して単一のd.tsファイルを発行できることは素晴らしいことです。 私は外部ツールがこれを行うことができることを知っていますが、それがエミッターと言語サービスに統合されれば本当に素晴らしいでしょう。

これは本当に必要ですか？ そのようなパッケージに.d.tsファイルが含まれていれば十分ではないでしょうか。

ターゲットtsconfigに、出力ファイルがどこにあるかを示す何かが必要です。 この提案の以前のバージョンには、「明示的なrootDir指定する必要があります」というかなり面倒なものがありました（すべてのtsconfigに"rootDir": "."を記述する必要がありました）。 この世界のさまざまな動作を反転させたいので、参照配列があり、それがキーオフされるものである場合、「プロジェクト」動作を取得すると言う方が理にかなっています。明示的に述べる必要のあるフラグ。

この提案は、TypeScriptプロジェクトをすでに構築した方法と密接に一致します。 それぞれがtsconfig.jsonを持ち、gulpを介して独立して構築される小さなユニットに細分化しました。 プロジェクトは、d.tsファイルを参照することによって相互に参照します。

理想的な世界では、参照されるプロジェクトを事前に構築する必要はありません。 NS。 TypeScriptは、参照されたプロジェクトの「ビルド」を実行し、言語サービスのメモリに同等の「d.ts」を維持します。 これにより、「ソース」プロジェクトで行われた変更が、再構築を必要とせずに「依存」プロジェクトに表示されるようになります。

ターゲットtsconfigに、出力ファイルがどこにあるかを示す何かが必要です。

それはoutDirが使われているときだけ真実ですよね？

のように：私がtsconfigを持っている場合：

• outDir使用しません（もちろん、 declaration: trueはあります）。その場合、 rootDirもreferencesも必要ありません。
• outDirがある場合は、 referencesおよび/またはrootDir （およびdeclaration: true ）を設定する必要があります

質問する理由は、TSパッケージを参照するだけで、任意のTSパッケージの「プロジェクトモード」を有効にできるためです。つまり、それは自分で制御できます。

その場合、探している.d.tsファイルが見つかったらすぐに機能するのも良いでしょう（つまり、.tsファイルやtsconfigファイルがなくても文句を言うことはありません）。 これにより、必要に応じてNPMバージョン（.d.tsファイルしかない場合があります）をソースバージョンに「置き換える」別のケースが可能になるためです。

たとえば、NPMパッケージのMyAppとSomeLibについて考えてみます。
SomeLibはtsconfigを持つことができます： declaration: true 。

次のようなリポジトリ：

package.json
tsconfig.json
index.ts
sub.ts

コンパイルすると、これは次のようになります。

package.json
tsconfig.json
index.ts
index.d.ts
index.js
sub.ts
sub.d.ts
sub.js

この構造は、例えば

// somewhere in MyApp
import something from "SomeLib/sub";

公開されたNPMパッケージでは、現在、常に.tsファイルを削除する必要があります。そうしないと、MyAppがSomeLibを使用する場合、すべてのソースがTSによって再コンパイルされます。

したがって、NPMでは、これは次のようになります。

package.json
index.d.ts
index.js
sub.d.ts
sub.js

さて、MyAppのtsconfigにreferences: ["SomeLib"]を入れた場合、NPMバージョンとSomeLibのソースバージョンの両方で「そのまま、tsconfigの欠落などについて文句を言わないということです。適切な場所にsub.d.tsが見つかる限り。

関連するが異なる質問：

SomeLibがreferencesをtsconfigに入れると、将来、.tsファイルを使用してNPMパッケージを公開できるようになることに気付きました。 しかし、依存パッケージがtsconfigにreferences: ["SomeLib"]を明示的に配置しない場合でも、TSは常にこれらを再コンパイルすると思います。

または、MyLibのreferences 、 importだけの場合（つまり、 referencesはない場合）に自動的に「プロジェクト境界」も導入するという意図もありますか？

IIRC、最初のアイデアの1つは、モジュールがたとえばnode_modulesを介して配置されている場合、 .d.tsファイルが.tsファイルよりも優先されるというものnode_modules "）は一般的に問題が多すぎたためです。 明示的な「プロジェクト境界」を持つことでこれが解決される可能性があります（たとえば、 projectRoot: true代わりに、またはそれに加えて、 references ）？

レルナの場合、私はもっと簡単な解決策を望んでいました。

1. 個々のパッケージディレクトリでは、パッケージはモノレポ構造に関して何も知らないはずです。 個々のTSconfig JSONファイルには、すべての参照を含めることはできません。
   
   
   
   • これにより、個々のパッケージを個別のリポジトリに分割し、メインのリポジトリツールでそれらのクローンを作成することができます（例：ProseMirror： https ：
   
   
2. ルートの「ワークスペース」リポジトリ（すべてのコードを含めることができますが、他のリポジトリのクローンを作成することもできます）で、tsconfig.jsonに参照を含めます。
   
   
   
   • これは、ツールが.d.tsファイルにアクセスする代わりに、ソースへの参照を認識して追跡できるようにするために行われます。
   
   

私の全体的な懸念は、個々のプロジェクト構成ファイルへの相対的な降順の"../xx"パスを使用して参照を追加すると、それらはスタンドアロンモジュールとして使用できなくなり、特定のワークスペース構造にある必要があることです。

「ワークスペース」tsconfig.jsonの新しい概念を追加すると、この問題が解決します。 そうすれば、たとえば個々のパッケージを「git clone」する場合、その依存関係を通常の方法（npmまたはyarnを使用するなど）でインストールすると、コンパイルされた依存関係が定義ファイルを取り込むため、個別に作業できるようになります。 ワークスペース全体のクローンを作成し、コマンドを実行してすべてのパッケージを取り込むと、ワークスペース構成ですべてのソースをナビゲートできます。

ワークスペースtsconfig.jsonもYarnのワークスペースpackage.json https：//yarnpkg.com/lang/en/docs/workspaces/と完全に一致することに注意して

ここで概念実証を少し行いました

https://github.com/spion/typescript-workspace-plugin

個々のリポジトリのすべてのtsconfig.jsonファイルにプラグインを追加するだけです

{
  "plugins": [{"name": "typescript-workspace-plugin"}]
}

次に、yarnの「workspaces」エントリと一緒にトップレベルのpackage.jsonで、「workspace-sources」エントリを追加します。

{
  "workspaces": ["packages/*"],
  "workspace-sources": {
    "*": ["packages/*/src"]
  }
}

このフィールドは、tsconfig.jsonの「paths」フィールドとまったく同じように機能しますが、個々のプロジェクトの言語サービスにのみ影響し、パッケージソースを指します。 適切な「定義/タイプに移動」機能などを復元します。

これは、outDirが使用されている場合にのみ当てはまりますね。

正しい。 大規模なプロジェクトを持つほとんどすべての人がoutDirを使用しているという仮説を立てました。 そうでないプロジェクトについて聞いてみたいです

ここで、MyAppのtsconfigに["SomeLib"]という参照を配置すると、NPMバージョンとSomeLibのソースバージョンの両方で「そのまま」機能するのがよいでしょう。

大ファン、私はこのアイデアがとても好きです。 本当に必要かどうかを考える必要があります。

ここでの注意点の1つは、パッケージの作成者は、a）TSが見つけた場所で.tsファイルとtsconfigファイルの両方を一緒に公開するか、b）どちらも公開せ

または、MyLib内の参照は、インポートするだけで（つまり、参照しない場合）、自動的に「プロジェクト境界」も導入するという意図もありますか？

@mhegazyと話をしreferences配列を持つプロジェクトは、プロジェクトフォルダーの外にある.tsファイルを「見る」ことはありません。これにはファイルが含まれます。 exclude dディレクトリの下。 この変更だけで、lernaシナリオがすぐに機能するようになります（「work」は「モジュール参照が常に.d.tsに解決される」ことを意味します）。

「ワークスペース」モデルをもっと見る必要があります。

これは、outDirが使用されている場合にのみ当てはまりますね。

正しい。 大規模なプロジェクトを持つほとんどすべての人がoutDirを使用しているという仮説を立てました。 そうでないプロジェクトについて聞いてみたいです

Visual Studioソリューションには67のTSプロジェクトがあり、 outdirなしでコンパイルされ、出力ディレクトリ構造を作成するためのビルド後のgrunttasks（およびuglifyやその他の後処理）があります。

ほとんどのプロジェクトにはそのようなtsconfig.jsonがあります

 "include": [
    "../baseProj/Lib/jquery.d.ts",
    "../baseProj/baseProj.d.ts"
  ]

参照の提案を読み通し、修正するのに少し時間がかかりました-AFAICT lernaおよびyarnワークスペースのユーザーは、ここで提案されているワークスペース機能を必要としません。

1. package.jsonに基づく依存関係グラフがすでにあるので、ビルドを実行する順序がわかります。 実際、lernaには、これを順番に実行できる汎用の実行コマンドがあり、必要に応じて並列処理も追加するツールを作成することは難しくありません。 skipLibCheckはパフォーマンスへの影響を無視できるはずですが、私はそれをチェックしていません。
2. LernaとYarnは、適切なnode_modulesの場所に他のモジュールへのシンボリックリンクをすでに作成しています。 その結果、すべての扶養家族は他のモジュールのpackage.jsonをたどり、types / typesフィールドを読み取り、参照されているmodule.d.ts型定義ファイルを見つけることができます。

私たちが持っていないもの、そして私が書いたプラグインが提供するものは、すべてのソースを同時にロードする方法です。 2つ以上のモジュールに同時に変更を加える必要がある場合、「定義に移動」と「タイプ定義に移動」で.d.tsファイルに送信されたくありません。 元のソースコードの場所に送ってほしいので、おそらく編集するかもしれません。 それ以外の場合は、個々のプロジェクトディレクトリをロードするだけで、lerna / yarnによって作成されたnode_modulesシンボリックリンクが機能します。

私たちにとっても同じことです。 Lernaの代わりに、 Rushを使用して依存関係グラフを計算しますが、効果は同じです。 プロジェクトをビルドする場合、 tscは実行する必要のある多くのタスクの1つにすぎません。 私たちのコンパイラオプションは、より大きなビルドシステムによって計算され、 tsconfig.jsonが入力ファイルではなく、生成された出力（主にVS Codeの利益のため）であるモデルに

私たちが持っていないもの、そして私が書いたプラグインが提供するものは、すべてのソースを同時にロードする方法です。 2つ以上のモジュールに同時に変更を加える必要がある場合、「定義に移動」と「タイプ定義に移動」で.d.tsファイルに送信されたくありません。 元のソースコードの場所に送ってほしいので、おそらく編集するかもしれません。

+1これは素晴らしいでしょう。

より良いマルチプロジェクトサポートを夢見ている場合、私の最初のリクエストは、VS CodeIntelliSenseの動作のようなコンパイラサービスです。 Rushがコンパイラエンジンを100回起動することなく、 tsc 100回呼び出すことができれば、ビルドは大幅に高速になります。 コンパイラは、最もコストのかかるビルド手順の1つです。 モノレポでは、ビルド時間が非常に重要です。

@iclanton @ nickpape-msft @ qz2017

はい、お願いします！

プロジェクトシステムの最も有用な成果の1つは、
「定義に移動」は、d.tsファイルではなくソースファイルに移動し、
「すべての参照を検索」は、プロジェクト参照ツリーを検索します。

おそらく、これは「グローバル名前変更」タイプのリファクタリングのロックも解除します。

木曜、午前9時30分PMサルヴァトーレPrevitiで2017年11月9日には[email protected]
書きました：

はい、お願いします！

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/3469#issuecomment-343356868 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANX6d19Zz7TCd_GsP7Kzb-9XJAisG6Hks5s07VXgaJpZM4E-oPT
。

@mhegazyと話をし

いいですね。その場合、なぜ特定の参照を指定する必要があるのでしょうか。
フラグ（ projectRoot: true ）があれば十分なようです。
たとえば、 references: ["foo"]とreferences: []の違いは何でしょうか。
import "foo"またはimport "bar"場合、どちらも.tsファイルを無視するためです。

したがって、その場合、提案は次のようになります。

このtsconfig.json（ projectRoot TODOバイクシェッド）を考えると：

{
  "extends": "../tsproject.json",
  "compilerOptions": {
    "projectRoot": true
   }
}

tscがプロジェクトフォルダ外の何か（除外されたディレクトリの下のファイルを含む）を解決する必要がある場合、 .d.tsファイルのみを調べます（または、 .d.ts優先する場合もあります）。ファイルを作成し、それだけが表示される場合はtsconfigおよび/または.tsフォールバックします）。

これにより、コンパイル中の解決が迅速かつ簡単になります。
これは、モノレポ参照（つまり、 import "../foo" ）およびパッケージベースの参照（つまり、 import "foo" ）に対して機能します。
NPMパッケージとそのソースコード表現で機能します。
また、コンパイル中にtsconfig.json機構を解決する必要がなくなりますが、 .d.tsが見つからない場合のエラーメッセージはあまり役に立ちません。

それが本当にこれほど単純であるならば、それは真実には少し良すぎるように聞こえるので、私はおそらく重要な何かを見落としています:)

他の人も指摘しているように、「IntelliSense」が.tsファイルを引き続き処理することは依然として非常に重要です。

したがって、「定義に移動」、「参照の検索」などの要求が行われた場合、逆マッピングを使用して、使用した.d.tsファイルから対応する.tsファイルを見つける必要があります。遠い。

このマッピングは、次の例を使用して実行できます。

• .d.ts //# sourceURL = ../src/foo.tsような埋め込みコメント文字列を使用する
  
  
  
  • より複雑なソースマップを使用して、「ロールアップされた」 .d.tsから元の.tsにマップすることができます。
  
  
• .jsファイルを解決し、そのソースマップを使用して `.ts

これは、 .tsが変更されたときに.d.tsを再構築するというトピックを紹介しますが、この提案で解決する必要があるかどうかはわかりません。 たとえば、ルートプロジェクト自体からでも、 .jsファイルを再構築するためのプロセスが必要になるのは今日すでに事実です。 したがって、それが存在する場合は、依存関係を再構築するための何かもあると想定するのが安全だと思います。 パッケージごとに並列のtscの束である可能性があり、 tsbuildである可能性があり、 compileOnSaveような動作をするスマートIDEである可能性があります。

@pgonzal @michaelaird https://github.com/spion/typescript-workspace-pluginは、それは定義に行くとマルチTSconfigの糸/レルナの/ etcワークスペースプロジェクトのすべての参照を見つける復元する-ことだけを行います。

面白い...ラッシュでこれを機能させることができるかどうか疑問に思います。 見てみましょう。

参考までに、この取り組みの一環として構築したもう1つの簡単なツールは、 wsrun

lerna runと同様に、ワークスペース内のすべてのパッケージに対してコマンドを実行します。

typescriptの依存関係は順番にコンパイルする必要があるため、wsrunは、 package.json依存関係に基づいてトポロジカルな順序でpackageコマンドを実行できます。 ビルド中の並列処理をサポートします。 最適に並列化されているわけではありませんが、後で改善することができます。

注意点として、 oaoは糸用のもう1つのモノレポツールです。 最近、コマンドの「トポロジカル」順序のサポートも追加されました。

「リファクタリング」という言葉は私たちにとって重要な目標であるため、ここに投稿したいと思いますが、おそらく現在の提案（https://github.com/Microsoft/TypeScript/issues/3469#issuecomment-341317069）と接線方向です。この号ではあまり言及されていません。

私たちのユースケースは、いくつかのTSプロジェクトを含むモノレポであり、基本的にcommon-library加えて、 app1とapp2つのアプリに減らすことができます。 IDEで作業する場合、これらは単一のプロジェクトとして扱う必要があります。たとえば、名前変更リファクタリングは3つのモジュールすべてで機能する必要がありますが、 app1とapp2も2つの別個のビルドターゲットです。 ビルドは一般的に関心の分離であることに同意しますが、真実は、私たちのアプリは非常に小さく、 cd app1 && tscようなことをすることは私たちにとって完全に問題ないということです。

TypeScriptがこれをサポートする良い方法を考え出すなら、それは素晴らしいでしょう。

monorepoクロスプロジェクトリファクタリング/リファレンスの場合、vscodeで作業している場合は、このセットアップが機能していることがわかりました。

ルートtsconfig：

"compilerOptions": {
   "baseUrl": ".",
   // global types are different per project
   "types": [],
   "paths": {
      "lib": ["packages/lib/src"],
      "xyz1": ["packages/xyz1/src"],
      "xyz2": ["packages/xyz2/src"],
   }
},
"include": ["./stub.ts"], // empty file with export {} to stop vscode complaining about no input files
"exclude": ["node_modules"]

packages / xyz1 / tsconfig.json

{
  "extends": "../../tsconfig",
   "compilerOptions": {
      "types": ["node"],
   },
   "include": ["src/**/*"]
}

packages / xyz2 / tsconfig.json

{
  "extends": "../../tsconfig",
   "compilerOptions": {
      "types": ["webpack-env"]
   },
  "include": ["src/**/*"]
} 

packages / lib / tsconfig.json

{
   "extends": "../../tsconfig",
    "compilerOptions": { ... },
    "include": ["src/**/*"],
    // special file to load referenced projects when inside in lib package, without it they won't be 
    // visible until you open some file in these projects 
    "files": ["./references.ts"],
}

packages / lib / tsconfig-build.json

{
   "extends": "./tsconfig",
    // exclude referenced projects when building
   "files": []
}

packages / lib / references.ts

import "xyz1";
import "xyz2";

export {};

パッケージのpackage.json正しいmainプロパティが必要であり、libなしのパッケージの場合でもtypesなる可能性があります。次に例を示します。

  "main": "src/main.tsx",
  "types": "src/main.tsx",

このように、 lib何かをリファクタリング/名前変更すると、 xyz1とxyz2参照もリファクタリングされます。 また、この方法では、プロジェクトに異なるグローバル/ターゲットライブラリを含めることができます。

Gradleでは、単にそれを複合ビルドと呼んでいます。

ちなみに、TypeScriptコンパイラに貢献したいのなら、私が始めるべき1つのポイントはありますか？ 私はリポジトリのクローンを作成しましたが、それは少なからぬことではありません（私はソースを読むために使用します：角度、イオン、ドキュメントから取得できない場合、またはインターネットから離れている場合はエクスプレス...）本当に助けが必要です行く道を教えてください。

ありがとう！
TypeScriptの明るい未来。

相対的なモジュールパスを使用している場合は、試してもらいたいプロトタイプがあります。 https://github.com/RyanCavanaugh/project-references-demoにサンプルリポジトリがあり、基本的なシナリオの概要とその仕組みを示しています。

ローカルで試す場合：

git clone https://github.com/RyanCavanaugh/TypeScript
git checkout pr-lkg
npm install
npm run build
npm link

次に、他のフォルダに：

npm link typescript

状況の変化に応じて、 pr-lkgタグが最新の作業コミットを指すようにします。 次は私のやることです：

• [x]依存プロジェクトがビルドされていない場合のエラーメッセージを改善する
• []リダイレクト動作を非相対モジュールパスに適用します
• []ビルドツールが使用するAPIを公開する

@RyanCavanaugh delモジュールやError: Cannot find module 'C:\github\TypeScript\built\local\tsc.js' （おそらくローカルパス？）がないなどのエラーのために実際にビルドすることはできませんが、全体的に構造は見栄えがします。

これはtscのみですか、それとも言語サーバーを使用したVSCodeでのプロジェクト全体のリファクタリングも考慮しますか？

...また、 pr-lkgタグがありません。

タグはそこにあります（ブランチではありません）。 https://github.com/RyanCavanaugh/TypeScript/tree/pr-lkgを参照して

referencesでtsconfig.json 、それはそれはすべてのものに適用するためのより多くの意味がありませんごとの依存関係オプトインであること外の解決さrootDir ？

次のようなsandboxプロパティのようなものを想像しています。

# tsconfig.json
{
  "compilerOptions": {
    "outDir": "lib",
    "sandbox": "."
  },
  "include": ["src/index.ts"]
}

サンドボックスもrootDirを同じ値に設定します。 tsconfig.jsonを含むディレクトリへのパスを明示的に提供する代わりに、通常のモジュール解決が適用され、FSツリーを検索してtsconfig.json自動的に見つけることができます。

# package.json
{
  "name": "animals",
  "module": "src",
  "typings": "lib",
  "dependencies": {
    "core": "*"
  }
}

こちらです：

• 2つの同期リスト（ referencesとdependencies ）を維持する必要はありません。
• パッケージは、それ自体の外部のファイルシステムに関する知識を持っていません。
• カスタムパスの代わりにノードモジュール解決戦略を使用します。

@RyanCavanaugh 、私が理解している限り、私はこれらの変更をローカルでしか作業できず、たとえばtravis-ci.orgでテストのためにそのようなプロジェクトを送信することはできません。 右？

@billti / @ mhegazyとの今日の会議からのメモ

• 少なくともプロジェクトの終了を決定するために必要なコンパイルコンテキストがメモリに収まるシナリオでは、参照の検索/名前の変更が機能する必要があります
• ソリューション全体の名前変更は、「ソリューション」ファイルを見つけるために歩き、参照プロジェクトを見つけるために逆方向に作業し、次に、シンボルが表示されているグラフのセクションを実装ロードします。 これは、真の発信宣言を見つけるための反復プロセスである可能性があります
• tsbuildは-wモードを処理する必要があります
• ソリューションには、ソリューションフォルダーの外部で発生したサブプロジェクトがない場合があります
• gulp、webpackなどの明確なドキュメントが必要

サイドバー：この名前変更は今日は機能しません

function f() {
  if (Math.random() > 0.5) {
    return { foo: 10 };
  } else {
    return { foo: 20 };
}
// rename foo here doesn't rename *both* instances in the function body
f().foo;

ライアン、モハメド、ビルに感謝します。 プロジェクト間で「参照の検索/名前の変更」シナリオを機能させることは、TypeScriptが中規模プロジェクトをサポートしていないことについて最初の苦情を述べたときに私が念頭に置いていた主要なユースケースの1つでした。 中規模のプロジェクトはモジュール式ですが、大規模ではありません。 私がこれまでにここで見た提案と作業は、スケーラビリティの遊びのように感じます。 これはTypeScriptの長期的な健全性にとって非常に重要ですが、中規模ではなく大規模なプロジェクトにとってはほとんどメリットがあります。 このコメントでライアンから聞いたことは、TypeScriptで中規模プロジェクトを開発する際の人間工学を改善するために必要なものに沿ったものに聞こえます。

いつものように、TypeScriptチーム全体の努力に感謝します！ あなたは素晴らしい仕事をしています。

lerna / yarnワークスペースには、あなたの生活をはるかに楽にするトリックがあります。
サブプロジェクトのpackage.jsonのmainおよびtypesエントリをsrc / indexにポイントします。 tsファイル、および参照の検索/名前の変更シナリオは単純に機能します。
また、1つのtscを実行するだけで、プロジェクト全体をコンパイルできます。
あなたはあなたのパッケージのいくつかのためにそれをするかもしれません、あなたはすべてのためにそうするかもしれません。 あなたの呼び出し。

いくつかの欠点と落とし穴があります（1つのパッケージに拡張がある場合、またはグローバルシンボルをインポートすると、プログラム全体が汚染されます）が、一般的には非常にうまく機能します。
NPMに公開する場合は、メインとタイプを適切な値に設定するだけです（ビルドの一部としてなど）。

上記の設定で、私は多かれ少なかれ期待される機能のすべてを手に入れました

これがlerna / yarnワークスペースの秘訣です。これによりあなたの生活がずっと楽になります。
サブプロジェクトのpackage.jsonのメインエントリとtypesエントリをsrc / index.tsファイルにポイントすると、参照の検索/名前の変更シナリオが簡単に機能します。

私の経験では、そのセットアップの問題は、TypeScriptが_external_パッケージのtsファイルを、外部ライブラリとしてではなく、それらを必要とするパッケージの_sources_であるかのように扱い始めることです。 これは多くの問題を引き起こします。

• 外部パッケージは、_requiring_パッケージのtsconfigを使用するたびに、複数回コンパイルされます。 必要なパッケージのtsconfigが異なる場合（たとえば、異なるライブラリ）、これにより、再度コンパイルされるまで、必要なパッケージに誤ったコンパイルエラーが表示される場合があります。

• 必要なパッケージには、必要以上のファイルが含まれているため、コンパイルも遅くなります。

• すべてのパッケージのrootDirが最上位ディレクトリになり、 indexからだけでなく、任意のパッケージから任意のTSファイルを直接含めることができる可能性があります。 開発者が注意しないと、必要なパッケージAPIをバイパスする可能性があります。 また、ビルドプロセスが堅牢でない場合、必要なパッケージには、外部向けの必要なパッケージからの重複コードが含まれる可能性があります。

私たちのプロジェクトでは、欠点のためにTSファイルに依存することを除外しました。 パッケージ間の依存関係はすべてindex.d.tsファイルにあるため、コンパイラーはそれらを外部として扱い、すべて問題ありません。

もちろん、 .d.tsによっては、マルチステップビルドが必要になるという問題（webpackなどのツールではすぐに使用できない）とIDEエクスペリエンスの低下（名前の変更、参照がパッケージの境界を越えない）の問題があります。 ）。

私は他の感情のいくつかに同意します-typescriptはコンパイラであり、ビルドシステムではありません。 より優れたマルチプロジェクトビルドをサポートするためのツールが必要です。 私はこれを始めているコミュニティにいくつかのオプションがあることを知っています。 例として、C＃にはRoslynという名前のコンパイラとMSBuildという名前のビルドツールがあります。

今日、 @ mhegazyと、

名前の変更の非縮退の最悪のケースは次のようになります。

// alpha.ts
const v = { a: 1 };
export function f() { return v; }
export function g() { return v; }

// alpha.d.ts (generated)
export function f(): { a: number };
export function g(): { a: number };

// beta.ts (in another project)
import { f } from '../etc/alpha';
f().a;

// gamma.ts (in yet another project)
import { g } from '../etc/alpha';
g().a;

重要な観察は、 alpha.tsが2つを相互に関連付けることができない限り、 f().a名前を変更するとg().a名前が変更されることを知ることは不可能であるということです。

実装計画の大まかなスケッチ：

• .d.tsファイルの「リッチ」および「リーン」なメモリ内SourceFile表現を用意します。 「リーン」ファイルはディスクから読み取られます。 「リッチ」なものは、メモリ内の.d.ts生成の結果として生成されます
• 「リッチ」.d.tsSourceFilesには、識別子ノードから元のソースファイルの元の名前への参照があります
• 名前の変更中、通常どおり、最初に問題のシンボルを定義します。 これがプロジェクト参照の.d.tsに由来する場合は、実装ロードして「リッチ」な.d.tsファイルを作成します。
  
  
  
  • 注：このプロセスは反復的です。つまり、実際の実装ファイル（プロジェクト参照のために.d.tsリダイレクトではないもの）に到達するまで、いくつかのレベルをトレースバックする必要がある場合があります。
  
  
• 次に、「リッチ」ポインタを使用して、プロジェクトの.d.ts内の他のどの識別子が同じソースファイル識別子に由来するかを把握します。
• 各ダウンストリームプロジェクトで、名前が変更された識別子をテキストスキャンし、その「go-to-def」結果が.d.ts内の「同じシンボルから開始された」場所のいずれかであるかどうかを確認します。
• 実装ファイルで名前の変更を実行します

@RyanCavanaughは定義に移動します/すべての参照がこのモデルで

多数の未解決の質問に関するアンダースとモハメドとの以前の議論からのメモ

• prependまたに適用されます.d.ts ？ はい
• ドッグフードブランチの@internalで何をしますか？ 内部宣言をローカルの.d.tsファイルに保持する必要がありますが、出力バージョンに表示されないようにする必要があります。
  
  
  
  • --stripInternal削除します
  
  
  • しかし、それを非難しないでください（まだ...？）
  
  
  • ライアンがremove-internalツールを作成する（完了）
  
  
  • 構築-> LKGプロセスは@internal宣言を削除します
  
  
• .d.tsファイルを@typesから変更するとどうなりますか？
  
  
  
  • 新しいエラーの可能性を確認したい場合は、手動で再構築を強制する必要があります☹️
  
  
  • これが本当に問題になる場合は、最終的に「filesIlooked.txt」ファイルを出力フォルダーに書き込むことができます。
  
  
• noEmitOnError必須ですか？ はい。
  
  
  
  • そうしないと、再構築によってエラーが非表示になります。
  
  
• referenceTarget -> composable ✨🚲🏡✨
• 宣言を発行したくないが、高速な再構築が必要なリーフノードプロジェクトはどうですか？
  
  
  
  • tsbuildまたは同等のものは、 composableアップストリームに関係のない要件への準拠を確認できます。
  
  
• 循環参照、（どのように）それらは機能しますか？
  
  
  
  • デフォルトでは、
  
  
  • これを行う場合は、たとえば{ path: "../blah", circular: true }を指定できます
  
  
  • そうした場合、ビルドが決定論的であり、常に固定点に到達することを確認するのはあなた次第です（おそらくそうではないかもしれませんか？！）
  
  
  • Circular：trueインポートの再マッピングは、オプションの（ただし優先順位が付けられた）再マップです。
  
  

その他

• @weswighamには、 ます

私はすでに負けました。 私は主にソースマップの解釈をコンパイラーから遠ざけたいと思っていました（別々のツールに対する別々の責任）が、あなたが留守の間、とにかくそれを追加することに取り組みました（明らかにシームレスなgo-todefが望ましいため）。

@RyanCavanaugh
＃23944をマージした後、参照されているプロジェクト全体ですべての参照の名前を変更/検索する必要がありますか？ また、言語サービス（tsbuildではない）のみが必要な場合に備えて、 composite: trueとprojectReferences: []を使用する必要がありますか？

＃23944をマージした後、参照されているプロジェクト全体ですべての参照の名前を変更/検索する必要がありますか？

まだ。 しかし、私たちは次にこれに取り組んでいます。

また、言語サービス（tsbuildではない）のみが必要な場合は、composite：trueおよびprojectReferences：[]を使用する必要がありますか？

質問がわかりません。「ビルド」ではなく「言語サービス」とはどういう意味ですか？

質問がわかりません。「ビルド」ではなく「言語サービス」とはどういう意味ですか？

私は使用しているので、新しいビルドツール（別名build mode ）（＃22997）ではなく、monorepoの複数のプロジェクトにわたるエディターサポート（名前の変更/すべての参照の検索など）にのみ興味があります私の編集のためのバベル。

それはうまくいくはずです。 ビルドはオプトイン機能であり、使用したくない場合は使用する必要はありません。たとえば、VSCodeでの言語サービスエクスペリエンスにtscが必要ないのと同様です。

ただし、クロスプロジェクト参照が機能するために必要なメタデータを生成するには、宣言と宣言マップを使用してビルドする必要があります。

提案のすべての側面を正しく理解しているかどうかはわかりませんが、個々のプロジェクトにパスではなく名前で他のプロジェクトを参照させることは可能でしょうか？ ワークスペースプロジェクトには、グロブを介したヤーンワークスペースと同様に、または個々のプロジェクト名をすべてリストすることによって、すべてのプロジェクトパスを指定する方法が必要です。

基本的に、代わりに：

"dependencies": [
    "../common", 
    "../util"
],

お願いできますか

"dependencies": [
    "common", 
    "util"
],

ワークスペースtsconfig.jsonがあります

"workspace": {
  "common": "packages/common",
  "util": "packages/util"
}

またはさらに良いことに、パス構文：

"workspace": {
  "*":"packages/*"
}

利点：

• モジュールシステムに応じて異なるルックアップルールを指定する機能
• パッケージがワークスペースの外部にダウンロードされたときにnode_modulesにフォールバックする機能
• 複数のリポジトリのクローンを作成し、パスの構成を変えることで、複数のワークスペースを自由に集約して作業できるため、さらに多くのパッケージを並行して作業できます。

または、少なくとも、パス以外の名前（「./」または「../」で始まらない名前）を将来の使用のために予約することはできますか？

これがどの程度関連しているかはわかりませんが、Yarn 1.7では最近「フォーカスされたワークスペース」の概念が導入されました。このブログ投稿を参照してください。

ここにいる誰かが、ワークスペースと@RyanCavanaughがTypeScriptプロジェクト参照/ビルドモードの周りで行っている作業の両方に精通していて、それらが関連しているかどうかを説明するコメントをドロップする可能性がありますか？ 私の直感は、Yarnワークスペース（npmは今年もそれらを取得します）と将来のTypeScriptバージョンの間の_どこか_が、複数のプロジェクトと共有ライブラリを持つモノリポジトリの優れたサポートにあるということです。 （現在、痛みを感じています。）

この機能の進捗状況に関する最新情報を入手したいです。 来月かそこらでAureliavNextをモノレポに移行する予定です。 新しいバージョンは100％TypeScriptであり、可能であれば、Lernaではなく公式のTSプロジェクトシステムを使用したいと考えています。 また、新機能の早期採用者/テスターに​​なることも嬉しく思います:)

コアサポートとソースマップサポートgotodefは、前回のリリース（TS 2.9）で追加されました。 ビルドサポート用のtsc --bはすでに存在し、TS3.0にバインドされています。 typescriptコードベースはそれを使用するように移動しました。 現在、typescriptリポジトリを使用してこのサポートをテストしています。

この時点でまだ実行する必要があること：1。複数のプロジェクトシナリオで機能するように、すべての参照を検索/名前を変更します。 2.エディターのバックグラウンドでの.d.tsファイルの更新に対処します。3。マルチプロジェクトシナリオの--watchサポート。 また、たくさんのテストがあります。

このチケットは彼の本に3年間掲載されています。 まだ3/6の傑出したアイテム？

@claudeduguayこれは、TypeScriptがサポートするプロジェクトの根本的な変更です。祝う時間だと思いませんか？ とても嬉しいです！

@mhegazyこれは素晴らしいニュースです。 TSチームが自分たちのプロジェクトでもドッグフーディングをしていると聞いてとてもうれしく思います。 最後のいくつかの作業が完了し、これをAureliaのオプションとして使用できることを楽しみにしています:)セットアップに関するドキュメントができ次第、vNextを新しいプロジェクトシステムに移動します。 待てない！

@mhegazy ES2015モジュールに基づくpackage.jsonファイルとプロジェクトでこれらすべてがどのように機能するかについて、いくつかの光を@aurelia/kernel 、 @aurelia/runtime 、 @aurelia/jitなどのパッケージがあります。これらはimportで使用されるモジュール名です。さまざまなプロジェクト全体のステートメント。 TSコンパイラは、これらのモジュール名がさまざまな参照フォルダにマップされていることをどのように理解しますか？ 参照されている各フォルダーに配置されているpackage.jsonファイルを取得しますか？ これはLernaまたはYarnワークスペースとどのように異なりますか？ 上記のリンクを最初に調べたところ、実用的なソリューションを得るには、TSプロジェクト（ビルド）をLerna（リンクと公開）と組み合わせて使用​​する必要があると思いましたが、TSがどのように適切にビルドされるのかわかりませんpackage.jsonおよびnode_modulesと統合できない場合。 TSリポジトリのソースは、平均的なLernaプロジェクトとはかなり異なります（実際にはそうではありません）。したがって、これで私たちのニーズを満たすことができるかどうか疑問に思い始めています。 あなたが提供できるそれ以上の情報、そして特に。 ここで説明したものと同様の実用的なデモソリューションのセットアップが非常に役立ちます。 ありがとう！

@EisenbergEffectと同じ質問を共有します。 特に、これがlerna管理されているモノレポでうまく機能することも期待しています。

考慮すべき2つのモノレポシナリオ

すべてをlernaでシンボリック化したセットアップから始めましょう。

/packages
  /a
    /node_modules
      /b -> symlink to b with package.json "types" pointing to dist/index.d.ts
  /b
    /dist
      /index.d.ts -> built output of entry point declaration file

ここで実行したい重要なことは、 aが古くなっている場合に、 aを構築したbを再構築することです。 したがって、 "references": [ { "path": "../b" } ]をaのtsconfig.json追加し、 a tsc --buildを実行して、 b正しいアップストリームビルドを取得します。 package.json依存関係をtsconfig.jsonにミラーリングできます。

別のシナリオ（おそらくあまり一般的ではありません）は、シンボリックリンクを行っていなくても、ライブのパッケージセットで作業しているように「動作する」ことを望んでいる場合です。 今日、これはかなり面倒なパスマッピングで実行できますが、一部の人はそうしています。 ここでのプロジェクト参照も同様にビルドの順序付けに役立ちますが、参照先のtsconfigファイルでプロパティをサポートして、参照されるたびにパスマッピングを自動的に作成することが非常に望ましいでしょう。 例えばあなたが持っていた場合

{
  "compilerOptions": { "outDir": "bin" },
  "package": "@RyanCavanaugh/coolstuff"
}

次に、 "references": [{ "path": "../cool" }]を追加すると、 @RyanCavanaugh/coolstuff -> ../cool/bin/からのパスマッピングが自動的に追加されます。 これはまだ追加していませんが、より一般的なシナリオであることが判明した場合は調査できます。

理想的には、lernaとTSはここで協力し、必要に応じてpackage.jsonの依存関係をtsconfig.jsonにミラーリングできます。

composite: trueが設定されている場合は、外部ツールに依存するのではなく、 package.json （tsconfigと一緒にある場合）を潜在的な参照として読み取ることを選択できます（解決された各パッケージにtsconfig.jsonがあるかどうかを確認してください） tsファイルをロードし（宣言よりもファイルを優先するため）、古くなっているかどうかに関係なくすべてを再コンパイルするという、今日の作業に対する最適化になります。

@RyanCavanaughこれはかなりエキサイティングに聞こえます。 それがラッシュのシンボリック戦略で機能するかどうか、何か考えはありますか？ 一言で言えば、Rushは、リポジトリ内のすべてのパッケージのすべての依存関係のスーパーセットを含む合成パッケージcommon / temp /package.jsonを作成します。 次に、 pnpmを使用して、この合成パッケージの単一のインストール操作を実行します。 （PNPMは、シンボリックリンクを使用して、NPMのツリー構造の代わりに有向非巡回グラフを作成します。これにより、重複するライブラリインスタンスが排除されます）。 次に、Rushは、リポジトリ内のプロジェクトごとにcommon / tempの下の適切なフォルダーを指すシンボリックリンクで構成されています。 結果は、TypeScriptおよび標準のNodeJS解決アルゴリズムと完全に互換性があります。 リポジトリ全体に対して1つのシュリンクラップファイルと1つのバージョン管理式があり、各パッケージが独自の依存関係を指定できるため、非常に高速です。

このモデルのtsconfig.jsonは特別なものは何も入れていません。 goto-definition機能に特別なTypeScript構成が必要な場合は、Gitに保存するのではなく、インストール中に自動生成するのが理想的です。

@pgonzal Rushへのリンクをありがとう！ 私はまだそれを見ていませんでした。 今夜チェックします。

@RyanCavanaugh説明ありがとうございます。 lernaを使用した最初のシナリオは、私たちが持っているシナリオに最も近いものです。 https://github.com/aurelia/uxで新しいプロジェクトサポートを使用したい例として、TSとlernaを使用したUXリポジトリを次に示し

@weswighamあなたが説明していることは、私たちのシナリオにも当てはまるように

ヤーンワークスペースの場合、モジュールは個々のパッケージのディレクトリでシンボリックリンクされるのではなく、トップレベルのワークスペースnode_modulesシンボリックリンクされることに注意してください。

ちなみに、ドット（ './'または '../'）で始まらない参照は、将来のために予約する必要があると思います。 うまくいけば、それらは「名前付き参照」になり、相対パスとして扱われるのではなく、アクティブなモジュール解決戦略を介して処理されます。

@spion必要に応じて、 path以外のプロパティ名を使用します（例： "references": [ { "module": "@foo/baz" } ] ）; "bar"と"./bar"がfilesでは同じことを意味し、 referencesでは異なることを意味するという混乱を引き起こしたくありません。

以下で進行中のドキュメント/ブログ投稿作業（フィードバックに基づいてこれを編集します）

このスレッドをフォローしている人は、ぜひ試してみることをお勧めします。 私は現在monorepoシナリオに取り組んでおり、そこで最後のバグ/機能を修正しているので、すぐにガイダンスが必要です。

プロジェクトリファレンス

プロジェクト参照はTypeScript3.0の新機能であり、TypeScriptプログラムをより小さな部分に構造化することができます。

これを行うことで、ビルド時間を大幅に改善し、コンポーネント間の論理的な分離を実施し、コードを新しくより良い方法で編成できます。

また、 tsc新しいモードである--buildフラグも導入しています。このモードは、プロジェクト参照と連携して機能し、TypeScriptのビルドを高速化します。

サンプルプロジェクト

かなり普通のプログラムを見て、プロジェクト参照がプログラムの整理にどのように役立つかを見てみましょう。
converterとunits 2つのモジュールと、それぞれに対応するテストファイルを持つプロジェクトがあるとします。

/src/converter.ts
/src/units.ts
/test/converter-tests.ts
/test/units-tests.ts
/tsconfig.json

テストファイルは実装ファイルをインポートし、いくつかのテストを実行します。

// converter-tests.ts
import * as converter from "../converter";

assert.areEqual(converter.celsiusToFahrenheit(0), 32);

以前は、単一のtsconfigファイルを使用した場合、この構造は扱いにくいものでした。

• 実装ファイルがテストファイルをインポートすることは可能でした
• src出力フォルダー名に表示せずに、 testとsrcを同時にビルドすることはできませんでした。
• 実装ファイルの内部のみを変更するには、新しいエラーが発生することはありませんが、テストを再度タイプチェックする必要がありました。
• テストだけを変更するには、何も変更されていなくても、実装を再度タイプチェックする必要がありました

複数のtsconfigファイルを使用してこれらの問題のいくつかを解決することもできますが、新しい問題が発生します。

• 組み込みの最新のチェックがないため、常にtsc 2回実行することになります。
• tsc 2回呼び出すと、起動時間のオーバーヘッドが増加します
• tsc -wは、一度に複数の構成ファイルで実行することはできません

プロジェクト参照は、これらすべての問題やその他の問題を解決できます。

プロジェクトリファレンスとは何ですか？

tsconfig.jsonファイルには、新しい最上位プロパティreferencesます。 これは、参照するプロジェクトを指定するオブジェクトの配列です。

{
    "compilerOptions": {
        // The usual
    },
    "references": [
        { "path": "../src" }
    ]
}

各参照のpathプロパティは、 tsconfig.jsonファイルを含むディレクトリ、または構成ファイル自体（任意の名前を指定できます）を指すことができます。

プロジェクトを参照すると、新しいことが起こります。

• 参照されているプロジェクトからモジュールをインポートすると、代わりにその出力宣言ファイル（ .d.ts ）が読み込まれます。
• 参照されたプロジェクトがoutFile生成する場合、出力ファイル.d.tsファイルの宣言がこのプロジェクトに表示されます。
• ビルドモード（以下を参照）は、必要に応じて参照されたプロジェクトを自動的にビルドします

複数のプロジェクトに分割することで、タイプチェックとコンパイルの速度を大幅に向上させ、エディターを使用する際のメモリ使用量を削減し、プログラムの論理グループ化の実施を向上させることができます。

composite

参照されるプロジェクトでは、新しいcomposite設定を有効にする必要があります。
この設定は、TypeScriptが参照されたプロジェクトの出力を見つける場所をすばやく決定できるようにするために必要です。
compositeフラグを有効にすると、いくつかの変更があります。

• rootDir設定は、明示的に設定されていない場合、デフォルトでtsconfigファイルを含むディレクトリになります。
• すべての実装ファイルは、 includeパターンと一致するか、 files配列にリストされている必要があります。 この制約に違反した場合、 tscはどのファイルが指定されなかったかを通知します
• declarationオンにする必要があります

declarationMaps

宣言ソースマップのサポートも追加しました。
--declarationMapを有効にすると、「定義に移動」や「名前の変更」などのエディター機能を使用して、サポートされているエディターでプロジェクトの境界を越えてコードを透過的にナビゲートおよび編集できます。

prependとoutFile

prependの

   "references": [
       { "path": "../utils", "prepend": true }
   ]

プロジェクトの前に付けると、現在のプロジェクトの出力の上にプロジェクトの出力が含まれます。
これは.jsファイルと.d.tsファイルの両方で機能し、ソースマップファイルも正しく出力されます。

tscは、このプロセスを実行するためにディスク上の既存のファイルのみを使用するため、一部のプロジェクトの出力が結果のファイルに複数回存在するため、正しい出力ファイルを生成できないプロジェクトを作成することができます。 。
例えば：

  ^ ^ 
 /   \
B     C
 ^   ^
  \ /
   D

この状況では、 Dの出力にAコピーが2つ含まれるため、各参照の先頭に付加しないことが重要です。これにより、予期しない結果が生じる可能性があります。

プロジェクト参照に関する警告

プロジェクトの参照には、注意が必要ないくつかのトレードオフがあります。

依存プロジェクトを使用しますので.d.tsそれらの依存関係から構築されているファイルを使用すると、スプリアス見ずにエディタでプロジェクトをナビゲートすることができます前に、あなたはどちらか特定のビルド出力で確認するか、それをクローニングした後、プロジェクトをビルドする必要がありますエラー。
これを軽減できるはずの舞台裏の.d.ts生成プロセスに取り組んでいますが、今のところ、クローン作成後にビルドする必要があることを開発者に通知することをお勧めします。

さらに、既存のビルドワークフローとの互換性を維持するために、 tscは、 --buildスイッチで呼び出されない限り、依存関係を自動的にビルドしません。
--buildについてもっと学びましょう。

TypeScriptのビルドモード

待望の機能は、TypeScriptプロジェクトのスマートインクリメンタルビルドです。
3.0では、 --buildとともにtsc --buildフラグを使用できます。
これは事実上、 tsc新しいエントリポイントであり、単純なコンパイラというよりもビルドオーケストレーターのように動作します。

tsc --build （略してtsc -b ）を実行すると、次のようになります。

• 参照されているすべてのプロジェクトを検索する
• それらが最新であるかどうかを検出します
• 古いプロジェクトを正しい順序でビルドする

tsc -bに複数の構成ファイルパスを指定できます（例： tsc -b src test ）。
tsc -p同様に、 tsconfig.jsonという名前の場合、構成ファイル名自体を指定する必要はありません。

tsc -bコマンドライン

構成ファイルはいくつでも指定できます。

 > tsc -b                                # Build the tsconfig.json in the current directory
 > tsc -b src                            # Build src/tsconfig.json
 > tsc -b foo/release.tsconfig.json bar  # Build foo/release.tsconfig.json and bar/tsconfig.json

コマンドラインで渡すファイルの順序について心配する必要はありません。依存関係が常に最初に構築されるように、 tscは必要に応じてファイルを並べ替えます。

tsc -b固有のフラグもいくつかあります：

• --verbose ：何が起こっているかを説明するために詳細なログを出力します（他のフラグと組み合わせることができます）
• --dry ：何が行われるかを示しますが、実際には何も構築しません
• --clean ：指定されたプロジェクトの出力を削除します（ --dryと組み合わせることができます）
• --force ：すべてのプロジェクトが古くなっているかのように振る舞います
• --watch ：ウォッチモード（ --verbose以外のフラグと組み合わせることはできません）

警告

通常、 tscは、 noEmitOnErrorがオンになっていない限り、構文エラーまたは型エラーが存在する場合に出力（ .jsおよび.d.ts ）を生成します。
インクリメンタルビルドシステムでこれを行うと、非常に悪い結果になります。古い依存関係の1つに新しいエラーが発生した場合、後続のビルドでは最新のプロジェクトのビルドがスキップされるため、エラーは1回しか表示されません。
このため、 tsc -b noEmitOnErrorは、すべてのプロジェクトで

ビルド出力（ .js 、 .d.ts 、 .d.ts.mapなど）をチェックインする場合、特定のソース管理の後に--forceビルドを実行する必要がある場合がありますソース管理ツールがローカルコピーとリモートコピーの間のタイムマップを保持するかどうかに応じた操作。

msbuild

msbuildプロジェクトがある場合は、追加してビルドモードを有効にすることができます

    <TypeScriptBuildMode>true</TypeScriptBuildMode>

あなたのprojファイルに。 これにより、自動インクリメンタルビルドとクリーニングが可能になります。

tsconfig.json / -p同様に、既存のTypeScriptプロジェクトのプロパティは尊重されないことに注意してください。すべての設定はtsconfigファイルを使用して管理する必要があります。

一部のチームは、msbuildベースのワークフローを設定しており、tsconfigファイルは、ペアになっている管理対象プロジェクトと同じ暗黙的なグラフの順序になっています。
ソリューションがこのような場合は、プロジェクト参照とともにmsbuildとtsc -pを引き続き使用できます。 これらは完全に相互運用可能です。

ガイダンス

全体的な構造

tsconfig.jsonファイルが多い場合は、通常、構成ファイルの継承を使用して、一般的なコンパイラオプションを一元化する必要があります。
このようにして、複数のファイルを編集しなくても、1つのファイルの設定を変更できます。

もう1つの良い方法は、すべてのリーフノードプロジェクトに対してreferencesを含む「ソリューション」 tsconfig.jsonファイルを用意することです。
これは単純なエントリポイントを示します。 たとえば、TypeScriptリポジトリでは、すべてのサブプロジェクトをsrc/tsconfig.jsonリストしているため、 tsc -b srcを実行してすべてのエンドポイントを構築します。
3.0以降、 tsconfig.jsonファイルに少なくとも1つのreferenceがある場合、空のfiles配列が存在することはエラーではなくなったことに注意してください。

これらのパターンはTypeScriptリポジトリで確認できます。重要な例としてsrc/tsconfig_base.json 、 src/tsconfig.json 、およびsrc/tsc/tsconfig.jsonを

相対モジュールの構造化

一般に、相対モジュールを使用してリポジトリを移行するのにそれほど多くは必要ありません。
指定された親フォルダーの各サブディレクトリにtsconfig.jsonファイルを配置し、プログラムの目的のレイヤーに一致するようにこれらの構成ファイルにreferenceを追加するだけです。
outDirを出力フォルダーの明示的なサブフォルダーに設定するか、 rootDirをすべてのプロジェクトフォルダーの共通ルートに設定する必要があります。

outFilesの構造化

outFileを使用したコンパイルのレイアウトは、相対パスがそれほど重要ではないため、より柔軟です。
覚えておくべきことの1つは、通常、「最後の」プロジェクトまでprepend使用したくないということです。これにより、ビルド時間が改善され、特定のビルドで必要なI / Oの量が削減されます。
TypeScriptリポジトリ自体はここでの良いリファレンスです-いくつかの「ライブラリ」プロジェクトといくつかの「エンドポイント」プロジェクトがあります。 「エンドポイント」プロジェクトは可能な限り小さく保たれ、必要なライブラリのみを取り込みます。

モノレポの構造化

TODO：もっと実験して、これを理解してください。 ラッシュとレルナは、私たちの側で異なることを意味する異なるモデルを持っているようです

＃25164に関するフィードバックも探しています

@RyanCavanaugh非常に素晴らしい記事と優れた機能は、特に試してみると本当に素晴らしいでしょう。 大きなプロジェクトを構成ファイル参照を使用してサブプロジェクトに編成するのに何日も費やした後。

私はいくつかのメモがあります：

1. モノレポとは？ このユースケースをもう少し説明するとよいでしょう。
2. ほとんどの場合（特に大規模なプロジェクトに当てはまります）、ビルド中に生成される追加のアーティファクトが多数あります。 私たちの場合、これらはgulpを介したCSS、HTML、画像ファイルなどです。 このようなビルドツールの使用は、この新しいやり方にどのように採用されるのだろうか。 たとえば、*。tsファイルだけでなく、他のすべてのファイル（スタイル、マークアップなど）でもwatchを実行したいとします。 どうやってするか？ gulp watchとtsc -b -wを並行して実行する必要がありますか？

@vvs monorepoは、通常RushやLernaなどのツールによって管理されるNPMパッケージのコレクションです。

gulpを使用している場合は、プロジェクト参照をネイティブに理解するローダーを使用して、最高のエクスペリエンスを得ることができます。 @rbucktonは、内部でgulpfileを使用している開発者がいるため、ここでいくつかの作業を行いました。 多分彼はそこに良いパターンがどのように見えるかを検討することができます

@RyanCavanaughこれはよさそうだ。 私はレルナのガイダンスに非常に興味があります:)

@RyanCavanaughこれは素晴らしく見えます、私は現在私たちのlernamonorepoでそれを試すことに取り組んでいます。

あなたの記事で私に不明確なことはprependオプションだけでした。 どのような問題に対処しているのか、どのような状況で使用したいのか、使用しないとどうなるのか、よくわかりませんでした。

これはすごい！ 私はts-loaderと関連プロジェクトに取り組んでいます。 TypeScriptのLanguageServiceHost / WatchHostを使用するプロジェクトでこれをサポートするには、変更が必要になる可能性がありますか？

（私が言っていることの例については、https：//github.com/TypeStrong/ts-loader/blob/master/src/servicesHost.tsを参照してください。）

もしそうなら、すべてのガイダンス/ PRはありがたいことに受け取られます！ 実際、これをwebpackの世界でテストしたい場合は、これをサポートするバージョンのts-loaderのプッシュを喜んでお手伝いします。

もちろん、それが「うまくいく」なら、それはさらに良いです：smile：

すごい仕事！

@yortus @EisenbergEffect https://github.com/RyanCavanaugh/learn-aにサンプルのlernaリポジトリを設定し、それを機能させるために行った手順の概要をREADMEで示しました。

私が正しく理解している場合、すべて（Xとそのすべての依存関係および推移的な依存関係）が最新の場合、 tsc -b Xは何もしませんか？ 参照のない個々のプロジェクトの-bフラグがなくても、それを取得できるかどうか疑問に思っていますか？ （もちろん、その場合の依存関係はありません）

これはかなりクールです。 私はLernaをこのような構成で使用する傾向があります（モノレポジトリを機能ごとに分離するため）。 私はそれも同様に機能すると思います。

{{
"lerna"： "2.11.0"、
「パッケージ」：[
"パッケージ/コンポーネント/ "、"パッケージ/ライブラリ/ "、
"パッケージ/フレームワーク/ "、"パッケージ/アプリケーション/ "、
「パッケージ/ツール/ *」
]、
「バージョン」：「0.0.0」
}

だからこれはtypescript@next利用できますか？

これをyarnワークスペースリポジトリでテストします。 まだワークスペースをサポートしていないいくつかのモジュールにはnohoistを使用する必要があるため、ワークスペースがどのように処理されるかを確認すると便利です。

@RyanCavanaugh私は今夜​​テストランのためにレポを取りました。 私が抱えていたいくつかの問題を報告するために、レポで問題を開きました。 これをまとめてくれてありがとう。 すぐに使えるのを楽しみにしています。

本当に面白いです！ 現在、私の会社では、 mtscという独自のツールを使用して、複数のプロジェクトの監視モードを同時にサポートしています。 同じリポジトリでコンパイルして監視する必要があるプロジェクトが約5つあります。

プロジェクトには、次のようなさまざまな構成があります。 ECMAターゲティング（es5、es6）、タイプ（node、jest、DOMなど）、emit（webpackを使用するものもあれば、js自体にコンパイルするものもあります）。 それらはすべて1つのことを共有し、それはtslintプラグインであり、残りはすべて異なる可能性があります。 私のツールは、プロジェクトのコンパイル後にtslintも実行します（プロジェクトごとに実行され、tslintが完了する前にプロジェクトが再コンパイルされると停止します）。

現在の提案に関する私の主な懸念は、どのプロジェクトがどのリソースを共有しているかを言うことができないということです。 サーバーとクライアントプロジェクトがあり、どちらも特別なユーティリティフォルダーを使用していますが、コンパイルエラーが2回発生することは望ましくありません。 しかし、それはフィルターで修正できるので、大したことではありません:)

lerna monorepoで新しい--buildモードを試しました。これは、現在17の相互依存パッケージで構成されています。 すべてが機能するまでにはしばらく時間がかかりましたが、今ではすべて機能し、段階的に構築できることは私たちにとって大きな改善です。

以下に説明するいくつかの問題が発生しました。 これがTSチームにとって有益なフィードバックであり、他の人がプロジェクトで--buildモードを機能させるのに役立つことを願っています。

tsc --buildモードのフィードバック

1.偽の "\出力ファイル「2.map」が存在しないため、古くなっています。」

すべてのビルドのすべてのパッケージに対してこのメ​​ッセージが表示されたため、何も変更されていなくても、すべてのビルドが完全な再ビルドになりました。 @RyanCavanaughが＃25281でこれをすでに修正していることに気づいたので、毎晩20180628以降に更新しても問題はなくなりました。 次の問題は、少なくとも毎晩20180628更新したことを前提としています。

2. "\依存関係からの.d.tsファイルで最新である」

編集：＃25337で報告されました。

この問題を再現するには、 @ RyanCavanaughのlearn-aサンプルリポジトリを彼の指示に従って設定します。 tsc -b packages --verboseを実行して、すべてが最初に構築されることを確認します。 ここで、 pkg1/src/index.ts 1行目をimport {} from "./foo";して保存します。 tsc -b packages --verboseもう一度実行します。 pkg1がpkg2のソースを壊すように変更されたとしても、 pkg2のビルドはスキップされます。 これで、 pkg2/src/index.ts赤い波線が表示されます。 tsc -b packages --force再度ビルドすると、ビルドエラーが表示されます。 次の問題は、これを回避するために--forceビルドすることを前提としています。

3.生成された.d.tsファイルにより、ダウンストリームパッケージで「重複識別子」ビルドエラーが発生します

編集：＃25338で報告されました。

この問題を再現するには、 @ RyanCavanaughのlearn-aサンプルリポジトリを彼の指示に従って設定します。 次に、 lerna add @types/nodeを実行して、3つのパッケージすべてにNode.jsタイピングを追加します。 tsc -b packages --forceを実行して、正常にビルドされることを確認します。 次に、次のコードをpkg1/src/index.ts追加します。

// CASE1 - no build errors in pkg1, but 'duplicate identifier' build errors in pkg2
// import {parse} from 'url';
// export const bar = () => parse('bar');

// CASE2 - no build errors in pkg1 or in downstream packages
// import {parse, UrlWithStringQuery} from 'url';
// export const bar = (): UrlWithStringQuery => parse('bar');

// CASE3 - no build errors in pkg1 or in downstream packages
// export declare const bar: () => import("url").UrlWithStringQuery;

// CASE4 - no build errors in pkg1, but 'duplicate identifier' build errors in pkg2
// import {parse} from 'url';
// type UrlWithStringQuery = import("url").UrlWithStringQuery;
// export const bar = (): UrlWithStringQuery => parse('bar');

一度に1つのケースのコメントを解除し、 tsc -b packages --forceます。 ケース1と4は、 pkg2で大量のビルドエラーを引き起こします。 ケース2と3では、ビルドエラーはありません。 ケース1と4との重要な違いは、生成されたpkg1/lib/index.d.tsの最初の行のようです。

/// <reference path="../node_modules/@types/node/index.d.ts" />

ケース2と3は、この行を生成しません。 ケース1と4でpkg2が作成されると、異なるパスに@types/node宣言の2つの同一のコピーが含まれるため、「重複識別子」エラーが発生します。

ケース2と3が機能するため、おそらくこれは仕様によるものです。 しかし、それはかなり混乱しているようです。 pkg1には、これら4つのケースのいずれについてもビルドエラーや警告はありませんが、ダウンストリームビルドの動作は、エクスポートされた宣言の正確なスタイルに非常に敏感です。 （a） pkg1はケース1と4でエラーになるか、 （b） 4つのケースすべてが同じダウンストリームビルド動作を持つか、 （c） TSチームからの明確なガイダンスがあるはずです。この問題を回避するための宣言の書き方。

4.ヤーンワークスペースを使用する場合に生成された.d.tsファイルのimportタイプの問題

17パッケージのmonorepoでビルドモードを動作させようとしたときに、生成された.d.tsファイルのimportタイプの相対パスによって引き起こされるいくつかのビルドエラーを処理しました。 私はついにモジュールの巻き上げに関連する問題を解決しました。 つまり、yarnワークスペースを使用する場合、インストールされているすべてのモジュールは、monorepo内のすべてのパッケージのシンボリックリンクを含めて、monorepo-root node_modulesディレクトリに持ち上げられます。 lerna.jsonのpackagesプロパティを使用するようにmonorepoを変更しました。これにより、 lernaは独自の非ホイストブートストラップアルゴリズムを使用するようになり、問題が解決しました。 とにかく、遅いですが、より良い/より安全なアプローチです。

TSがモジュールで持ち上げられたセットアップをサポートするつもりかどうかわからないので、私は遭遇した問題の再現を開発していませんが、興味があれば作成を試みることができます。 私はこの問題は、いくつかのトップレベルの両方を経由して、同じタイプを取得している構築することかもしれないと思うpackages （TSconfigの設定どおり）ディレクトリとトップレベルのnode_modulesごとにディレクトリ（ importは、生成された.d.tsファイルを入力します）。 これは構造型が原因で機能する場合がありますが、エクスポートされた一意のシンボルなどでは失敗します。

5.繰り返し構成

使用レルナにmonorepoを設定すると、基本的には同じようなもの置く必要が"packages": ["packages/*"]でlerna.json 。 Lernaは、globstarsを展開して正確なパッケージリストを作成し、次に各パッケージのpackage.json宣言されている依存関係を調べて正確な依存関係グラフを作成します。 パッケージと依存関係は自由に追加および削除でき、 lernaはその構成に触れることなく維持されます。

TypeScript --buildモードには、もう少しセレモニーが含まれます。 グロブパターンは認識されないため、すべてのパッケージを@RyanCavanaughのlearn-aサンプルリポジトリに明示的にリストして維持する必要があります（たとえば、 packages/tsconfig.json ）。 ビルドモードはpackage.json依存関係を調べないため、すべてのパッケージは、依存する他のパッケージのリストをpackage.jsonファイル（ "dependencies" ）と両方で維持する必要があります。それはtsconfig.jsonファイルです（ "references" ）。

これは小さな不便ですが、 lerna'sアプローチと比較してリグマロールが目立つことがわかったので、ここに含めます。

6.グローバルモジュールの拡張によるtscクラッシュ

編集：＃25339で報告されました。

この問題を再現するには、 @ RyanCavanaughのlearn-aサンプルリポジトリを彼の指示に従って設定します。 次に、 lerna add @types/multerを実行して、3つのパッケージすべてにmulterタイピングを追加します。 tsc -b packages --forceを実行して、正常にビルドされることを確認します。 次に、次の行をpkg1/src/index.ts追加します。

export {Options} from 'multer';

tsc -b packages --forceもう一度実行します。 アサーションに違反したため、コンパイラがクラッシュします。 スタックトレースとアサーションを簡単に見てみましたが、これはExpress名前空間のグローバルな拡張と関係があるようです。

フィードバックをありがとう@yortus 。 頼りに感謝します。 3の場合は、 https：//github.com/Microsoft/TypeScript/issues/25278だと思い

4の場合、私は概念としてのモジュール巻き上げに精通していません。 詳細を説明したり、再現を共有したりできますか？

@mhegazy lernaとyarnを使用する多くの人がワークスペースを使用しています（私を含む）。 詳細はこちら： https ：

私は現在、yarnワークスペース、lerna、拡張tsconfigsを使用しています。ここで、ベースtsconfigは、 root/node_modules下にあるホイストモジュールを持つすべてのパッケージで共有されるpaths宣言します。 yarnとmonorepoを聞いたとき、それが機能の目的であるため、 workspacesだと思います-使いやすく、重複を減らすためです。 この変更により、ベースのtsconfigで宣言された長くて苦痛なpathsが簡単に削除されることを期待していました。

これが私たちのルートmonorepotsconfigのサンプルです（それが助けになるなら）：

{
  "extends": "./packages/build/tsconfig.base.json",
  "compilerOptions": {
    "baseUrl": "./packages",
    "paths": {
      "@alienfast/build/*": ["./build/src/*"],
      "@alienfast/common-node/*": ["./common-node/src/*"],
      "@alienfast/common/*": ["./common/src/*"],
      "@alienfast/concepts/*": ["./concepts/src/*"],
      "@alienfast/faas/*": ["./faas/src/*"],
      "@alienfast/math/*": ["./math/src/*"],
      "@alienfast/notifications/*": ["./notifications/src/*"],
      "@alienfast/ui/*": ["./ui/src/*"],
      "@alienfast/build": ["./build/src"],
      "@alienfast/common-node": ["./common-node/src"],
      "@alienfast/common": ["./common/src"],
      "@alienfast/concepts": ["./concepts/src"],
      "@alienfast/faas": ["./faas/src"],
      "@alienfast/math": ["./math/src"],
      "@alienfast/notifications": ["./notifications/src"],
      "@alienfast/ui": ["./ui/src"],
    }
  },
  "include": ["./typings/**/*", "./packages/*/src/**/*"],
  "exclude": ["node_modules", "./packages/*/node_modules"]
}

サンプルのフォークでショットを撮ります：
https://github.com/RyanCavanaugh/learn-a

ヤーンワークスペースを使用した@RyanCavanaughのリポジトリへのマージされないPRは
https://github.com/RyanCavanaugh/learn-a/pull/3/files

また、 Jupyterlabでは、レルナとヤーンを使用したモジュール巻き上げを使用しました。 基本的に、インストールされている依存関係をすべてのパッケージ間で共有できるため、ファイルシステムのルートプロジェクトに1回だけ存在します。

ワークスペースは、すべてのパッケージ間でlinkコマンドを使用して相互にアクセスできるようにする（または少なくとも依存関係にアクセスできるようにする）よりも少しクリーンであると理解しています。

上記のように、モジュールの巻き上げにより、すべての依存関係がルートnode_modulesディレクトリに移動します。 これは、ノードモジュールの解決が常にディレクトリツリーをトラバースし、必要なモジュールが見つかるまですべてのnode_modulesディレクトリを検索するという事実を利用しています。 モノリポジトリ内の個々のモジュールは、このルートnode_modulesシンボリックリンクされ、すべてが正常に機能します。 糸のブログ投稿はおそらく私ができるよりもそれをよりよく説明しています。

巻き上げが発生する保証はありません。 同じパッケージのバージョンが一致しない場合、それらは引き上げられません。 また、既存のツールの多くは、 node_modulesがどこにあるかを想定しているか、ノードモジュールの解決に正しく従わないため、巻き上げをサポートしていません。 このため、特定のモジュールまたは依存関係の巻き上げを無効にできるnohoist設定があります。

以前のフィードバックに6番目の項目を追加しました。 tsc説明されているシナリオでは、

@mhegazyアイテム3が＃25278に関連しているかどうかは

上記のように、モジュールの巻き上げにより、すべての依存関係がルートnode_modulesディレクトリに移動します。 これは、ノードモジュールの解決が常にディレクトリツリーをトラバースし、必要なモジュールが見つかるまですべてのnode_modulesディレクトリを検索するという事実を利用しています。

ところで、このモデルには欠点があります。それは、プロジェクトがpackage.jsonファイルで明示的に宣言されていない依存関係をインポートできる「ファントム依存関係」につながることです。 ライブラリを公開すると、（1）テスト/期待されたものとは異なるバージョンの依存関係がインストールされる、または（2）インストールされていない無関係のプロジェクトから引き上げられたために依存関係が完全に失われるなどの問題が発生する可能性がありますこの文脈で。 PNPMとRushはどちらも、ファントムの依存関係から保護することを目的としたアーキテクチャ上の選択肢があります。

tsc --buildについて一般的な質問があります：TypeScriptコンパイラは、モノリポジトリ内のプロジェクトのビルドを調整する役割を引き継ぐことを目指していますか？ 通常、ツールチェーンには、次のようなタスクのパイプライン全体が含まれます。

• 前処理
• ローカライズされた文字列の生成
• アセットをJavaScriptに変換する（css、画像など）
• コンパイル（型チェック/トランスパイル）
• .jsファイルのロールアップ（例：webpack）
• .d.tsファイルのロールアップ（例：API Extractor）
• 単体テストとドキュメント生成を含む後処理

通常、GulpやWebpackなどのシステムがこのパイプラインを管理し、コンパイラーはチェーンの途中の1つのステップにすぎません。 場合によっては、セカンダリツールが別の方法でビルドを実行することもあります（例： jest --watch Jest + ts-jest）。

tscは、これらのもの自体を管理することを目的としていますか？ そうでない場合は、従来のビルドオーケストレーターが依存関係グラフ自体を解決する方法がありますか？たとえば、各プロジェクトフォルダーで正しい順序でtscを繰り返し呼び出す方法はありますか（前処理が更新された後）？

または、モノリポジトリ全体を1回のパスで処理する設計の場合（今日は各プロジェクトを個別のNodeJプロセスでビルドします）、他のビルドタスクがどのように参加するかについても興味があります。たとえば、Webpackを実行しますか？すべてのプロジェクトを一度に？ （過去には、メモリ不足の問題が発生していました。）マルチプロセスの同時実行性を利用する機能が失われますか？

ところで、これらは批判ではありません。 全体像と使用目的を理解しようとしています。

@pgonzalそうですね、現実世界のモノレポを構築するには、tsc以外の部分がたくさんあります。 私たちのlernamonorepoについては、次のアプローチを採用しました。

• monorepoの各パッケージは、オプションでprebuildスクリプトおよび/またはpackage.json postbuildスクリプトを定義します。 これらには、ビルドのtsc以外の側面が含まれています。
• monorepoのpackage.jsonには、次のスクリプトがあります。
  "prebuild": "lerna run prebuild", "build": "tsc --build monorepo.tsconfig.json --verbose", "postbuild": "lerna run postbuild",
• それでおしまい。 monorepoレベルでyarn buildを実行すると、それらを定義する各パッケージに対してprebuildスクリプトが実行され、次にtsc --buildステップが実行され、次にすべてのpostbuildスクリプト。 （NPM糸の両方において慣例により、実行npm run foo略同じであるnpm run prefoo && npm run foo && npm run postfoo ）。

jest --watchまたはwebpack-dev-serverどのように処理しますか？ たとえば、ソースファイルが変更された場合、ビルド前/ビルド後の手順は再度実行されますか？

これはts-nodeおよび関連するワークフローに影響を及ぼしますか？ "start": "ts-node ./src/app.ts"や"start:debug": "node -r ts-node/register --inspect-brk ./src/app.ts"など、一部のヘルパーアプリはTypeScriptから「直接」実行されます。

＃25355でビルドモードに関する別の問題を報告しました。

これまでのすべての素晴らしいフィードバックと調査に感謝します。 時間をかけて試してみて、タイヤを蹴ってくれた皆さん、本当にありがとうございました。

@yortus re https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -400439520

素晴らしい記事、これを提供してくれてありがとう。 順番にあなたの問題-

1. 修理済み
2. ＃25370でPRアップ
3. ログに記録された問題について話し合う-正しい修正が何であるかはすぐにはわかりませんが、何かをします
4. 調査中（下記）
5. ログに記録された＃25376
6. --build AFAICTとは技術的に無関係です。 これは、最近追加した新しいアサーションです。 ネイサンの調査

@ rosskevin🎉 learn-aレポのPRに！ これをブランチにマージして、比較と対比を改善します。

@pgonzal re https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -401577442

tsc --buildに関する一般的な質問があります。TypeScriptコンパイラは、モノリポジトリ内のプロジェクトのビルドを調整する役割を引き継ぐことを目指していますか？

素晴らしい質問です。 私はこれに非常に明確に答えたいと思います：絶対にありません。

今日はtscを使用してプロジェクトを構築することに満足している場合は、明日はtsc -bを使用してマルチパートプロジェクトを構築することに満足してください。 今日はgulpを使用してプロジェクトを構築することに満足している場合は、明日はgulpを使用してマルチパートプロジェクトを構築することに満足してください。 最初のシナリオは制御できますが、2番目のシナリオを支援するツールとプラグインの作成者が必要です。そのため、 tsc -bさえ、プロジェクト参照を適切に再生するためにツール作成者が使用できる公開APIの薄いラッパーにすぎません。彼らのビルドモデルで。

より広い文脈では、 tsc -bが存在するべきか、それとも別個のツール/エントリポイントになるべきかについて、かなり強力な内部討論がありました-汎用ビルドオーケストレーターの構築は巨大なタスクであり、私たちのタスクではありませんサインアップします。 私たち自身のリポジトリでは、軽いタスクランナーフレームワークでtscを使用し、同じタスクランナーでtsc -bしました。移行する他の人も、既存のビルドチェーンを維持することを期待しています。微調整のみで。

@borekb re https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -401593804

これは、ts-nodeおよび関連するワークフローに影響を及ぼしますか？ 一部のヘルパーアプリは、TypeScriptから「直接」実行されます

暗黙的にプロジェクト参照を持つことができない単一ファイルスクリプトの場合、影響はありません。

@EisenbergEffectは、プロジェクト間の名前変更やその他の言語サービス機能について、 learn-aリポジトリにいくつか質問がありました。 ここでの大きな未解決の質問は、この機能を3.0で使用可能な状態で取得できるかどうかだけです。 もしそうなら、プロジェクト間の名前変更は「うまくいく」でしょうが、すべてのダウンストリームプロジェクトを最終的に見つけ

プロジェクト間の名前変更が3.0で許容できるほど安定していて完全であると思わない場合は、名前が変更されたシンボルが別のプロジェクトの.d.ts出力ファイルにある場合に後、アップストリームプロジェクトの後続のビルドで.d.tsファイルが更新されるため、非常に混乱します。つまり、ローカルの名前を変更してから宣言コードに気付くまでに数日かかる可能性があります。実際には更新されていませんでした。

Go to Definitionのような機能の場合、これらは現在VS Codeで機能しており、VisualStudioの将来のバージョンではすぐに機能する予定です。 これらの機能はすべて、.d.ts.mapファイルを有効にする必要があります（ declarationMapオンにします）。 これを明らかにするための機能ごとの作業がいくつかあるため、期待どおりに機能しないものが見つかった場合は、いくつかのケースを見逃している可能性があるため、バグをログに記録してください。

この時点で追跡している未解決の問題：

• プロジェクト間の名前変更-@ andy-msが実装されています
• 吊り上げられたモジュールのセットアップを分析し、それらの影響を理解する必要があります-私にとって
• サンプルのバージョンがあるはずですlearn-aレポその用途yarn 、および他のその用途pnpm 、および他の用途掲揚モードでは、これらのいずれかをその

未解決の質問

• プロジェクト参照を推測するためにpackage.jsonを読み取るロジックを実装する必要がありますか？ ログに記録された＃25376
• compositeプロジェクトでは、 .d.ts.mapエミットを暗黙的にオンにする必要がありますか？

@RyanCavanaughに追加する

この時点で追跡している未解決の問題

また、実際のプロジェクトの出力場所とは別に、LSのバックグラウンドで宣言を更新するなどの処理を行うために、増分出力キャッシュを用意することについても説明しました（現在、変更はビルドするまでエディターのプロジェクト境界を越えて伝播されません）。 stripInternal 、およびビルドプロセスの変更（ビルド出力がその場で変更されるため、LS操作には適していません）。

ばかげた質問で申し訳ありませんが、ロードマップでチェックされているので、この機能を有効にするにはどうすればよいですか？

@ aleksey-bykovあなたはtypescript @ nextでそれを使うことができます

ヤーンワークスペースを搭載したモノレポでこれを試してみましたが、うまく機能します。

私が気づいたことの1つは、 tsc --build --watchがエラーを報告しますが、ビルドが修正されたことを示すものを何も出力しないことです。 2.9の標準のtscウォッチモードはエラーカウントを出し始めており、そこにゼロが表示されているので、構築が完了したことがわかります。

私は* .d.tsでいっぱいのフォルダを持っていますが、それについて何をすべきか他に何もありません：

• それをプロジェクトにして参照します（試しましたが、機能しませんでした）
• 「インクルード」を使用してください

@timfishのフィードバックは、私が聞いた他のフィードバックと一致します。 ログに記録された＃25562

@ aleksey-bykov https://github.com/Microsoft/TypeScript/issues/3469#issuecomment-400439520はいくつかの概念を説明するのに役立つはずです

@RyanCavanaughプロジェクトの参照は、commonjsとノードモジュールの解決でのみ機能するようですよね？

あなたの例では：

import * as p1 from "@ryancavanaugh/pkg1";
import * as p2 from "@ryancavanaugh/pkg2";

p1.fn();
p2.fn4();

1. @ryancavanaughモジュールとは何ですか？TSがモジュールを解決する方法とは関係がありますか？
2. この例はAMD（クラシックモジュール解像度）で動作するはずですか？
3. 定義を見つけるにはoutFile必要ですか？
4. d.tsファイルは、参照プロジェクトがそれらを見つけるためにあるはずです（outDirを引き続き使用できますか？TSはそこでそれらを見つけますか？）

私は2つの単純なプロジェクトessentialsとcommonを持っていますが、共通点ではエッセンシャルでコンパイルされたものを解決できません。

@ aleksey-bykov

1. これはスコープ付きモジュール名であり、通常のノードモジュール解決アルゴリズムで解決されます
2. クラシックを含む任意のモジュールシステムでプロジェクト参照を使用できますが、サンプル名（スコープモジュール）はノード外での使用にはあまり適していません
3. 番号
4. TypeScriptは、参照されたプロジェクトがそれらをビルドする場所にある.d.tsファイルを探します

サンプルリポジトリなどがある場合は、なぜそのエラーが発生するのかを診断できます

@RyanCavanaughしてください
example.zip

@RyanCavanaugh 、 tsc --build --watchは、ソースファイルの変更を確認するまで、最初はファイルを出力しないようです。

スレッドが長すぎます（時間と空間の両方で）; ラッキーイシューナンバー100 * 2 ^ 8：＃25600でディスカッションをピックアップしましょう