ねえ@lazutkin。 現在はサポートされていませんが、多少関連しているため、この問題を＃2869にリンクしたいと思います。

フォルダー内に引数なしでtscを実行している場合、コンパイラーは、作成しているフォルダーに最も近いtsconfig.jsonを選択します。 したがって、tsconfig.jsonを含む内部ディレクトリがある場合は、外部ディレクトリのディレクトリよりも前に取得されます。

複数のtsconfig.jsonからの統合/構成のオーバーライドをサポートするとは思いません。

大規模なエンタープライズアプリには、複数のtsconfigファイルが不可欠です。
提案：tscがサブディレクトリで新しいtsconfigファイルを見つけるたびに、tscはここで停止し、独自のtsconfigファイルを使用して新しいtscプロセスを作成します。

@Eisenspalterこれは、grunt、

@mhegazy @Eisenspalterに同意します。どちらもビルドプロセスについてではなく、ビルド前に完了する必要のあるソースの作成、テスト、その他のアクティビティを含む開発プロセスについて話しているからです。 このすべての中間ステップでは、インテリセンス、タイプチェックなどを含むtypescriptからのサポートが必要です。さらに、前に述べたように、プロジェクトのさまざまな部分に、さまざまなソース編成手法（外部-内部モジュール、単一）を適用したいと思います。出力ファイルなど）、ここでは、個別のtsconfigでオーバーライドするいくつかのオプションが必要です。

@mhegazyなぜ閉じたのですか？ 再度開いてください。

今日、複数のtsconfigを使用でき、それぞれが重複するファイルのセットを指しています。 したがって、1つはsrctsconfig.jsonに、もう1つはteststsconfig.jsonなどにあります。コンパイラ/ツールは、ディレクトリツリーを上って最も近いファイルを見つけることにより、ファイルを見つけます。 したがって、ルートに3番目のファイルを作成してすべてをキャッチできます。

これはすべて、コンパイラとさまざまなIDEで今日機能します。 元々の問題は、ファイルが別のファイルから継承できるようにすることでした。 複雑さを正当化する十分な価値があるとは思いません。

2番目の問題の場合：

tscがサブディレクトリで新しいtsconfigファイルを見つけるたびに、tscはここで停止し、独自のtsconfigファイルを使用して新しいtscプロセスを作成します。

前に述べたように、tsconfig.jsonは、tsc.js / tsc.exeへの単一の呼び出しを表します。複数の呼び出しを実行する場合は、ビルドドライバーを使用する必要があります。

@lazutkinと@Eisenspalterはこれが質問に答えますか

@mhegazy
複数のtsconfig.jsonを機能させることができませんでした。 少なくともTypeScript1.7.3では、1つのtsconfig.jsonのみが読み取られ、プロジェクトのルートディレクトリ（または親）にあることが期待されます。

@Ziink上記の私のコメントは、同じプロジェクト内の複数のtsconfigに関するものではありませんでした。 それは、それぞれが異なるtsconfigを持つ複数のプロジェクト/ディレクトリに関するものでした。 これは、tsプロジェクトのレイアウト方法です。https：//github.com/Microsoft/TypeScript/tree/master/srcを参照して

TypeScriptで記述されたプロジェクトがあり、両方をターゲットにしたい：

1. ES5 / AMDを搭載したブラウザ（ /browserファイルとしましょう）と
2. CommonJSとジェネレーター（およびTSのasync / await）を使用したnodejs（ server内のファイル）。

たとえば、（ /common ）フォルダにいくつかの共有ファイルがあり、 commonからbrowserおよびserverへのインポートがあります。
IDEサポート、すべてのエラーなどを保持するそのような構成をどのように達成できますか？ 議論が私の疑問に答えたかどうかはわかりません。

@bartq TS 1.8では、2つのtsconfigファイルを作成します。1つはブラウザー用、もう1つはサーバー用で、両方のサブプロジェクトのファイルに///参照を共通のものに追加します。 試してみて、これがシナリオに対応しているか、まだ不足している部分があるかどうかをお知らせください。

実際、私はこれら2つのtsconfig.jsonファイルを使用していますが、WebStormはそれらを検出し、コンパイルを自動的に実行します。 正確には、バックエンドコードはフロントエンドコードからいくつかのクラスをインポートします（代わりにcommon概念を使用します）が、すべて正常に機能します。

私はついに解決策を手に入れました。

私のアプリケーション構造：
--app /--app / client /（私のクライアント側のソースコード）--app / server /（サーバー側のソースコード）--app / build /（jsを生成する場所）--app / node-modules /--app / package.json--app / tsconfig.server.json--app / tsconfig.client.json

tsconfig.server.jsonの内容：
{"compilerOptions"：{...、 "outDir"：_ "build / server" _}、"exclude"：["node_modules"、 "client"]}

tsconfig.client.jsonの内容：
{"compilerOptions"：{...、 "outDir"： "build / client"}、"exclude"：["node_modules"、 "server"]}

次に、サーバーのソースコードをコンパイルする場合は、アプリのルートディレクトリから次のコマンドを使用します。

tsc --p tsconfig.server.json

また、ルートアプリディレクトリからクライアントソースコードをコンパイルするには：

tsc --p tsconfig.client.json

クライアントとサーバーの両方のコンパイルを実行するために、package.jsonにコマンドを追加しました。

"scripts"：{...、 "tsc"： "tsc --p tsconfig.server.json && tsc --p tsconfig.client.json"、...}

次に、サーバーとクライアントの両方をコンパイルするために、ルートアプリディレクトリからこれを実行します。

npm run tsc

このコメントがお役に立てば幸いです:-)

ここで何が問題なのかわかりません。 異なるファイル名の構成をサポートできないのはなぜですか？ 別のtsconfigファイルをに入れるためだけにsubFoldersを作成しなければならないのは面倒です。

あなたはできる。 --p引数はファイル名にすることができます。

ただし、異なるファイル名は、そのままではVisual Studioタイプスクリプトコンパイラ拡張機能（CLIについては説明していません）では機能しません。 これを行う唯一の方法は、各tsconfig.jsonをダミーディレクトリに配置し、 filesオプションを使用して必要なタイプスクリプトにリンクすることです。

例えば

--src / target / search / tsconfig.json
--src / target / core / tsconfig.json
--src / target / users / tsconfig.json

target / search /tsconfig.jsonは次のようになります。

{
  "compilerOptions": {
    "outFile": "../../../build/app/search.js"
  },
  "files": [
    "../../src/common",
    "../../src/search"
  ]
}

そして、他のものも同様です。

これにより、それぞれ独自のファイル構成を持つ3つのJavaScriptファイルが1つにバンドルされて生成されます。

もちろん、Typescriptコンパイラ自体とは異なるバンドル/最小化/パッケージングのソリューションを使用することもできます。

Typescriptコンパイラが最適化で本当に良い仕事をしているというだけです-それはTypescriptを使用することの最大の魅力の1つです。

したがって、単一のtsconfig.jsonがtsconfigsの配列に変更するだけで、複数の構成をサポートできると便利です。

[
  {
    "compilerOptions": {
      "outFile": "../../build/search.js"
    },
    "files": [
      "src/common",
      "src/search"
    ],
    "compileOnSave": true
  },
  {
    "compilerOptions": {
      "outFile": "../../build/core.js"
    }
    "files": [
      "src/common",
      "src/core"
    ],
    "compileOnSave": true
  }
]

これは、この問題の後のコメントで要求されているように聞こえますが、私は同意しますが、元の問題は継承と構成のオーバーライドに関するものでした。

@mhegazy @bartq tscコマンドで動作させることはできません。
私は次のディレクトリ構造を持っています

-- app/
-- app/server  -- here I want es6/commonjs
-- app/server/tsconfig.json
-- app/client    -- here I want es6/es6 
-- app/client/tsconfig.json
-- app/tsconfig.json

私が実行したときに、まだ、 tscのみからconfigコンapp/tsconfig.json使用され、残りは無視されます。 私はそれをVSCodeで動作させようとしています：/

@tomitrescak私はWebStormを使用しており、最も近いtsconfig.jsonを見つけて、ファイルを編集するときにそれを使用するのに十分インテリジェントです。 おそらく、複数のtsconfig.jsonの監視をサポートするcmdツールはありません。 たとえば、FBウォッチマンを使用して展開できます。

ええ、私はVSCodeでこのようなものが欲しいです。 ターミナルでコンパイルを実行しています。 同様に動作します。 VS Codeは、とにかくエラーを正しく識別します。

複数の設定があれば素晴らしいでしょう。 私はReact-Nativeプロジェクトに取り組んでおり、基本的に2つのビルドを実行したいと思っています。

1. 私のReact-Nativeプロジェクトのスクリプト
2. React-Native WebView（チャート）のHTMLで使用されるスクリプト。

構成の継承はTS2.1で追加され、今日typescript@nextで利用できるようになるはずです。 詳細については、 https：//github.com/Microsoft/TypeScript/issues/9876を参照してください。 これにより、「マスター」tsconfig.jsonを作成し、そこから構成を継承するものをオーバーライドできます。 それでも複数のtsconfig.jsonファイルを作成する必要がありますが、IDEはこれらを取得する必要があります。

私は次のディレクトリ構造を持っています：

├── examples
│   ├── files...
│   └── tsconfig.json
├── src
│   └──files...
└── tsconfig.json

ルートtsconfig.jsonは次のものがあります。

{
  "compilerOptions": {
    "target": "es2015",
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "dist",
    "sourceMap": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "removeComments": false,
    "noImplicitAny": false,
    "declaration": true,
    "allowJs": false
  },
  "include": [
    "./src"
  ],
  "compileOnSave": false,
  "buildOnSave": false,
  "atom": { "rewriteTsconfig": false }
}

examples/tsconfig.jsonは、次の点を除いて同じ値です。

  "include": [
    "./hello-world"
  ],

私がする時：

cd examples
tsc

コンパイルします：

├── examples
│   ├── dist
│   │   ├── examples
│   │   └── src
│   ├── files...
│   └── tsconfig.json
├── src
│   └──  files...
└── tsconfig.json

（ dist間違っていると、外部フォルダーsrcが含まれ、ルートフォルダー内からコンパイルされます）

これを助けない（ examples/tsconfig.json ）：

  "exclude": [
    "../src"
  ],

私は何が間違っているのですか？

問題が見つかりました。 私のexamples/hello-world/any-file*.tsこのインポートがある場合：

import { SomeClass } from '../../src';

上記の問題を生成します。 次のインポートは期待どおりに機能します。

import { SomeClass } from '../../';

しかし、typescriptのディレクティブinclude期待どおりに機能しないのはなぜですか？

動かない
同じフォルダーにtsconfig.jsonがありますが、「警告：親tsconfig.jsonが見つかり

@zhukovkaローカルで実行できるスタンドアロンの再現で新しい問題をログに記録してください

@RyanCavanaughああ。 おかげで、私はそれを理解しました
この問題は、テストフォルダー（tsconfig.jsonを含まない）から1つのファイルを開き、 'src'フォルダー（tsconfig.jsonを含む）で2番目のファイルを開いた場合にのみ再現されます。
テストフォルダのファイルは、srcフォルダのファイルをインポートします。 この場合、srcフォルダーのファイルには「親tsconfig.json」が表示されません。

@RyanCavanaugh、いくつかの異なるtsconfig.jsonのでコンパイルするためのサポートをしたいと思い何か開発され続けているようです。 私の場合、一般的には、生成された出力ファイルの移動先を変更することについてです。 コード生成を既存のpathsマッピングのようなもので制御できれば、生成されたコードをソースとは異なる方法でレイアウトできるようになり、複数のプロジェクトの必要性が減る可能性があります。

私のユースケースは、より厳密な型チェックルールに耐えられない大きなレガシーコードベースがあり、厳密なチェックが有効になっている新しいコードベースで使用したいのですが、レガシーコードをコンパイルできません。ライブラリには、エクスポート用の型に名前を付けるために必要なすべての型をインポートしないケースが100万件あるためです（＃9944）。 したがって、レガシーコードベースを新しいコードベースに追加したいのですが、緩いルールに従ってコンパイルされています。 これを2つの異なるコンパイル手順にすることはできません。 コンパイラが特定のディレクトリの下のソースファイルで作業しているときは、laxerルールを使用する必要があります。

私の場合、ユースケースは、ノードを使用して実行され、commonjsモジュールにコンパイルする必要があるリポジトリの一部を持ち、ES6でツリーシェイクを有効にするために他の部分をES6モジュールにコンパイルする必要があります。 私の場合、経験は素晴らしいものではありません。 TS_NODE_PROJECT環境変数を使ったハッキン​​グがたくさんあります。 私が最終的にプロジェクトを変更するときに、それを維持している次の人の地獄を混乱させる可能性があるもののように思えます。

私はまだこれが解決されるのを見たいです。 プロジェクト内のモジュールごとに異なるtsconfig.jsonファイルを必要とする大規模なプロジェクトにとっては大きなメリットになります。

@Robinfr extends機能で解決できないものは何ですか？

しました。 私はこの投稿の後でそれについて知りました。 ただし、注意すべき点の1つは、 includeを、kがwebpackを通過するため、通常は必要のないファイルに設定しないと機能しなかったことです。

Op 159月 2017年9時24午前schreefキットソンケリー[email protected] ：

@Robinfr https://github.com/robinfr拡張機能https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#configuration-inheritance-with-extendsで解決できないものは何ですか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/Microsoft/TypeScript/issues/3645#issuecomment-329703706で表示するか、スレッドをミュートしてくださいhttps://github.com/notifications/unsubscribe-auth/AD90FLZKcHMJeFU0osJroT_yawlC1oTIks5siiZFgaJpZM4FM

@kitsonk拡張はうまく機能しますが、何か問題がない場合は、両方の構成で特定の設定（buildフォルダーとnode_modulesフォルダーを除く）を繰り返す必要があります。 私にとって最大の問題は、どの構成ファイルが正しいかをすべてのツールが認識していることを確認することです（通常、 TS_NODE_PROJECT環境変数などを使用します。もう1つは、2つのtsconfigを使用してプロジェクトを開く場合です。 VS.code。使用するプロジェクトファイルをVSに指示する方法はありません。つまり、対応するtsconfig内のファイルの設定が異なるため、一部のファイルではエラーに正しく下線が引かれません（たとえば、何かtsconfig.build.jsonのように）。

@voyは、ビルド用に異なるtsconfigがある理由を尋ねてもよいですか？ 私が理解している限り、VSCodeは、編集しているファイルに最も近いtsconfigファイル（ tsconfig.json ）を使用します。 私がこれまでに抱えていた唯一の問題は、VSCodeが構成の使用を開始する前に、ルートにtsconfigファイルが必要なことです...

@Robinfr確かに。 同じリポジトリに、webpackとbabelを使用して処理され、ES6モジュールを使用してツリーシェイクを有効にするファイルがあります。 他のファイルはビルドプロセスの一部であり、ノードを使用して実行されます。そのため、インポートをrequiresにトランスパイルする必要があります。 どうすればそれを回避できるかわかりません。

@voyは、これらのファイルを別のフォルダーに置いているだけではありませんか？ たとえば、すべてのBabelおよびwebpackファイル用に1つのフォルダー、ノードファイル用に1つのフォルダー。 次に、これらのフォルダーごとにtsconfig.jsonを作成できます。 それはあなたのために働きませんか？

@Robinfrは理想的ですが、現実の世界では常に可能であるとは限りません。 たとえば、すべての構成ファイルもtypescriptであり、すべてのTypeScriptコードベースとまったく同じルールに従ってコンパイルおよびリントされ、一部のファイルはプロジェクトのルートにある必要があります。 シンボリックリンクすることもできますが、それによって他の問題が発生することがあります。 だからこそ、もっと柔軟なものがあればいいと思います。