outFile caution

以下の理由から、これを使用するのは良くない考えです：

ランタイムエラー

あなたのコードがjsの任意の形式に依存する場合は、実行時にランダムなエラーが発生します。

foo.tsを考えてみましょう：

class Foo {

}

と bar.ts：

class Bar extends Foo {

}

あなたが正しい順序でコンパイルに失敗した場合など。おそらくアルファベット順にtsc bar.ts foo.tsコードがコンパイルされますが、実行時にReferenceErrorでエラーが発生します。

foo.tsを考えてみましょう：

module App {
    export var foo = 123;
}

そしてbar.ts：

module App {
    export var bar = foo + 456;
}

あなたが正しい順序でコンパイルに失敗した場合など。おそらくアルファベット順に tsc bar.ts foo.tsコードがコンパイルされますが、実行時にはbarがNaNに設定されています。

--outを使用すると、単一の.tsファイルは、不要なハックなしに単独で単一の.jsファイルにコード化することはできません。--outは本質的に遅いインクリメンタルビルドを強制します。

また、ソースマップは位置的にセンシティブでランレングス符号化されているので、元のマップを使用する場合は再コンパイル時に大部分のマップを再構築する必要があります。10秒から100秒のクロックが必要になるので、それは遅くなるでしょう。

確かに名前空間を使うことはできますが、ブラウザで実行するとwindowにはまだその名前空間を使うことができます。名前空間は不要な回避策に過ぎません。また、/// <referenceコメントは、あなたのコードにグローバルコンテキストを導入して、保守性を損ねます。

また、あなたの会社が独立して働いているいくつかのチームを持っていて、誰かが独立に書かれた2つのアプリケーションを統合しようと決心した場合、名前が競合する可能性が高いです。

私達は、より多くのコード解析ツールを提供したいと考えています。依存関係のチェーン(暗黙的に外部モジュールを使用している銀の大皿があります)を提供すると、これらは簡単になります。

また、_devツール_だけでなく、コードを理解するのに苦労します。次の人間は、物が実際にどこからインポートされるのかを理解し始める前に、多くのコードベースを理解する必要があります。内部モジュールを使用すると、コードを分離してレビューすることも難しくなります。例えば、githubで。

ランダムなランタイムエラー、遅くなるコンパイル時間、他の人のコードを理解するのが難しくなることによる、ただの結果です。

tsconfig.jsonではサポートされていません：あなたは手動でfilesの配列をソートする必要があります。

あなたのコードの一部を別のプロジェクトで再利用したい場合、そのすべての_暗黙の_依存関係管理を、潜在的なランタイムエラーなしに移植することは難しくなります。

また、nodejs(例：testing API)のようなものでブラウザコードを再利用することに決めた場合は、モジュールシステムに移植するか、nodejsのglobalを、あなたの新しいグローバルスコープにするために醜いハックを考える必要がありますスコープ(例:window)。

ファイルを単独でコンパイルすることはできません。例えば「a.ts」を考えてみましょう：

module M {
  var s = t;
}

次の形式のb.tsがあるかどうかによって出力が異なります：

module M {
  export var t = 5;
}

または

var t = 5;

そのためa.tsは

--outはビルドツールの仕事です。また、このようなビルドツールを使っても、外部モジュールによって提供される依存関係の恩恵を受けることができます。そのため、外部モジュールを使用し、必要に応じてビルドツールで単一の.jsファイルを作成することをお勧めします。

最終更新 2 年前

役に立ちましたか？