Typescript: tscは気にせず、rootDir外のtsファイルで失敗するはずです

回避するために、 tsconfig.json 「除外」を追加し直します

rootDirは、出力フォルダー構造を構築するために使用されます。 コンパイラが出力の書き込み先を知るには、すべてのファイルがrootDirの下にある必要があります。 この制約がない場合、rootDirの下にないファイルがある場合、コンパイラには2つのオプションがあります。1。まったく予期しない場所に出力されるか、2。まったく出力されないかのいずれかです。 エラーメッセージは、サイレントエラーよりもはるかに優れていると思います。

@mhegazy説明してくれてありがとう。 名前でrootDirブラウザのbaseURLように、ソースコードのルートディレクトリとして使用しました。 出力フォルダ構造専用だとは知りませんでした。

これが私のtsconfig.jsonです：

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "sourceMap": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "removeComments": true,
        "noImplicitAny": true,
        "rootDir": "src",
        "outDir": "build"
    },
    "exclude": [
        ".idea",
        "build",
        "node_modules",
        "typings/globals",
        "typings/modules"
    ]
}

私のフォルダ構造は次のようになります。

• 事業
  
  
  
  • 建てる
  
  
  • node_modules（../ node_modulesへのシンボリックリンク）
  
  
  • node_modules
  
  
  • src
  
  

srcフォルダー内の.tsファイルをコンパイルして、同じフォルダー構造でビルドフォルダーに出力したいと思います。 これを行うのは、ドキュメントルートをビルドフォルダーに設定し、srcをドキュメントルートから除外できるようにするためです。 node_modulesフォルダー内の.tsファイルに関するエラーメッセージが表示されます。これはOPと同じエラーメッセージです。 上記のように、node_modulesは除外されています。 なぜtscはそれらについて不平を言っているのですか？

@HillTravisあなたの問題はhttps://github.com/Microsoft/TypeScript/issues/9552と同じよう

@mhegazy同じかどうかは

＃9552には、srcフォルダーがありません。つまり、作成中のパスにnode_modulesフォルダーが存在します。 私のシナリオでは、tscが確認する必要のあるルートディレクトリはsrcであり、node_modulesは含まれていません。 したがって、そのフォルダを見ているべきではありません。 その上、tsconfig.jsonを介してnode_modulesフォルダーを明示的に除外しています。 したがって、それは二重に無視されるべきです。 buildフォルダーも除外しているので、その中のnode_modulesへのシンボリックリンクをカバーする必要があります。

また、＃9552では、エラーメッセージやコンパイルの失敗についての言及はありませんでした。

TypeScript1.8.10を使用していることにも言及する必要があります。

具体的には、エラーメッセージは次のとおりです。

エラーTS6059：ファイル '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.module.ts'は 'rootDir' '/ Users / thill / Projects /の下にありませんnrc / client / src '。 'rootDir'には、すべてのソースファイルが含まれている必要があります。

エラーTS6059：ファイル '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.ts'は 'rootDir' '/ Users / thill / Projects / nrc /の下にありませんclient / src '。 'rootDir'には、すべてのソースファイルが含まれている必要があります。

エラーTS6059：ファイル '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/timepicker-event-interface.ts'は 'rootDir' '/ Users / thill / Projects /の下にありませんnrc / client / src '。 'rootDir'には、すべてのソースファイルが含まれている必要があります。

@HillTravisあなたはこれで私を信頼することができます:)コンパイラをスローするのはシンボリックリンクの一貫性のない処理です。 ノードモジュールの解決のためにのみシンボリックリンクをたどり、その名前をファイル名として使用します。 次に、チェックを実行して、ユーザーが指定したパスではなく、実際のパスを使用して、すべてのファイルがソースディレクトリの下にあることを確認します。 それがエラーを生成するものです。

テストとして、シンボリックリンクを削除してみました。 実際、 buildフォルダー全体を削除しました。 次に、 tsc再度実行しましたが、それでもエラーが発生しました。

さらにテストを行っているときに、その特定のノードモジュール（ng2-datetime）のコード内インポートと使用をコメントアウトしようとしましたが、エラーはなくなりました。 したがって、シンボリックリンクに関係なく、エラーが表示されるのは、そのノードモジュールをインポートしようとしたときだけです。

GitHubでそのパッケージのソースを見ると、package.jsonファイルの「main」パラメーターが「ng2-datetime.js」に設定されていることがわかりますが、作成者も同じ.tsファイルを公開しています。名前。 これが問題の原因のようです。 .d.tsファイルを作成して.tsファイルを削除すると、問題は解決します。 シンボリックリンクを追加し直しても問題なくコンパイルされました。

したがって、すべての点で、この問題がシンボリックリンクに具体的にどのように関連しているのかわかりません。 作成者がパッケージに.tsファイルを含めると、一般的に問題が発生するようです。

これに対する回避策があるかどうか知っていますか？ 上記のOPは、tsconfig.jsonに「exclude」を追加して回避したと述べています。 私はすでにディレクトリを除外していますが、それでもコンパイルしようとしています。

これに対する回避策があるかどうか知っていますか？ 上記のOPは、tsconfig.jsonに「exclude」を追加して回避したと述べています。 私はすでにディレクトリを除外していますが、それでもコンパイルしようとしています。

これは別のものに関連しているかもしれませんが、私は今それを見つけることができません。 型を解決するとき、 tsc常にnode_modulesから検索しようとしますが、そこにはありません（ typings関連します）。

「tscはrootDir外のtsファイルを気にせず失敗するべきではありません」私は同意します。

typescriptがrootDirの外部のJSファイルを参照する理由を
エラーメッセージに「 'rootDir'にはすべてのソースファイルが含まれていると予想されます」と表示されます。TSに関する限り、そのディレクトリの外側にあるものはすべてソースファイルであると想定または想定しないでください。

これが「意図したとおりに機能する」場合、この動作の意図または動機は正確には何ですか？ TSがrootDirの外部にあるソースファイルをコンパイルしたい場合はありますか？

一方、tsconfigに「include」セクションを追加すると問題が解決します。 含めるファイルまたはディレクトリが提供されている場合、TSはそれ以外の他のファイルを調べません。

タイプスクリプト1.8.10

ホームディレクトリ~/node_modules node_modulesフォルダーがありました。 プロジェクトディレクトリ~/projects/myProject/からtscを実行すると、typescriptが次のファイルについて文句を言います。

../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/config.d.ts(29,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(36,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(68,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(75,111): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/request.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/services/glacier.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.

非常に紛らわしいです-そもそもなぜホームディレクトリにノードモジュールフォルダがあったのかはわかりませんが。

@iwllyuは、 [email protected]プロジェクトを確認し、それでも問題が解決しない場合は新しい問題を提出できます。

別のファイルセットについて不平を言っていますが、2.1.4にはまだ問題があります

Using tsc v1.8.10
../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(27,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(34,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(66,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(73,111): error TS1110: Type expected.

Using tsc v2.1.4
../../node_modules/aws-sdk/lib/config.d.ts(38,37): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/request.d.ts(164,16): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/s3/managed_upload.d.ts(15,16): error TS2304: Cannot find name 'Promise'.

テストケースを分離するプロジェクトを作成します

さて、私は新しいプロジェクトで試しましたが、それは起こりませんでした。 これは古いプロジェクトであり、余分なnode_modulesフォルダーを削除して既に修正しているので、これ以上時間をかけて再作成する必要はありません。 助けてくれてありがとう！

この場合について。 インポートするのが外部からのタイプ（この「フロントタイプスクリプト、バックタイプスクリプト」の波のことを実際にサーフィンしているようなもの）だけの場合、おそらくtscは私が行っていることを区別できますか？
バックエンドからフロントエンドアプリケーションまで、エンティティの種類だけを共有しています。 もちろん、これらのクラスの型とインポートを含まない出力（コンパイル時とインテリセンスにのみ使用されるため）。

これもありました。
Typescriptは私たちのチームにとって制約が大きすぎます-今フローを考えています。

みんな、これに関する解決策はありますか？ バックエンドコード内などでクライアントコードの型を使用する。

最良の選択肢は何ですか？ コピー-あちこちに貼り付けて、タイプを変更した場合は変更しますか？

2つのプロジェクトに対して1つのルートディレクトリを作成することはオプションではありません。なぜなら、バックエンドのtsconfig.jsonがjsxに関する情報を持ち、es2015を使用できるときにcommonjsにコンパイルされるからです。

baseUrlはあなたのために働きますか？

@unionalは

import * as request from "superagent";

しかし

import * as request from "node_modules/superagent/..something";

？

ブレ、これは本当に意図したとおりに機能していますか？ 私はちょうどこれに遭遇しました、私は私のソースがすべて特定のフォルダにあることをtypescriptに伝えました（ rootDir経由）そしてそれから私はたまたま.ts単一のファイルを持っていたので_私が言ったことを完全に無視しました_そのフォルダの外にある

これは本当にエラーのように感じます。コンパイラにソースがrootDir経由でどこにあるかを伝えた場合、その設定を完全に無視して出力フォルダ構造を変更するべきではありません。何か間違ったことをしたと思われるからです。 rootDirないファイルはすべて無視する必要があります。 または、ハードフェイルする必要があります。目的の出力フォルダー構造とまったく一致しない出力を出力し続けないでください。

私の後に来る人のために、以下はあなたが_実際に_望むことをするでしょう：

{
    "compilerOptions": {
        "outDir": "./output",
        "rootDir": "./source",
    },
    "include": [
        "source"
    ]
}

私のソースはすべて特定のフォルダーにあるとtypescriptに伝えました（rootDir経由）

これはrootDir意味ではありません！ rootDirは、「このフォルダをoutDirのパスを計算するための相対的な基準として使用する」ことを意味します。 どのファイルがコンパイルの一部であるかは、 filesおよび/またはinclude / excludeによって回答される別の質問です。

私がそれを受け入れたとしても、現在の振る舞いはまだエラーIMOにあります。 指定されたディレクトリの外にTSファイルがある場合、 rootDirはoutDirのパスを計算するための基礎にはなりません。つまり、指定した構成は完全に無視されます。

コンパイラーは私が無効な構成を与えたと効果的に考えるので、ハードフェイルの方がはるかに良いと思います。 無効なときに構成を無視することは、（IMO）このクラスの障害を処理する正しい方法ではありません。

（ハード障害とともに）はるかに明確なエラーメッセージの例：

TSCはrootDirの外部にtypescriptファイルを検出したため、コンパイルを続行できません。 rootDirを変更して、すべてのtypescriptファイルを含めるか、rootDirの外部のファイルを除外するか、rootDirの内部のファイルのみを含めます。

注：rootDirの現在の動作が非常に間違っていると感じる理由の大部分は、rootDirの外部にファイルを置くことが意味をなさないためです。 自分自身（またはコンパイラ）にrootDirの外でファイルをコンパイルすることはどういう意味かと尋ねると、唯一の答えは「意味がない」です。 したがって、rootDirはsourceDirも指定するという自然な結論に達します。

悪は命名にあります。 それは本当にrelativePathBaseDirまたはそのようなものを意味します。

また、 includeは通常「ここも見てください」を意味しますが、この場合は「ここだけを見てください」を意味していることにも気づきました。
私はそれが別の名前を持ち、義務的であることが賢明でしょう。

IMOこのコメントは、これが実際にバグであり、そのように再度開く必要があることを確認するために、特に考慮に入れる必要があります。

注：rootDirの現在の動作が非常に間違っていると感じる理由の大部分は、rootDirの外部にファイルを置くことが意味をなさないためです。 自分自身（またはコンパイラ）にrootDirの外でファイルをコンパイルすることはどういう意味かと尋ねると、唯一の答えは「意味がない」です。

確かに、それは意味がありません。 「 rootDir外のソースファイル」は、ファイル拡張子や内容に関係なく、単にはありません。 コンパイラがそれらをコンパイルすることはありません。 では、なぜ彼は彼らの存在について不平を言うのでしょうか？ 彼は自分の支配下にないファイルがあることに嫉妬していますか？

これがバグであることに+100（実際には厄介なもの）。 次のディレクトリ構造を検討してください。

- src/
  - module.ts
- test/
  - module.test.ts
- out/
  - module.js

ts-nodeテストを実行するので、 tsc srcのみをコンパイルしたいと思います。 rootDir: 'src'があると、現在コンパイルエラーが発生します。 ts-nodeのみ実行する予定のテストやその他のものを「除外」としてマークすると（または個別にコンパイルすることもできますか？）、悪いことが起こり始めます（たとえば

実際、 rootDir 、 excluded 、およびその他すべてのオプションの組み合わせがすべての要件を満たしているわけではありません（テストを実行して操作できる状態で、コンパイルからテストを除外します）。

そして、私のユースケースは本当にユニークだとは思わないので、少なくともUXの観点から、「意図したとおりに機能する」ラベルを再検討する価値があります。

src / test / outセットアップは、プロジェクトの参照によって対処された重要なシナリオでした

rootDirを設定した後、typescriptがwebpack.config.jsファイルをコンパイルしようとした理由をグーグルで調べていたため、この問題が見つかりました。

私のソースはすべて特定のフォルダーにあるとtypescriptに伝えました（rootDir経由）

これはrootDirの意味ではありません！ rootDirは、「outDir内のパスを計算するための相対的な基礎としてこのフォルダーを使用する」ことを意味します。 どのファイルがコンパイルの一部であるかは、ファイルによって回答されたり、包含/除外されたりする別の質問です。

これが答えです！ rootDirのドキュメントによると

入力ファイルのルートディレクトリを指定します

これは「入力_ソース_ファイル」を意味すると解釈しました。 @RyanCavanaughのコメントが、このオプションの現在の説明を置き換えることをお勧めします。

ここにリンクする-https：//github.com/Microsoft/TypeScript/issues/11299はこの問題の複製です。 （解決策：include / excludeを使用してコンパイルするファイルを指定します。rootDirはコンパイルするファイルを指定しません。）

@mhegazyこの効果にそのスレッドに関するコメントを追加しますか？ これは、質問者が言及しているもののようです（TSがRootDirの外部のファイルを参照している理由について混乱しており、rootDirの意味と同じ誤解があります）。

私もこの問題に直面していて、それを解決することができませんでした。

tscコンパイルは、ツリーをインクルードされたディレクトリから親フォルダに移動し、重複タイプエラーを引き起こします。

私は次のようなネストされたフォルダ構造を持っています：

└─src
└─package.json
└─node_modules
└─tsconfig.json
└─example
│ └─src
│ └─package.json
│ └─node_modules
│ └─tsconfig.json

サンプルディレクトリ内からtscを実行しようとすると、次のエラーが発生します。

node_modules/@types/react/index.d.ts:2809:14 - error TS2300: Duplicate identifier 'LibraryManagedAttributes'.

2809         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                  ~~~~~~~~~~~~~~~~~~~~~~~~

  ../node_modules/@types/react/index.d.ts:2814:14
    2814         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                      ~~~~~~~~~~~~~~~~~~~~~~~~
    'LibraryManagedAttributes' was also declared here.

エラーからわかるように、tscはツリーを上に移動してサンプルフォルダーから出て、親ディレクトリのnode_modulesフォルダーを調べています。 さらに悪いと感じるのは、親のnode_modulesディレクトリを明示的に無視しようとしてもほとんど効果がないことです。

例のディレクトリのtsconfigは次のとおりです。

{
  "compilerOptions": {
    "target": "es5",
    "experimentalDecorators": true,
    "module": "commonjs",
    "sourceMap": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "moduleResolution": "node",
    "lib": ["es2017", "dom"],
    "jsx": "react"
  }
,
  "typeRoots": [
    "./node_modules/@types"
  ],
  "include": [
    "src"
  ],
  "exclude": [
    "node_modules",
    "../node_modules"
  ]
}

この問題を解決するにはどうすればよいですか？ 上記のどれも私にはうまくいかないようです

@lexwebb同じ問題が発生しました。 yarn.lockファイルで@types/reactバージョンが同じであることを確認してください。
https://stackoverflow.com/questions/52399839/typescript-duplicate-identifier-librarymanagedattributesを参照して

アセットフォルダに拡張子.ts 「MPEGトランスポートストリーム」ビデオファイルが含まれているため、ここにアクセスしました。そのため、フォルダがrootDirパスになくても、tscがクラッシュしました😄

excludeパスにアセットフォルダーを追加して修正しましたが、邪魔な動作でした🤔

したがって、親パッケージと子パッケージの両方で、これまでにないわずかに異なるバージョンのreactがあったことがわかりました。 バージョンを一致させると、問題が完全に解消されました。 それでも、タイプチェックから親ディレクトリを除外できないという苦痛があります。

これは決して修正されることはないと思います。 同じ問題が発生しました。 これが「意図したとおりに機能する」方法は私を超えています。 コンパイラを無意味な方法で実行させることが意図されていたと思います。

私自身の個人的な経験から、typescriptビルドがrootDirツリーから外れて、予期しないものをビルドしようとする理由は、（意図的または不注意に）直接的または間接的にその中の何かを参照したという事実です。 rootDir内からの領域。 これを行うと、参照ファイルを含む領域を除外しようとしたかどうかに関係なく、ビルドは参照ツリーに従います。 時々それはあなたがそれをどのように/どこで行ったかを見つけようとしているPITAかもしれません-しかし常に私はそれが私自身のせいであると思います- tscせいではありません。 それは私がそうするように言ったことをしているだけです。

これが私を襲うときはいつでも、それはタイプのせいです。 何か他のものをインポートするファイルに存在する何かをインポートするファイルに存在するインターフェースまたは何かをインポートします......最終的にrootDir外のファイルに存在する何かをインポートすることになります設定で明示的に除外しようとしていることがよくあります。

あなたの一部はあなたの痛みの根源に到達します。 設定の量がそれからあなたを取り除くことはありません-あなたはあなたのインポート構造の厳密な制御を維持する必要があるだけです。

@kpturnerそれは非常に合理的に聞こえますが、クロスフォルダーのインポートがない

本当に？ 私が見たことがないこと:)

除外されたフォルダは、私がほのめかしている状況が存在する場合を除いて、すべてのプロジェクトで常に除外されます。

このスレッドに必要最低限​​の例はありますか？ 私の電話から見分けるのは難しい。

申し訳ありませんが、除外は私が言及する「裸の骨」の状況の一部ではありません。 インポートが動作の原因ではないように見えることに注意してください（ただし、そうであればもっと意味があります）。

つまり、このようなものをコンパイルするとエラーが発生します。

-src / src.ts <- no imports -test / test.ts -out -tsconfig.json {"rootDir": "src", "outDir": "out"}

しかし、 tsconfig.jsonがそのように見える場合は、typescriptがsrcディレクトリ内のすべてとtestディレクトリ内のすべてをコンパイルすることを期待します。 srcものだけをトランスパイルして、 outディレクトリに出力したいだけなら、 tsconfig.jsonは

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    }
}

次に、 rootDir外部にいくつかのファイルがあるため、TS6059エラーがスローされます。 したがって、それらを除外する必要があります。

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    },
    "exclude": [
        "test"
    ]
}

これは、トランスパイルされると、 src.jsを含むsrcサブフォルダーを持つoutというフォルダーを生成します。 testフォルダーは完全に無視されます。 これは私が起こると期待することです-いいえ？

ええと、確かに、私の例tsconfigは、最初の例で示したように、 compilerOptions下にrootDirとoutDirが含まれているはずです。 testを除外すると、 testとそのファイルが除外されることも正しいです。 もともと、TS6059エラーの（または）原因はrootDirファイルであり、 rootDir外部から何かをインポートしているとおっしゃっていたと思いますが、誤解していると思います。 とにかく、あなたが説明するように、 rootDir外のディレクトリを明示的に除外しなければならないことに驚いたことで、私はここで他の人たちに同意します。

いいえ、私は（以前は）参照ツリーが除外リストにトランスパイルされる可能性があると言っていました-わずかに異なります。

TS6059エラーは、最初は少し戸惑いますが、TSがミスを防ぐのに役立っているように見えます。 rootDirを定義するのに苦労した後、plonk typescriptがそのrootDirの外に飛んだ場合、TSは事実上「oi-あなたは私が到達できないtypescriptを作成しました-そうですか？」と言っています。

「いいえ、それは正しくありません」と答えて、ファイルをrootDirに移動します。
また
「はい、その通りです。お知らせしなかったのでごめんなさい」と言い、それを除外ファイルのリストに追加します。

これはあまりにも複雑です。 私はモノレポを持っていますが、 pathsオプションを使用して（同じモノレポから）ローカルパッケージをインポートしながら、各パッケージを適切にコンパイルして正しいディレクトリ構造を出力する方法を見つけることができないようです。

出力ディレクトリのディレクトリ構造に不要な親フォルダが含まれているか、tscがファイルがルートディレクトリの外にあることについて文句を言っています。

これほど複雑になることはありませんか？

どのオプションをどの組み合わせで使用しても、 tscは、同じモノレポ内のローカルパッケージを参照するpathsモノレポを処理できないようです。 --build 、 --project 、 references 、 paths 、 extends 、 rootDir 、 rootDirs 、 include 、 exclude 、 baseUrl 、 outDirは、さまざまな値を持つあらゆる種類の組み合わせであり、最終的にはファイルがrootDir内にないことについて文句を言います。 outDir内に間違ったディレクトリ構造を出力することで失敗します。

私がモノレポとして持っているものについては説明しませんが、同じレポに3つの異なるプロジェクトがあり、問題や他の干渉なしにそれぞれを独立してトランスパイルできます。 各プロジェクトには独自のtsconfigがあります

かなりの時間を試していじくり回した使用してmonorepoを実行することができました。 typescript構成では、 referencesをpathsと組み合わせて使用​​し、 rootDir使用に支障をきたすことはありません。

rootDirは、出力フォルダー構造を構築するために使用されます。 コンパイラが出力の書き込み先を知るには、すべてのファイルがrootDirの下にある必要があります。

出力を必要としないファイルはどうですか？ ルートの外にjsonファイルがある：

const errors = require("../../../../errors.json");

ES6バージョンをコンパイルできないため：

import * as errors from "../../../../errors.json";

しかし、最初のバージョンでは、型の安全性が失われています。

@mhegazyこの問題は3年前にクローズされました。 しかし、それは3年後もまだ混乱の原因になっているようです。

この「意図したとおりに機能している」ステータスをもう一度確認してください。 このスレッドでのコミュニティの反応を考えると、コミュニティが期待どおりに動作していないと言ってではありません。 ドキュメントの問題であれ、そのオプションの名前の変更であれ、その動作の変更であれ、新しいオプションの追加であれ、実際には決定すべきアクションアイテムがあると思います。

あなたはこれよりもはるかに高い優先順位を持っていることは理解できますが、ここで与えられたフィードバックがこれまでに評価されたことを示す兆候なしにこの問題を閉じたままにしておくことは、Typescriptが正直に言うとあまり良いイメージを伝えません。

@ngryman次のステップは何ですか？ rootDirには定義があります-これは私のソースファイルの共通ルートです。 rootDir定義上、ファイルがその共通ルートにない場合、それはエラーです。 その定義は文書化されています。 人々がrootDir独自の定義を発明し、その後驚いたという事実については、私は何もできません。

これは、スターバックスに行って、ラテを頼んでもエスプレッソと蒸しミルクの混合物を手に入れるべきではないと言うようなものです。 あなたが定義について議論しているので、それは実行不可能です。 別の飲み物が必要な場合は、別のものを注文してください。 スターバックスがあなたが望む種類の飲み物を提供していない場合は、その飲み物がどうあるべきか、そしてそれが何から作られるべきかについて提案をしてください。

https://github.com/microsoft/TypeScript/issues/9858#issuecomment -370653478で述べたように、この問題の解決策は、単にエラーメッセージを改善することだと思います。 私がそれに遭遇し、最終的にこのGitHubの問題を見つけたとき、私の最大の欲求不満は、問題を理解しようとして、それがコンパイラのバグであると考え、再現ケースを作成し、そして見つけたのにどれだけの時間を無駄にしたかから来ました「意図したとおりに機能している」という重複バグ。 明確なエラーメッセージで速く失敗すれば、私はそのすべてを救うことができたでしょう。

rootDir外にソースファイルがある場合は、TypeScriptプロジェクトが正しく構成されていないことを意味します。 これを示す明確なメッセージとその修正方法のガイダンスをユーザーに提供することで、多くの人にとって問題が解決すると思います。

@RyanCavanaugh迅速な回答ありがとうございます。

このページにアクセスした場合： https ：

入力ファイルのルートディレクトリを指定します。 --outDirを使用して出力ディレクトリ構造を制御するためにのみ使用します。

私はそれが「出力ディレクトリ構造を制御する唯一の使用」が重要です。 どのように私もそれはコンパイラが実際にやっているだけではないのですが、私は活字体は、そのディレクトリの外にファイルがある場合、それはまた、エラーを放出することを推測できました。

何かが足りないのかもしれませんが、そうだとすれば、私だけではありません。 したがって、製品を持っていて、かなりの数のユーザーが製品を理解していない場合、2つの方法しかありません。ユーザーを愚かだと考えるか、何かを明確に伝えられなかったかのどちらかです。 私はあなたが最初に傾いていないことを願っています😕

スターバックスの例を終えるには、材料リストに「エスプレッソと蒸しミルクの混合物」とよく書いてください。そうすれば、ラテが何であるかがわかり、推測する必要はありません。

rootDir外にあるファイルの意味は、TSがoutDir外にファイルを出力するということです。これは、明らかに悪い動作だと思います。

エラーメッセージの方が良いかもしれません-そのための提案やPRが欲しいです。

ドキュメントは常に優れている可能性があります-繰り返しになりますが、物事をより明確に伝える方法についての具体的なアイデアが大好きです。

私が人々を愚かだと呼んでいるとほのめかすことは、私がこれ以上望んでいることではありません。

rootDirの外部にあるファイルの意味は、TSがoutDirの外部にファイルを出力することです。これは、明らかに悪い動作だと思います。

コンパイラがrootDir 「chroot」するだけでなく、そのディレクトリ外のファイルを考慮しない理由については、まだよくわかりません。 ユーザーとして、おそらくtsc内部と履歴に関するコンテキストが不足しているため、これは私にとって予測可能な動作ではありません。

私が頭から出すことができる1つの例は、同じオプションを提供するJestです： https ：//jestjs.io/docs/en/configuration#rootdir-string。 AFAIK Jestは、 rootDir以外のテストファイルを考慮しません。 たとえば、ここでも同じ動作が期待されます。

ドキュメントは常に優れている可能性があります-繰り返しになりますが、物事をより明確に伝える方法についての具体的なアイデアが大好きです。

ここで改善を検討していただき、ありがとうございます。 @MicahZoltuの提案は、かもしれません。

私の側では、 rootDirは予測可能ではないと言い換えることができますが（したがって、人々の反応）、私が理解しているように、そのオプションの動作を変更することは考慮すべきことではありません。 したがって、妥協案として、 rootDir名前をより意味のある名前に変更することも提案できます。 outBaseDirが候補になる可能性があります。 しかし、おそらくもっと良い名前があるでしょう。

私が人々を愚かだと呼んでいるとほのめかすことは、私がこれ以上望んでいることではありません。

私は何もほのめかしませんでした、そしてあなたがそれをそのようにしたならばすみません。 私は非常に単純な事実だけを述べました。ユーザーが理解できないことについて不平を言うとき、実際には2つの道しかありません。 私はあなたが最初のものに傾いていないことを願っていると結論付けました。 あなたがこれらの道の1つにあなた自身を関連付けるという事実はあなたに正直に任されています。

特にこのスレッドがどのように処理されたかについて率直なフィードバックを与えることに関して、私が言わなければならなかったことを言ったと思います。 だから私は他の人が解決策を提案する余地を残しておきます。

@ngryman rootDirの定義とそれが実際に行っていることは一致していないように見えることに同意します。 あなたは（経由新しいTSプロジェクトを作成するとtsc --initでのコメント） tsconfig.jsonについてrootDirあなたが引用されたものと同様である/* Specify the root directory of input files. Use to control the output directory structure with --outDir. */ 。 _input_ファイルのディレクトリを提供する場合、入力の定義により、コンパイルを検討するのはそのディレクトリだけであると思います。

@RyanCavanaugh typescriptがjavascriptにコンパイルされるためだけに使用されていたとき、4年前にこのようなエラーを報告することは理にかなっているかもしれません。 もちろん、ファイルが不足することは望ましくありません。 しかし、 ts-nodeようなタイプスクリプト実行の人気により、tscは私にとって少し嫉妬しているようです。

そして、 rootDir外にあるtypescriptファイルが間違ったプロジェクト構成を意味するという考えは、単に間違っています。 typescriptで記述されたユニットテストをjavascriptにコンパイルする必要はありません。 ts-nodeは単純に高速で、テストを作成するときにtypescriptのすべての利点を享受できます。

@CodySchrankに同意し

ただし、TypeScript自体が、rootDirの外部にある無関係なファイルを調べてエラーを発生させることは理解できませんが、それらはjestなどのさまざまなツールの構成ファイルにすぎません。 つまり、ポイントは何ですか？ これらは私のアプリケーションの一部ではなく、どこにも直接参照/インポートされていません。私の神様、そもそも結果のビルドにバンドルしてほしいのはなぜですか...

このエラーを警告に変えることの意味は何でしょうか。 コードを簡単にざっと見てみると、確かに可能だと思われますが、私はtscビルドプロセスの専門家ではありません。 潜在的な問題について通知を受け取ることと、必要に応じてそれを回避することの間の幸せな媒体のようです。

src / test / outセットアップは、プロジェクトの参照によって対処された重要なシナリオでした

これには、ルートフォルダーごとに少なくとも個別のプロジェクト構成が必要です（https://www.typescriptlang.org/docs/handbook/project-references.html）。 説明書を読んだのですが、パターンの実装方法がよくわからず、手持ち削岩機を渡されたような気がします。

確かに、付属モジュールをソースフォルダー内の個別のサブプロジェクトとして維持する方が効率的ですが、ここではlodashをコンパイルしていません。 私が欲しいのは、静的分析用の共通のプロジェクトフォルダーの下に、テストファイルやベンチマークファイルなどの多くのファイルを含め、コンパイルするときに、外部で使用するために1つのディレクトリのみを出力することです。 これは指定するのに十分簡単なようで、ユーザーが行うのが難しいだけでなく、TS仕様の観点から明らかに_verboten_である理由を理解するのに苦労しています。

私が強調したいのは、この機能が許可されない唯一の理由は、開発者側の腐敗した意図をコンパイラが想定しているためであるということです。 開発者が"outDir"を./srcし、コンパイラが./testでTSファイルを見つけた場合、このファイルを発行する必要はないと想定できます（もちろん、 「outDir」内のどのファイルからも参照されていません）。

しかし、そうではありません。 開発者がこのファイルを発行することを_望んでいた_ことを前提としており、無能または悪意により、それを含まないサブディレクトリを指定しました。 言い換えれば、コンパイラーは、開発者の指示を一般的で合理的なユースケースに一致させる機会があり、代わりにそれを不条理なものに一致させ、続行を拒否します。

現状では、 "outDir"の正当なユースケースが何であるかさえわかりません。 tsconfig.jsonが他の構成ファイルやメタデータファイルとともに最上位にあるプロジェクト構造をサポートすることを想定しており、所有者はコンパイルされたフォルダーがその中にネストされたソースフォルダーのみを表すことを望んでいます。 （これらのメタファイルのいずれも.ts終わっていないことを確認してください：それはばかげているでしょう。）

スペックのデザインはユーザーに敵対的であるように私には思えます。 メニューに材料が記載されているにもかかわらず、スターバックスで飲み物を注文し、それが期待したものではなかったときに動揺しているという言及がありました。 これは、それに関しては適切ですが、私はこの機能を、ホットドッグを販売していないホットドッグスタンドにもっと例えたいと思います。

確かに、イライラした顧客は戻って、ホットドッグスタンドがホットドッグを販売していないことを大胆に宣言する大きな看板を見たはずです。 しかし、混乱が蓄積するにつれて、ホットドッグスタンドの所有者が、製品の機能を顧客にどのように伝えているかを考える機会があるかもしれません。

うーん、これをもっと考えると、この問題の根底にあるコアチームの側にある種の不変条件があるのではないかと思います。

すべてのソースコードをコンパイルする必要があります。 コンパイルされていない場合、それはソースコードではありません。

ユーザーランドでは、どうにかしてこれを乗り越える必要があります。 ソースコードの定義を拡張してこれを行うかどうかはわかりません。 TypeScript、または2番目のカテゴリ（「サポートコード」、「検証コード」、「周辺コード」...）を作成します。 これは、ソースと同じ型定義の下で動作することが期待され、ソースが正しいと見なされるために正常に検証する必要があるコードですが、そのインターフェイスに関するプログラムの実際の機能の一部ではありません。

TypeScriptの消費者として、私はそのようなカテゴリーを実装することの特定の難しさを理解していません。 ただし、 "outDir"ぴったり収まるようです。 "outDir"内のすべてがソースの一部であり、その外部以外のプロジェクトフォルダー内のすべてがサポートコードの一部です。 これを便利/必要にする主なものはts-nodeの出現です。これは、コンパイルとは完全に独立して、このサポートコードを別のステップとして実行できることを意味します。 もちろん、それを利用できるようにしたいと思います。

ツールに提供される入力ファイルが暗黙的に含まれていません

この問題は、ユーザーがrootDir外部でファイルを暗黙的にコンパイルしようとしているために発生します。 基本的に、コンパイラに「このディレクトリ内のファイルのみをコンパイルする」と伝えてから、そのディレクトリ外のファイルを参照しました。 コンパイラは混乱していて、続行する方法がわかりません。

/project/source/index.ts

import '../external.ts'

/project/tsconfig.json

{
  "compilerOptions": {
    "rootDir": "./source"
  }
}

この例では、コンパイラに「ソースファイルは「ソース」ディレクトリにのみ存在する」と伝えます。 次に、それらのファイルの1つが、ソースディレクトリに_ない_ファイルを参照します。 TypeScriptには、2つの競合する命令があります。1つはソースディレクトリ内のファイルのみをコンパイルするように指示し、もう1つはソースディレクトリ外のファイルをコンパイルするように指示します。

@MattiasMartensは、暗黙的にincludeとrootDir混同しています。 /srcと/testがある場合、 includeがsrc/*場合、 /test 、 srcがtestから何かを誤ってインポートしましたが、これは喜ばしいことです。

プログラム内の誤ったインポートがどのように見えるかを書き留めるためのメカニズムを提供し、そのような誤ったインポートが発生したときにエラーを発行することは、ユーザーに対して敵対的または敵対的ではありません。 繰り返しになりますが、これはフラグの意味を誤解している場所から来ていると思います。フラグは主に、プログラムが正しく構成されていることを検証するのに役立つオプトイン強制チェックです。

ともかく！

rootDirの定義を考えると、TypeScriptが提供されたrootDir外にあるファイルを見ると、いくつかのオプションがあります。

• outDir上にファイルを出力します（これが可能であると仮定します！）。これは、出力場所に関するユーザーの指示と矛盾します。
• ファイルを処理しますが、出力しないでください。他のビルド手順がないと、プログラムが機能しなくなります。
• プロジェクトが正しく構成されていないように見えるため、エラーを発行します

私は、動作しないプログラムを出力することがデフォルトであるべきだという考えに強く反対します。 ここでの機能リクエストが単にrootDir外部にある.tsファイルを.d.tsとして扱うことである場合、それは合理的です。これはrootDir意味とは別のものです。 rootDir以外のもの。 あなたはそのような旗を何と呼びますか？

@MattiasMartensは、暗黙的にincludeとrootDir混同しています。 /srcと/testがある場合、 includeがsrc/*場合、 /test 、 srcがtestから何かを誤ってインポートしましたが、これは喜ばしいことです。

それは本当だ。 私はincludeをいじくり回しましたが、VSCodeのツールを含め、このケースで思っていたよりもうまく機能することがわかりました。

コンパイル時に検証され、コンパイル時に出力includeではカバーされていません。 しかし、それはここで議論する必要のない別の要求です。

これは、フラグが何を意味するのかを誤解している場所から来ていると思います。フラグは主に、プログラムが正しく構成されていることを検証するのに役立つ_オプトイン強制チェック_です。

私はこれに混乱しています。 rootDirをオプトイン施行チェックと見なしますか？ それは最終的に放出されるものに影響を与えるので、それは明らかに強制チェックだけではありません。

targetようないくつかのフラグは、出力されるものを大幅に変更します。これらは強制チェックではなく、コンパイラー命令です。 rootDirは、コンパイラ命令のように読み取られ、そのように文書化されています。

私は、_動作しないプログラムを出力する_をデフォルトにするべきであるという考えに強く反対します。

私がこれまでこのスレッドについて読んだことから、 rootDir内のファイルからrootDir外のファイル任意のTSファイルを見つけた場合、実際にエラーがスローされますということですrootDir内のファイルかどうかrootDirはそれらをインポートするかどうか。

繰り返しになります。ソースコードが存在するフォルダーにrootDirを設定すると、コンパイラーはプロジェクト内の他のTSコードに気づき、 rootDir内容とは関係がこの特定の動作は、コードを理解するのに役立ちません。 それは単に迷惑です。

このスレッドで詳しく説明されているように、 rootDirのTypeScript定義の観点からは、動作は完全に合理的であり、それについての不満を表明するためにここに来たすべての人は誤りです。 しかし、ルートディレクトリの従来の予想される定義からは合理的ではありません。 私がルートディレクトリを提供する事実上すべてのコンテキストで、ファイルシステムに他に何かがないことが絶対に確実かどうかを尋ねるのではなく、ファイル構造のトラバースを開始する場所をプログラムに指示していることをお伝えします。に興味がある。

定義が間違っている可能性があります。 それらは変更することができます。 下位互換性のために、定義を保持する必要はなく、機能のみを保持する必要があります。

ここでの機能要求が単にrootDir外部で見つかった.tsファイルを.d.tsとして扱うことである場合

rootDir内の何かがコードを外部からインポートしたときにコンパイラーにエラーをスローさせたいのとほぼ同じ理由で、私はそれを望んでいないと思います。 rootDirを提供する場合、その内容は周囲のコードからカプセル化する必要があると思います。

私や他の人が望まない動作を回避する最も簡単な方法は、 rootDir内のファイルがそれらを参照していない場合、 rootDir外のファイルを暗黙的に除外することだと思います。 内のファイルならばrootDirそれらを参照くださいそれが現在であるとして、エラーがスローされなければなりません。

そこにあるすべての段落は、「 rootDirはデフォルト値のinclude rootDirを変更する必要があります」に要約されているようです。これは、今日これらのフラグを同時に追加する場合に提案するのが妥当ですが、現時点で行うことができる画期的な変更ではありません。 間違いなくお互いがより高くなる認知的負荷と対話するすべての設定フラグを作るのではなく、それを減少させるけれども。

includeが明示的に設定されておらず、含まれているファイルがrootDir外にある場合include 、カスタムエラーを発行する必要があるかもしれません。

ファイル "tests /foo.ts"はrootDir'src 'の外にあります。 「インクルード」パターンを設定するのを忘れましたか？

ログに記録された＃33515

https://github.com/microsoft/TypeScript/issues/31757#event -2480427393でも、これに問題がありました

rootDir、include、excludeの相互作用は、非常に奇妙に設計されています。

rootDirはコンパイラーがトラバースを開始するフォルダーであり、rootDirから参照される可能性のある追加のフォルダー（ベンダーフォルダーなど）が含まれていると常に思っていました。

現在の定義は地獄のように奇妙で、非常に直感的ではありません。

皮肉なことに、紛らわしいのは、それらが相互作用includeは、プログラムの内容を100％制御し、 rootDirは、 outDirレイアウトの計算を100％制御します。

問題の別の例を追加するために、これは私のフォルダ構造です：

tsconfig.json
package.json
src/index.ts

tsconfigに次のものがあります。

"rootDir": "src",
"outDir": "lib",

そして私の「index.ts」（srcフォルダー）

import pkg from '../package.json'; // I read the package.json object

export class SomeClass {
  public version = pkg.version;
}

ビルド後、「index.js」ファイルが「lib」フォルダー内にあることを私は_知っています_。 そして、package.jsonが1レベル上になることを私は_知っています_。
Typescriptが私のフォルダ構造を私よりよく知っていて、ビルドを壊すべきだとは思いません。 出力フォルダーに含まれていなかったrootDirフォルダー外のいくつかのファイルに関する警告を単にログに記録する必要があります。

@sebelgaおそらくバグだと思います-TSが出力フォルダにコピーしないのでrootDir外部から.jsonを許可することは問題ありません

@sebelgaおそらくバグだと思います-TSは出力フォルダーにコピーしないので、rootDirの外部から.jsonを許可しても問題ありません

真実ではありません。.jsonファイルを発行するための特別なルールがいくつかあります...ファイルがそれ自体で同じ場所で発行される場合、それだけが発行されません。 すべての場合に発行されます（たとえば、-outDirが指定されている場合、そのフォルダーに発行されます）

私は私がしたい@sebelgaに似たユースケース持って@RyanCavanaugh console.logからバージョン番号package.json実行時にします。

だから私の解決策は私の"rootDir": "."を変更すること

"include": [
    "src",
    "typings"
  ]

また、 package.jsonファイルは「src」サブフォルダーを含むlib （ビルド済み）フォルダーに含まれているため、ビルドの直後に実行してクリーンアップするbashスクリプトを作成しました。

#!/bin/bash

rm lib/package.json
mv $(pwd)/lib/src/* $(pwd)/lib
rm -rf lib/src

それは機能しますが、私にはかなりハッキーな感じがします。

@sebelga typingsフォルダに.tsファイルがありますか？ そうでない場合は、 rootDirをsrcし、スクリプトをスキップすることが合法です。

@sebelga const { version } require('../../package.json')またはimport { version } from 'package.json')代わりに、次のようなことを試しましたか？

import { sync as loadJsonFileSync } from 'load-json-file';

const { version } = loadJsonFileSync('../../package.json');

TypeScriptは、このようにrootDir外にあることを気にしません。

https://github.com/sindresorhus/load-json-file

すべての../..をハードコーディングすることを避けたい場合は、これを試すことができます。
https://github.com/sindresorhus/read-pkg-up

@RyanCavanaugh上記のように「src」に設定できません。 src（ import pkg from '../package.json'; ）の外に「package.json」をインポートしていますが、tscではそれが許可されていません。

この@dylangを共有してくれてありがとう！ やってみます。

私のソースはすべて特定のフォルダーにあるとtypescriptに伝えました（rootDir経由）

これはrootDir意味ではありません！ rootDirは、「このフォルダをoutDirのパスを計算するための相対的な基準として使用する」ことを意味します。 _どのファイルがコンパイルの一部であるか_は、 filesおよび/またはinclude / excludeによって回答される別の質問です。

@RyanCavanaughしかし、それはrootDirが意味するものであり、これがこの問題の目的です。

新しい「compilerOption」を導入してエラーを無視できることをコンパイラに通知することで、既存のユーザーに新しい問題を導入せずに非常に修正できる可能性のある、2016年以降に開かれている問題を見つけたとき、私は落ち着きを保つのが苦手です。特定のユースケースで。

このため、私はお詫び申し上げます。 私は良いサービスを提供することに頼っているので、私はそれを助けることができません、それでも私は時々このような問題のスレッドに遭遇します。 TypeScriptの作成者が1つの単純な構成フラグを実装するのが非常に難しいのはなぜですか？

開発者が怠け者であるからか、彼らが助けたがらないからだとは思いません。 私を除いて、ここの誰もが悪い人だとは思いません。

プロパティ「rootDir」の定義と思われるものをめぐって何年にもわたって続いてきたのは、この対立、この議論です。 そして、この問題について何をすべきか。

彼らは自分たちが正しいと信じているので、人々はこの議論に投げ込まれます。 はい、「rootDir」はソースコードのベースディレクトリとして機能します。 はい、エラーは有効です。

それでも、根本的な問題はまだ残っています。 私のツールはコードを完全にコンパイルしますが、IDEはこのエラーを画面に表示します。 それは倒錯です。 私はそれらの赤い線を消したい。 私のファイルにはエラーがありません。 もしそうなら、私はこれらの非問題に気を取られるのではなく、それらに焦点を当てるべきです。

私が欲しいのは、このエラーメッセージを抑制することだけです。 それが私たちのほとんどが望んでいることだと思います。 ここに他のケースがあるかどうかはわかりませんが、それについて話したい人がいるかもしれません。

一緒に働いてこの問題を解決していただけませんか？ それらの赤い線が消えるのを見るのはとても幸せです...

@nullquery tsc機能するが、IDEに赤い波線が表示されている場合は、IDEがtscと同じコンパイラバージョンまたは構成を使用していないことを意味します。

@nullqueryは、問題を再現する方法を示すバグをファイルします。問題を修正するか、プロジェクト構成の何が問題になっているのかをお知らせします。

@sebelgaの回避策に続いて、npmスクリプト内に入るのに適したバリエーションを

tsc --module commonjs --target ESNext --outDir ./edition-esnext --project tsconfig.json && test -d edition-esnext/source && ( mv edition-esnext/source edition-temp && rm -Rf edition-esnext && mv edition-temp edition-esnext ) || true

ここでの使用例。

境界は自動的にそれを適用します。

解決策はプロジェクトリファレンスです。

これを使用するには、「tsconfig.json」ファイルを編集し、これをファイルの最後（「compilerOptions」の外）に追加します。

"references": [
    { "path": "../common" }
]

これにより、「../ common /」フォルダー（およびすべてのサブフォルダー）内のファイルを参照できるようになります。

以前の混乱は、IntelliJと汚染されていないgulp-typescriptタスクが、同じ「tsconfig.json」ファイルを使用しているにもかかわらず、異なる結果をもたらしていたという事実に起因していました。

何らかの理由で、「gulp-typescript」はコンパイルにベストエフォートのアプローチを試みていることが判明しました。

TypeScriptのエラー（ let z: number = '' ）はIntelliJでフラグが付けられますが、「gulp-typescript」は問題なくコンパイルします。
JavaScript構文エラー（ let 1z = '' ）のみが「gulp-typescript」によってフラグが付けられます。

したがって、「gulp-typescript」ユーザーの場合、「gulp-typescript」のバージョンと構成によっては、このような問題が発生する可能性があります。 （執筆時点では最新バージョンを使用していますが、将来の誰かがこれを読んでいる可能性があると思います。あなたにとってより良い時代になることを願っています。）

プロジェクト参照の使用がこの応答の雪崩のどこかに埋もれていることは知っていますが、これがより適切に文書化されていればもっと良かったでしょう。

Googleでの「TS6059」の上位3つの結果はすべて、GitHubの問題につながります。 これらの一般的なエラーとその解決策を文書化したページがあれば、私にははるかに明確だったでしょう。

@MicahZoltuこれは対処できるものですか？ 私は新しい問題を作成する必要がありますか、それとも主要な貢献者の間で内部的に議論された場合、これはより速く進むものですか？

（FWIW私はTypeScriptチームの一員ではありません）

一般的に、どうしても必要な場合を除いて、 pathを使用しないことをお勧めします。 その目的は、奇妙な依存関係構造を持つレガシーJSプロジェクトとの互換性を可能にすることだと思いますが、新しいプロジェクトで使用することを意図しているとは思いません。必要な場合は、次の場合に移行することを検討してください。あなたには機会があります。 私は個人的には使っていないので、あなたが抱えている問題を解決することはできませんが、多くの人が苦労しているのを見て、解決策は通常「使うのをやめる」ことです。

gulp-typescriptに関しては、おそらくgulp-typescriptで使用されているTSCのバージョンがIntelliJで使用されているTSCのバージョンとは異なるようです。 あなたが説明するような症状が見られる場合、それは通常問題です（もうtsconfig.jsonは、同じ

「gulp-typescript」で使用されるバージョンは同じである必要があります。 どちらのバージョンもnode_modulesから派生しています。 エラーのキャッチとそれに関連する設定の変更の両方をさまざまな方法で試しました（「gulp-typescript」によって提供されるさまざまな「レポーター」をいじったり、設定をオーバーライドしてエラーを増やしたりするなど）。何も機能しないようです。

でも大丈夫です。 IntelliJがエラーを表示する限り、Gulpタスクがエラーを無視することを喜んで受け入れます。

私は今週の好ましい方法を支持して私の方法をオーバーホールするのが好きではありません。 私が持っているプロジェクト構造は私には理にかなっています。 それはすべてを封じ込めたままにしますが、物事を複数のコンポーネントに分割する柔軟性を与えてくれます。

私は「レガシーの理由で互換性を許可する」こと、特にプロジェクトの参照に関しては信じていません。 rootDir外部のファイルを参照できる必要があります。そうしないと、自分とチームにとって意味のある方法でプロジェクト構造を定義する自由がなくなります。

TypeScriptを使い始めたとき、私は多くの問題に遭遇しました。 その中で：

• JavaScriptファイルを含めるための頼りになるソリューションは、当時AMDのようでした。 ウェブサイトは公式に聞こえ、AMDの実稼働環境での多くの例がオンラインでありました。 しかし、どうやらWebpackは新しい大きなものだったので、一部のプロジェクトはAMD環境では機能しませんでした。 教訓：誰もが新しい方法を採用するわけではないので、あなたはいつも困惑しています。

• TypeScriptから最終的な縮小化されたJavaScript（ソースマッピングを含む）への道のりは私にはわかりませんでした。 当時はいくつかの異なる方法が利用可能でしたが、当時は「tsconfig.json」ファイルや私のIDEでネイティブに機能するものはなかったようです。 教訓：何かを正しくやりたいのなら、自分でやらなければなりません。 他の人に仕事を任せないでください。たとえ彼らがどんなに善意を持っていても、完璧な人は誰もいませんし、誰もあなたのワークスペースを予測することはできません。

• 私が欲しかったカスタムなものが1つありました。それは、HTMLファイルのコンテンツをJavaScript辞書に変換して含める方法です。 これが私の唯一のつまずきだったはずですが、結局、これは書きやすいスクリプトの1つであることがわかりました。

私はすべてを処理するために独自のGulpfileを開発する必要がありました。 それは以下を行います：

• 縮小されたJavaScriptファイルをコピーして、 node_modulesフォルダーからWebルートに配布します。 単純に聞こえますが、私が含めようとしたほとんどすべてのJavaScriptライブラリには、縮小されたJavaScriptファイルを格納する場所が異なっていました。 構成はなく、ファイルへの明確なパスもありませんでした。 含めたいJavaScriptライブラリごとに個別のスクリプトを作成する必要がありました。 将来のバージョンで場所が変更されないと仮定すると機能しますが、変更された場合はいつでもコピースクリプトを変更できます。

• （ outDirを使用して）出力ディレクトリに個別のファイルを生成するローカルの「tsconfig.json」ファイルに従ってTypeScriptをコンパイルするため、TypeScriptがGulpと同じようにIDEでコンパイルされることを確認できます。 （hahahahaha！）次に、「rollup」プラグインを使用してこれらのファイルを単一のJavaScriptファイルに圧縮し、UglifyJSを実行してこのファイルを縮小します。その間、元のTypeScriptファイルにマップするソースマッピングを維持します。

• （カスタムタスク）TypeScriptソースルートのHTMLファイルごとにhtml_templatesという辞書を含むJavaScriptファイルを生成し、縮小されたJavaScriptファイルとしてwebrootフォルダーに配置します。

もっとエレガントな方法があるかもしれませんが、あるオープンソースプロジェクトから次のプロジェクトにジャンプした後、私はそれぞれが提供しているソリューション間を十分に行き来しました。

私が選んだアプローチはうまくいき、理解するのに十分簡単です（特に、「gulp-typescript」が何か違うことをすることを理解した今）、おそらくこれを何年も使い続けるでしょう。

最善の解決策は、自分自身を理解していることです。 これは私を助けようとする人には役立ちませんが（私は非常に感謝しています！私が意味する助け、混乱ではありません）私は経験から、_any_ソリューションには常に何か問題があるので何かに固執する方が良いと話すことができますあなたは、さまざまな信念、性的指向、性同一性の多文化チームによって設計、開発、作成されたものよりも自分自身を所有しています。

tl; drプロジェクト参照を壊さないでください。 ツールが機能するためにそれが必要です。 ありがとうございました

マルチプロジェクトTSセットアップのセットアップを適切に断念し、すべてのプロジェクトでtsc -wとnpm linkを実行するだけで、マルチプロジェクトtsconfigの複雑さをすべて無視して、他のプロジェクトを参照できます。 node_modulesのプレーンなnode.js依存関係のようなプロジェクト。

しかし、今日、あるプロジェクトでターゲットをes5からes6しましたが、 File '.../lib.ts' is not under 'rootDir'ため、コンパイルされなくなりました。

ファイル構造：

/app
 - tsconfig.json // rootDir = "."
 - app.ts (

/app/node_modules/lib
 - tsconfig.json // rootDir = "."
 - lib.ts
 - lib.js
 - lib.d.ts

/app tscが/app/node_modules/lib/lib.tsファイルを気にするのはなぜですか？ そのファイルをまったく使用しないでください。 コンパイルされた/app/node_modules/lib/lib.jsと/app/node_modules/lib/lib.d.tsます。

/app/node_modules/lib/lib.ts削除された場合（驚き）、正常にコンパイルされます。

@alexeypetrushinあなたは私のプロジェクトのいくつかを見ることができます。 正常に動作しているようです。 例えば：

• https://github.com/unional/standard-log
• https://github.com/mocktomata/mocktomata

import * as pkg from '../package.json';

いいえ。 そして、私が見つけることができるこのエラーをオフにする方法はありません。

@SephReed ：StackOverflowに200 repポイントを費やしましたが、誰かが../package.jsonをインポートするためのこのがしなければtypings.d.tsと同じディレクトリにあるファイルpackage.jsonこの内容で、：

declare module '*.json';

これがどのように機能するかはわかりませんが、正直なところ、私は気にしません。 その段階で、TSは私のためではなく、自分自身のために分岐していました。

私はこれがそのような白熱した議論であることに驚いた。 しかし、私はその理由を理解しています。 私の場合、もちろんソースフォルダーがありますが、そのフォルダーの外に、コンパイルすることを意図していないビルドスクリプトもありますが、正直なところ、最高のIntelliSenseはTypeScriptであるため、タイプサポートが含まれています。

repo/
⊢ config/  << provide TS support, but don't build this directory
  ⨽ webpack.config.ts 
⊢ scripts/  << provide TS support, but don't build this directory
  ⨽ release.ts
⊢ src/        << build this directory
  ⨽ example.ts
⨽ tsconfig.json

私が使用して"rootDir": "src"確認ファイルをに向けられている作るためにdistなくdist/src 。 もちろん、TypeScriptはこの設定について文句を言うのが好きですが、私はWebpackを使用しているので、エラーは発生しません。

私はついにこのフラグが正確に何を意味するのかを理解しましたが、それを明確にしないいくつかのコメントはありませんでした。 これで応援してください。

tscのフォルダーとファイルを設定して、コンパイルを考慮に入れるオプション： "files"、 "include"、 "exclude"。

では、「rootDir」を何に使用しますか？
rootDirは、ソースファイルへのディレクトリ構造（階層）のルートであり、tscは、tsconfig.jsonディレクトリまたは「outDir」（指定されている場合）から始まる同じディレクトリ構造を出力するために使用します。 したがって、これはtscが「outDir」のベースパスとして使用するパスではありません。 「outDir」は、tscが出力ファイルを出力するルートです。
たとえば、Javaプロジェクトがこのディレクトリ構造を持っているとしましょう。

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

「include」と「rootDir」を以下のように設定すると、tscは次のように出力を生成します。

"include": "src/main/resources/static/ts" *
"rootDir": "." *

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.js *
          test.ts

また、「outDir」を以下のように設定すると、tscは次のように出力を生成します。

"include": "src/main/resources/static/ts"
"rootDir": "."
"outDir": "build" *

- build
  - src
    - main
      - resources
        - static
          - ts
            test.js *
- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

おそらく、「rootDir」オプションを設定し、「outDir」オプションを以下のように変更することで、これが必要になります。

"include": "src/main/resources/static/ts"
"rootDir": "src/main/resources/static/ts" *
"outDir": "src/main/resources/static/js" *

- src
  - main
    - java
    - resources
      - static
        - js
          test.js *
        - ts
          test.ts

したがって、「exclude」オプション以外のファイルのスコープをカバーしない「rootDir」オプションを設定した場合、「rootDir」オプションの目的には意味がないため、tscはビルドに失敗します。

ええ、それは完全に悪い命名慣行です。 それは単に「rootOfStructureOfInputs」か何かであるはずでした。 また、「outDir」は単に「rootOfOutputs」である必要があります。

SSに表示されるのは、WebStormの問題ではなく、TSDevServerからのものです。
2番目に推奨されるインポートはがらくたです。 「通信」ソースフォルダから取得します。 一体誰がそれを望んでいるのか分かりません。 このようなインポートを使用してファイルをコンパイルすると、多くの問題が発生します。

私も試しました：

"exclude": ["lib", "node_modules",
        "..", "../..", "../../..", "../../../..", "../../../../..", "../../../../../.."
    ]

問題も解決しなかった

@mhegazyこの問題に「意図した