プログラムに含めるファイルの許可リストを指定します。ファイルが見つからない場合、エラーが発生します。

{
  "compilerOptions": {},
  "files": [
    "core.ts",
    "sys.ts",
    "types.ts",
    "scanner.ts",
    "parser.ts",
    "utilities.ts",
    "binder.ts",
    "checker.ts",
    "tsc.ts"
  ]
}

これは、ファイル数が少ない場合に、多くのファイルを参照するためにglobを使用する必要がない場合に役立ちます。globが必要な場合は、includeを使用してください。

extendsの値は、継承する別の設定ファイルへのパスを含む文字列です。パスはNode.jsスタイルの解決を使用できます。

基本ファイルの設定が最初に読み込まれ、その後、継承する設定ファイルの設定によって上書きされます。設定ファイルに見つかったすべての相対パスは、それらが由来した設定ファイルに対して解決されます。

files、include、およびexcludeは、継承する設定ファイルから基本設定ファイルを *上書き* し、設定ファイル間の循環は許可されないことに注意してください。

現在、継承から除外される最上位レベルのプロパティはreferencesのみです。

例

configs/base.json:

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

tsconfig.json:

{
  "extends": "./configs/base",
  "files": ["main.ts", "supplemental.ts"]
}

tsconfig.nostrictnull.json:

{
  "extends": "./tsconfig",
  "compilerOptions": {
    "strictNullChecks": false
  }
}

設定ファイルに見つかった相対パスを持つプロパティで、継承から除外されていないものは、それらが由来した設定ファイルに対して解決されます。

プログラムに含めるファイル名またはパターンの配列を指定します。これらのファイル名は、tsconfig.jsonファイルを含むディレクトリを基準にして解決されます。

json
{
  "include": ["src/**/*", "tests/**/*"]
}

これには以下が含まれます

.
├── scripts                ⨯
│   ├── lint.ts            ⨯
│   ├── update_deps.ts     ⨯
│   └── utils.ts           ⨯
├── src                    ✓
│   ├── client             ✓
│   │    ├── index.ts      ✓
│   │    └── utils.ts      ✓
│   ├── server             ✓
│   │    └── index.ts      ✓
├── tests                  ✓
│   ├── app.test.ts        ✓
│   ├── utils.ts           ✓
│   └── tests.d.ts         ✓
├── package.json
├── tsconfig.json
└── yarn.lock

includeとexcludeは、ワイルドカード文字をサポートしてglobパターンを作成します。

• * は、0 個以上の文字（ディレクトリセパレーターを除く）に一致します。
• ? は、任意の1文字（ディレクトリセパレーターを除く）に一致します。
• **/ は、任意のレベルにネストされた任意のディレクトリに一致します。

パターンの最後のパスセグメントにファイル拡張子またはワイルドカード文字が含まれていない場合、それはディレクトリとして扱われ、そのディレクトリ内のサポートされている拡張子のファイルが含まれます（例：デフォルトでは.ts、.tsx、.d.tsで、allowJsがtrueに設定されている場合は.jsと.jsx）。

includeの解決時にスキップするファイル名またはパターンの配列を指定します。

**重要:** excludeは、includeの設定の結果としてどのファイルが含まれるかのみを変更します。excludeで指定されたファイルは、コード内のimport文、typesの包含、/// <referenceディレクティブ、またはfilesリストで指定されているために、コードベースの一部になる可能性があります。

これは、ファイルをコードベースに **含めるのを防ぐ** メカニズムではありません。単にincludeの設定が検出するものを変更するだけです。

プロジェクト参照は、TypeScript プログラムをより小さな部分に分割する方法です。プロジェクト参照を使用すると、ビルド時間とエディターのインタラクション時間を大幅に向上させ、コンポーネント間の論理的な分離を強化し、コードを新しい方法で整理することができます。

参照の動作の詳細については、ハンドブックのプロジェクト参照セクションを参照してください。

設定値：

• `undefined` (デフォルト) エディタに警告としてサジェスチョンを表示します。
• `true` 到達不能なコードが無視されます。
• `false` 到達不能なコードに関するコンパイラエラーが発生します。

これらの警告は、JavaScript構文の使用によって証明可能に到達不能なコードに関するものだけです。例えば、

ts
function fn(n: number) {
  if (n > 5) {
    return true;
  } else {
    return false;
  }
  return true;
}

`"allowUnreachableCode": false` の場合

ts
function fn(n: number) {
  if (n > 5) {
    return true;
  } else {
    return false;
  }
  return true;
Unreachable code detected.7027Unreachable code detected.
}Try

これは、型解析によって見かけ上到達不能と思われるコードに基づくエラーには影響しません。

設定値：

• `undefined` (デフォルト) エディタに警告としてサジェスチョンを表示します。
• `true` 未使用のラベルが無視されます。
• `false` 未使用のラベルに関するコンパイラエラーが発生します。

JavaScriptではラベルは非常にまれで、通常はオブジェクトリテラルの記述を試みたことを示しています。

ts
function verifyAge(age: number) {
  // Forgot 'return' statement
  if (age > 18) {
    verified: true;
Unused label.7028Unused label.
  }
}Try

ファイルがECMAScript厳格モードで解析され、「use strict」が各ソースファイルに対して出力されるようにします。

ECMAScript厳格モードはES5で導入され、JavaScriptエンジンのランタイムの動作を調整してパフォーマンスを向上させ、いくつかのエラーを黙って無視する代わりに例外としてスローするようにします。

`exactOptionalPropertyTypes` を有効にすると、TypeScriptは`?`プレフィックスを持つ`type`または`interface`のプロパティの処理に関するより厳格なルールを適用します。

例えば、このインターフェースは、プロパティが2つの文字列のいずれか「dark」または「light」であるか、オブジェクトに存在しないことを宣言しています。

ts
interface UserDefaults {
  // The absence of a value represents 'system'
  colorThemeOverride?: "dark" | "light";
}

このフラグを有効にしないと、`colorThemeOverride` に設定できる値は「dark」、「light」、`undefined`の3つになります。

値を`undefined`に設定すると、存在チェックの大部分のJavaScriptランタイムチェックが失敗する可能性があり、事実上偽になります。しかし、これは正確ではありません。`colorThemeOverride: undefined`は`colorThemeOverride`が定義されていないのとは異なります。例えば、`"colorThemeOverride" in settings`は、キーとして`undefined`を使用する場合と定義されていない場合で動作が異なります。

`exactOptionalPropertyTypes` は、オプションプロパティとして提供された定義をTypeScriptが真に強制するようにします。

ts
const settings = getUserSettings();
settings.colorThemeOverride = "dark";
settings.colorThemeOverride = "light";
 
// But not:
settings.colorThemeOverride = undefined;
Type 'undefined' is not assignable to type '"dark" | "light"' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the type of the target.2412Type 'undefined' is not assignable to type '"dark" | "light"' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the type of the target.Try

switch文のフォールスルーケースについてエラーを報告します。switch文内の空でないケースには、`break`、`return`、または`throw`のいずれかを含める必要があります。これにより、フォールスルーのバグを誤って出荷することがなくなります。

ts
const a: number = 6;
 
switch (a) {
  case 0:
Fallthrough case in switch.7029Fallthrough case in switch.
    console.log("even");
  case 1:
    console.log("odd");
    break;
}Try

型注釈がない場合、TypeScriptは型を推論できない場合、変数の型として`any`にフォールバックします。

これにより、一部のエラーが見過ごされる可能性があります。例えば、

ts
function fn(s) {
  // No error?
  console.log(s.subtr(3));
}
fn(42);Try

`noImplicitAny`を有効にすると、TypeScriptは`any`を推論した場合に常にエラーを発行します。

ts
function fn(s) {
Parameter 's' implicitly has an 'any' type.7006Parameter 's' implicitly has an 'any' type.
  console.log(s.subtr(3));
}Try

継承を使用するクラスを操作する場合、サブクラスが基底クラスで名前が変更された場合、オーバーロードする関数と「同期がずれる」可能性があります。

例えば、音楽アルバム同期システムをモデル化しているとします。

ts
class Album {
  download() {
    // Default behavior
  }
}
 
class SharedAlbum extends Album {
  download() {
    // Override to get info from many sources
  }
}Try

次に、機械学習で生成されたプレイリストのサポートを追加するときに、`Album`クラスを`setup`関数を持つようにリファクタリングします。

ts
class Album {
  setup() {
    // Default behavior
  }
}
 
class MLAlbum extends Album {
  setup() {
    // Override to get info from algorithm
  }
}
 
class SharedAlbum extends Album {
  download() {
    // Override to get info from many sources
  }
}Try

この場合、TypeScriptは`SharedAlbum`の`download`が基底クラスの関数をオーバーライドすることを期待していたという警告を出していません。

`noImplicitOverride`を使用すると、オーバーライドする関数が`override`キーワードを含めるようにすることで、サブクラスが同期を失うことがないようにできます。

`noImplicitOverride`が有効になっている次の例では、`override`がない場合に受信されるエラーを確認できます。

ts
class Album {
  setup() {}
}
 
class MLAlbum extends Album {
  override setup() {}
}
 
class SharedAlbum extends Album {
  setup() {}
This member must have an 'override' modifier because it overrides a member in the base class 'Album'.4114This member must have an 'override' modifier because it overrides a member in the base class 'Album'.
}Try

有効にすると、TypeScriptは関数のすべてのコードパスが値を返すことを確認します。

ts
function lookupHeadphonesManufacturer(color: "blue" | "black"): string {
Function lacks ending return statement and return type does not include 'undefined'.2366Function lacks ending return statement and return type does not include 'undefined'.
  if (color === "blue") {
    return "beats";
  } else {
    "bose";
  }
}Try

暗黙的な`any`型の`this`式に関するエラーを発生させます。

例えば、以下のクラスは`this.width`と`this.height`にアクセスしようとする関数を返しますが、`getAreaFunction`内の関数の`this`のコンテキストはRectangleのインスタンスではありません。

ts
class Rectangle {
  width: number;
  height: number;
 
  constructor(width: number, height: number) {
    this.width = width;
    this.height = height;
  }
 
  getAreaFunction() {
    return function () {
      return this.width * this.height;
'this' implicitly has type 'any' because it does not have a type annotation.
'this' implicitly has type 'any' because it does not have a type annotation.2683
2683'this' implicitly has type 'any' because it does not have a type annotation.
'this' implicitly has type 'any' because it does not have a type annotation.
    };
  }
}Try

この設定は、「ドット」( `obj.key` )構文と「インデックス」( `obj["key"]` )構文によるフィールドへのアクセス、およびプロパティが型内で宣言される方法との間の一貫性を確保します。

このフラグがないと、TypeScriptは定義されていないフィールドにドット構文を使用してアクセスすることを許可します。

ts
interface GameSettings {
  // Known up-front properties
  speed: "fast" | "medium" | "slow";
  quality: "high" | "low";
 
  // Assume anything unknown to the interface
  // is a string.
  [key: string]: string;
}
 
const settings = getSettings();
settings.speed;
          
(property) GameSettings.speed: "fast" | "medium" | "slow"
settings.quality;
           
(property) GameSettings.quality: "high" | "low"
 
// Unknown key accessors are allowed on
// this object, and are `string`
settings.username;
            
(index) GameSettings[string]: stringTry

フラグをオンにすると、不明なフィールドがインデックス構文ではなくドット構文を使用しているため、エラーが発生します。

ts
const settings = getSettings();
settings.speed;
settings.quality;
 
// This would need to be settings["username"];
settings.username;
Property 'username' comes from an index signature, so it must be accessed with ['username'].4111Property 'username' comes from an index signature, so it must be accessed with ['username'].
            
(index) GameSettings[string]: stringTry

このフラグの目的は、呼び出し構文において、そのプロパティが存在することにどれだけ確信があるかを意図的に示すことです。

TypeScriptには、インデックスシグネチャを介して、不明なキーを持つがオブジェクトの値が既知であるオブジェクトを記述する方法があります。

ts
interface EnvironmentVars {
  NAME: string;
  OS: string;
 
  // Unknown properties are covered by this index signature.
  [propName: string]: string;
}
 
declare const env: EnvironmentVars;
 
// Declared as existing
const sysName = env.NAME;
const os = env.OS;
      
const os: string
 
// Not declared, but because of the index
// signature, then it is considered a string
const nodeEnv = env.NODE_ENV;
        
const nodeEnv: stringTry

`noUncheckedIndexedAccess`を有効にすると、型内の宣言されていないフィールドに`undefined`が追加されます。

ts
declare const env: EnvironmentVars;
 
// Declared as existing
const sysName = env.NAME;
const os = env.OS;
      
const os: string
 
// Not declared, but because of the index
// signature, then it is considered a string
const nodeEnv = env.NODE_ENV;
        
const nodeEnv: string | undefinedTry

未使用のローカル変数に関するエラーを報告します。

ts
const createKeyboard = (modelID: number) => {
  const defaultModelID = 23;
'defaultModelID' is declared but its value is never read.6133'defaultModelID' is declared but its value is never read.
  return { type: "keyboard", modelID };
};Try

関数内の未使用のパラメータに関するエラーを報告します。

ts
const createDefaultKeyboard = (modelID: number) => {
'modelID' is declared but its value is never read.6133'modelID' is declared but its value is never read.
  const defaultModelID = 23;
  return { type: "keyboard", modelID: defaultModelID };
};Try

`strict`フラグは、プログラムの正確性の保証を強化する、幅広い型チェック動作を有効にします。これを有効にすることは、以下に示すすべての厳格モードファミリオプションを有効にすることと同じです。必要に応じて、個々の厳格モードファミリチェックを無効にすることができます。

将来のバージョンのTypeScriptでは、このフラグの下でより厳格なチェックが導入される可能性があるため、TypeScriptのアップグレードによってプログラムに新しい型エラーが発生する可能性があります。適切で可能な場合、対応するフラグが追加され、その動作を無効にすることができます。

設定されている場合、TypeScriptは関数の組み込みメソッド`call`、`bind`、`apply`が基になる関数に対して正しい引数で呼び出されることをチェックします。

ts
// With strictBindCallApply on
function fn(x: string) {
  return parseInt(x);
}
 
const n1 = fn.call(undefined, "10");
 
const n2 = fn.call(undefined, false);
Argument of type 'boolean' is not assignable to parameter of type 'string'.2345Argument of type 'boolean' is not assignable to parameter of type 'string'.Try

それ以外の場合は、これらの関数は任意の引数を受け入れ、`any`を返します。

ts
// With strictBindCallApply off
function fn(x: string) {
  return parseInt(x);
}
 
// Note: No error; return type is 'any'
const n = fn.call(undefined, false);Try

有効にすると、このフラグにより、関数の引数がより正しくチェックされるようになります。

`strictFunctionTypes`をオフにした場合の基本的な例を次に示します。

ts
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
type StringOrNumberFunc = (ns: string | number) => void;
 
// Unsafe assignment
let func: StringOrNumberFunc = fn;
// Unsafe call - will crash
func(10);Try

`strictFunctionTypes`をオンにすると、エラーが正しく検出されます。

ts
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
type StringOrNumberFunc = (ns: string | number) => void;
 
// Unsafe assignment is prevented
let func: StringOrNumberFunc = fn;
Type '(x: string) => void' is not assignable to type 'StringOrNumberFunc'.
  Types of parameters 'x' and 'ns' are incompatible.
    Type 'string | number' is not assignable to type 'string'.
      Type 'number' is not assignable to type 'string'.2322Type '(x: string) => void' is not assignable to type 'StringOrNumberFunc'.
  Types of parameters 'x' and 'ns' are incompatible.
    Type 'string | number' is not assignable to type 'string'.
      Type 'number' is not assignable to type 'string'.Try

この機能の開発中に、DOM内の一部のものなど、本質的に安全でないクラス階層が多数発見されました。このため、この設定は`function`構文で記述された関数にのみ適用され、`method`構文の関数には適用されません。

ts
type Methodish = {
  func(x: string | number): void;
};
 
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
// Ultimately an unsafe assignment, but not detected
const m: Methodish = {
  func: fn,
};
m.func(10);Try

`strictNullChecks`が`false`の場合、`null`と`undefined`は言語によって事実上無視されます。これにより、ランタイムで予期しないエラーが発生する可能性があります。

`strictNullChecks`が`true`の場合、`null`と`undefined`にはそれぞれ独自の型があり、具体的な値が期待される場所でそれらを使用しようとすると型エラーが発生します。

例えば、このTypeScriptコードでは、`users.find`は実際にユーザーを見つけるという保証はありませんが、まるで保証されているかのようにコードを記述できます。

ts
declare const loggedInUsername: string;
 
const users = [
  { name: "Oby", age: 12 },
  { name: "Heera", age: 32 },
];
 
const loggedInUser = users.find((u) => u.name === loggedInUsername);
console.log(loggedInUser.age);Try

`strictNullChecks`を`true`に設定すると、`loggedInUser`を使用する前にその存在を保証していないというエラーが発生します。

ts
declare const loggedInUsername: string;
 
const users = [
  { name: "Oby", age: 12 },
  { name: "Heera", age: 32 },
];
 
const loggedInUser = users.find((u) => u.name === loggedInUsername);
console.log(loggedInUser.age);
'loggedInUser' is possibly 'undefined'.18048'loggedInUser' is possibly 'undefined'.Try

2番目の例は、配列の`find`関数がこの簡略化のようなものだから失敗しました。

ts
// When strictNullChecks: true
type Array = {
  find(predicate: (value: any, index: number) => boolean): S | undefined;
};
// When strictNullChecks: false the undefined is removed from the type system,
// allowing you to write code which assumes it always found a result
type Array = {
  find(predicate: (value: any, index: number) => boolean): S;
};

trueに設定すると、クラスプロパティが宣言されているがコンストラクタで設定されていない場合に、TypeScriptはエラーを発生させます。

ts
class UserAccount {
  name: string;
  accountType = "user";
 
  email: string;
Property 'email' has no initializer and is not definitely assigned in the constructor.2564Property 'email' has no initializer and is not definitely assigned in the constructor.
  address: string | undefined;
 
  constructor(name: string) {
    this.name = name;
    // Note that this.email is not set
  }
}Try

上記の例では、

• `this.name`は具体的に設定されています。
• `this.accountType`はデフォルトで設定されています。
• `this.email`は設定されておらず、エラーが発生します。
• `this.address`は、`undefined`の可能性があるとして宣言されているため、設定する必要はありません。

TypeScript 4.0では、catch節の変数の型を`any`から`unknown`に変更できるサポートが追加されました。次のようなコードを許可します。

ts
try {
  // ...
} catch (err) {
  // We have to verify err is an
  // error before using it as one.
  if (err instanceof Error) {
    console.log(err.message);
  }
}Try

このパターンにより、スローされるオブジェクトが事前にErrorサブクラスであると保証できないため、エラー処理コードがより包括的になります。`useUnknownInCatchVariables`フラグを有効にすると、追加の構文(`: unknown`)や、この動作を強制しようとするリンタールールは必要ありません。

TypeScript 5.0 では、インポートパスが既知の JavaScript または TypeScript ファイル拡張子で終わっていない場合、コンパイラは `{file basename}.d.{extension}.ts` という形式の宣言ファイルを探します。例えば、バンドラープロジェクトで CSS ローダーを使用している場合、これらのスタイルシートの宣言ファイルを作成（または生成）することが必要になる場合があります。

css
/* app.css */
.cookie-banner {
  display: none;
}

ts
// app.d.css.ts
declare const css: {
  cookieBanner: string;
};
export default css;

ts
// App.tsx
import styles from "./app.css";
styles.cookieBanner; // string

デフォルトでは、このインポートは、TypeScript がこのファイルタイプを理解しておらず、ランタイムがインポートをサポートしていない可能性があることを知らせるエラーを発生させます。しかし、ランタイムまたはバンドラーで処理するように設定している場合は、新しい `--allowArbitraryExtensions` コンパイラオプションを使用してエラーを抑制できます。

従来、`app.d.css.ts` ではなく `app.css.d.ts` という名前の宣言ファイルを追加することで、同様の効果が得られることがよくありました。ただし、これは Node の CommonJS に対する `require` の解決ルールを通じて機能していました。厳密に言うと、前者は `app.css.js` という名前の JavaScript ファイルの宣言ファイルとして解釈されます。Node の ESM サポートでは相対ファイルのインポートに拡張子が含まれている必要があるため、`--moduleResolution node16` または `nodenext` の下では、ESM ファイル内のこの例で TypeScript はエラーになります。

詳細については、この機能の提案 と 対応するプルリクエスト を参照してください。

`--allowImportingTsExtensions` を使用すると、TypeScript ファイルは `.ts`、`.mts`、`.tsx` などの TypeScript 固有の拡張子を使用して相互にインポートできます。

このフラグは、`--noEmit` または `--emitDeclarationOnly` が有効になっている場合のみ許可されます。これは、これらのインポートパスは JavaScript 出力ファイルのランタイムでは解決できないためです。ここでは、リゾルバー（バンドラー、ランタイム、またはその他のツールなど）がこれらの `.ts` ファイル間のインポートを機能させることを想定しています。

`allowUmdGlobalAccess` を true に設定すると、モジュールファイル内からグローバルとして UMD エクスポートにアクセスできます。モジュールファイルとは、インポートと/またはエクスポートを持つファイルです。このフラグがない場合、UMD モジュールからのエクスポートを使用するには、インポート宣言が必要です。

このフラグの使用例としては、特定のライブラリ（jQuery や Lodash など）がランタイムで常に使用可能であることがわかっている Web プロジェクトがありますが、インポートを使用してアクセスできない場合が挙げられます。

ベアスペシファイアモジュール名の解決元のベースディレクトリを設定します。例えば、次のディレクトリ構造の場合

project
├── ex.ts
├── hello
│   └── world.ts
└── tsconfig.json

`"baseUrl": "./"` を使用すると、TypeScript は `tsconfig.json` と同じフォルダから始まるファイルを探します。

ts
import { helloWorld } from "hello/world";
console.log(helloWorld);

この解決は、`node_modules` からの検索よりも優先されます。

この機能は、ブラウザでの AMD モジュールローダーとの連携で使用するために設計されており、その他のコンテキストでは推奨されません。TypeScript 4.1 以降、`paths` を使用する場合、`baseUrl` を設定する必要がなくなりました。

`--customConditions` は、TypeScript が `package.json` の `exports` または `imports` フィールドから解決する際に成功する追加の 条件 のリストを受け取ります。これらの条件は、リゾルバーがデフォルトで使用している既存の条件に追加されます。

例えば、`tsconfig.json` にこのフィールドが次のように設定されている場合

jsonc
{
  "compilerOptions": {
    "target": "es2022",
    "moduleResolution": "bundler",
    "customConditions": ["my-condition"]
  }
}

`package.json` で `exports` または `imports` フィールドが参照されるたびに、TypeScript は `my-condition` という名前の条件を考慮します。

したがって、次の `package.json` を持つパッケージからインポートする場合

jsonc
{
  // ...
  "exports": {
    ".": {
      "my-condition": "./foo.mjs",
      "node": "./bar.mjs",
      "import": "./baz.mjs",
      "require": "./biz.mjs"
    }
  }
}

TypeScript は `foo.mjs` に対応するファイルを探そうとします。

このフィールドは、`--moduleResolution` の `node16`、`nodenext`、`bundler` オプションの下でのみ有効です。

プログラムのモジュールシステムを設定します。TypeScript の `module` オプションの理論 と リファレンスページ を参照してください。最新の Node.js プロジェクトでは、`nodenext` を使用することを強くお勧めします。

`module` を変更すると、リファレンスページも参照されている `moduleResolution` に影響します。

このファイルの出力例を次に示します。

ts
// @filename: index.ts
import { valueOfPi } from "./constants";
 
export const twoPi = valueOfPi * 2;Try

CommonJS

ts
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.twoPi = void 0;
const constants_1 = require("./constants");
exports.twoPi = constants_1.valueOfPi * 2;
 Try

UMD

ts
(function (factory) {
    if (typeof module === "object" && typeof module.exports === "object") {
        var v = factory(require, exports);
        if (v !== undefined) module.exports = v;
    }
    else if (typeof define === "function" && define.amd) {
        define(["require", "exports", "./constants"], factory);
    }
})(function (require, exports) {
    "use strict";
    Object.defineProperty(exports, "__esModule", { value: true });
    exports.twoPi = void 0;
    const constants_1 = require("./constants");
    exports.twoPi = constants_1.valueOfPi * 2;
});
 Try

AMD

ts
define(["require", "exports", "./constants"], function (require, exports, constants_1) {
    "use strict";
    Object.defineProperty(exports, "__esModule", { value: true });
    exports.twoPi = void 0;
    exports.twoPi = constants_1.valueOfPi * 2;
});
 Try

System

ts
System.register(["./constants"], function (exports_1, context_1) {
    "use strict";
    var constants_1, twoPi;
    var __moduleName = context_1 && context_1.id;
    return {
        setters: [
            function (constants_1_1) {
                constants_1 = constants_1_1;
            }
        ],
        execute: function () {
            exports_1("twoPi", twoPi = constants_1.valueOfPi * 2);
        }
    };
});
 Try

ESNext

ts
import { valueOfPi } from "./constants";
export const twoPi = valueOfPi * 2;
 Try

ES2015/ES6/ES2020/ES2022

ts
import { valueOfPi } from "./constants";
export const twoPi = valueOfPi * 2;
 Try

ES2015/ES6 の基本機能に加えて、ES2020 は 動的 `import` と `import.meta` をサポートし、ES2022 はさらに トップレベル `await` のサポートを追加しています。

node16/nodenext

4.7 以降で使用できる `node16` と `nodenext` モードは、Node の ネイティブ ECMAScript モジュールサポート と統合されます。出力される JavaScript は、ファイル拡張子と最寄りの `package.json` の `type` 設定の値に応じて、`CommonJS` または `ES2020` 出力を使用します。モジュールの解決も異なります。ハンドブック と モジュールリファレンス で詳細を確認できます。

None

ts
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.twoPi = void 0;
const constants_1 = require("./constants");
exports.twoPi = constants_1.valueOfPi * 2;
 Try

モジュール解決戦略を指定します。

• 最新のNode.jsバージョンには'node16'または'nodenext'を使用します。Node.js v12以降は、ECMAScript importとCommonJS requireの両方をサポートしており、異なるアルゴリズムを使用して解決されます。これらのmoduleResolution値は、対応するmodule値と組み合わせて、出力されたJavaScriptコードにimportまたはrequireのどちらが含まれるかに基づいて、各解決に適切なアルゴリズムを選択します。

• CommonJS requireのみをサポートするv10より前のNode.jsバージョンには'node10'（以前は'node'と呼ばれていました）を使用します。最新のコードではnode10を使用する必要はほとんどないでしょう。

• バンドラーで使用するには'bundler'を使用します。node16およびnodenextと同様に、このモードはpackage.jsonの"imports"と"exports"をサポートしますが、Node.jsの解決モードとは異なり、bundlerはインポートの相対パスにファイル拡張子を付ける必要がありません。

  bundlerはrequire呼び出しの解決をサポートしていません。TypeScriptファイルでは、import mod = require("foo")構文は禁止されます。JavaScriptファイルでは、require呼び出しはエラーになりませんが、常に型any（またはグローバルなrequire関数の環境宣言で宣言されている戻り値）を返します。

• 'classic'は、1.6リリース前のTypeScriptで使用されていました。classicは使用しないでください。

TypeScriptのモジュール解決の理論と各オプションの詳細を説明したリファレンスページがあります。

モジュールの解決時に検索するファイル名サフィックスのデフォルトリストをオーバーライドする方法を提供します。

{
  "compilerOptions": {
    "moduleSuffixes": [".ios", ".native", ""]
  }
}

上記の構成を考慮すると、次のインポートのようなものになります。

ts
import * as foo from "./foo";

TypeScriptは、相対ファイル./foo.ios.ts、./foo.native.ts、最後に./foo.tsを検索します。

moduleSuffixesの空文字列""は、TypeScriptが./foo.tsも検索するために必要です。

この機能は、各ターゲットプラットフォームが異なるmoduleSuffixesを持つ別々のtsconfig.jsonを使用できるReact Nativeプロジェクトで役立ちます。

デフォルトでは、TypeScriptは初期のファイルセットでimportおよび<referenceディレクティブを調べ、解決されたこれらのファイルをプログラムに追加します。

noResolveが設定されている場合、このプロセスは実行されません。ただし、importステートメントは、有効なモジュールに解決されるかどうかまだチェックされるため、他の方法でこれが満たされていることを確認する必要があります。

設定されている場合baseUrlを基準とした、そうでない場合はtsconfigファイル自体を基準とした参照先をインポートに再マッピングする一連のエントリです。moduleResolutionリファレンスページには、pathsに関するより詳細な説明があります。

pathsを使用すると、TypeScriptがrequire/importでのインポートをどのように解決するかを宣言できます。

{
  "compilerOptions": {
    "paths": {
      "jquery": ["./vendor/jquery/dist/jquery"]
    }
  }
}

これにより、import "jquery"を記述し、ローカルで正しい型をすべて取得できるようになります。

{
  "compilerOptions": {
    "paths": {
        "app/*": ["./src/app/*"],
        "config/*": ["./src/app/_config/*"],
        "environment/*": ["./src/environments/*"],
        "shared/*": ["./src/app/_shared/*"],
        "helpers/*": ["./src/helpers/*"],
        "tests/*": ["./src/tests/*"]
    },
}

この場合、TypeScriptファイルリゾルバーに、コードを見つけるための複数のカスタムプレフィックスをサポートするように指示できます。

この機能は、tscによって出力されるインポートパスの方法を変更しないため、pathsは、別のツールがこのマッピングを持っており、実行時またはバンドル時にそれを使用するようにTypeScriptに通知するためだけに使用してください。

.json拡張子を持つモジュールのインポートを許可します。これは、ノードプロジェクトでは一般的な方法です。これには、静的JSON形状に基づいてimportの型を生成することも含まれます。

TypeScriptはデフォルトではJSONファイルの解決をサポートしていません。

ts
// @filename: settings.json
Cannot find module './settings.json'. Consider using '--resolveJsonModule' to import module with '.json' extension.2732Cannot find module './settings.json'. Consider using '--resolveJsonModule' to import module with '.json' extension.
{
    "repo": "TypeScript",
    "dry": false,
    "debug": false
}
// @filename: index.ts
import settings from "./settings.json";
 
settings.debug === true;
settings.dry === 2;Try

このオプションを有効にすると、JSONをインポートし、そのJSONファイル内の型を検証できます。

ts
// @filename: settings.json
{
    "repo": "TypeScript",
    "dry": false,
This comparison appears to be unintentional because the types 'boolean' and 'number' have no overlap.2367This comparison appears to be unintentional because the types 'boolean' and 'number' have no overlap.
    "debug": false
}
// @filename: index.ts
import settings from "./settings.json";
 
settings.debug === true;
settings.dry === 2;Try

--resolvePackageJsonExportsは、node_modules内のパッケージから読み取るたびに、TypeScriptがpackage.jsonファイルのexportsフィールドを参照するように強制します。

このオプションは、--moduleResolutionのnode16、nodenext、bundlerオプションではtrueにデフォルト設定されています。

--resolvePackageJsonImportsは、祖先ディレクトリにpackage.jsonが含まれているファイルから始まるルックアップを実行する際に、TypeScriptがpackage.jsonファイルのimportsフィールドを参照するように強制します。

このオプションは、--moduleResolutionのnode16、nodenext、bundlerオプションではtrueにデフォルト設定されています。

デフォルト：すべての非宣言入力ファイルの最長の共通パス。compositeが設定されている場合、デフォルトはtsconfig.jsonファイルを含むディレクトリになります。

TypeScriptがファイルをコンパイルすると、出力ディレクトリには入力ディレクトリにあるものと同じディレクトリ構造が保持されます。

たとえば、いくつかの入力ファイルがあるとします。

MyProj
├── tsconfig.json
├── core
│   ├── a.ts
│   ├── b.ts
│   ├── sub
│   │   ├── c.ts
├── types.d.ts

rootDirの推論された値は、すべての非宣言入力ファイルの最長の共通パスであり、この場合はcore/です。

outDirがdistの場合、TypeScriptは次のツリーを書き込みます。

MyProj
├── dist
│   ├── a.js
│   ├── b.js
│   ├── sub
│   │   ├── c.js

ただし、coreを出力ディレクトリ構造の一部として意図していた可能性があります。tsconfig.jsonでrootDir: "."を設定することにより、TypeScriptは次のツリーを書き込みます。

MyProj
├── dist
│   ├── core
│   │   ├── a.js
│   │   ├── b.js
│   │   ├── sub
│   │   │   ├── c.js

重要なのは、rootDirはコンパイルの一部となるファイルには影響しません。include、exclude、またはfiles tsconfig.json設定とは相互作用しません。

TypeScriptは、outDirの外部のディレクトリに出力ファイルを書き込んだり、ファイルの発行をスキップすることはありません。このため、rootDirは、発行する必要があるすべてのファイルがrootDirパスの下にあることも強制します。

たとえば、次のツリーがあるとします。

MyProj
├── tsconfig.json
├── core
│   ├── a.ts
│   ├── b.ts
├── helpers.ts

rootDirをcoreとして、そしてincludeを*として指定することはエラーです。これは、outDirの外部に出力する必要があるファイル（../helpers.jsつまりhelpers.ts）を作成するためです。

rootDirsを使用すると、単一のルートとして機能する多くの「仮想」ディレクトリがあることをコンパイラに通知できます。これにより、コンパイラは、これらの「仮想」ディレクトリ内で、まるで1つのディレクトリにマージされたかのように、相対モジュールインポートを解決できます。

たとえば

 src
 └── views
     └── view1.ts (can import "./template1", "./view2`)
     └── view2.ts (can import "./template1", "./view1`)

 generated
 └── templates
         └── views
             └── template1.ts (can import "./view1", "./view2")

{
  "compilerOptions": {
    "rootDirs": ["src/views", "generated/templates/views"]
  }
}

これは、TypeScriptがJavaScriptを出力する方法には影響しません。実行時にそれらの相対パスで動作できると仮定しているだけです。

rootDirsは、TypeScriptまたはJavaScriptではないファイルに別の「型レイヤー」を提供し、別のフォルダに生成された.d.tsファイルの場所を提供することで使用できます。この手法は、必ずしもコードではないファイルのimportを使用するバンドルされたアプリケーションで役立ちます。

sh
 src
 └── index.ts
 └── css
     └── main.css
     └── navigation.css
 generated
 └── css
     └── main.css.d.ts
     └── navigation.css.d.ts

{
  "compilerOptions": {
    "rootDirs": ["src", "generated"]
  }
}

この手法では、コードではないソースファイルの型を事前に生成できます。インポートは、ソースファイルの場所に基づいて自然に機能します。たとえば、./src/index.tsはファイル./src/css/main.cssをインポートでき、TypeScriptは対応する生成された宣言ファイルによって、そのファイルタイプに対するバンドラの動作を認識します。

ts
// @filename: index.ts
import { appClass } from "./main.css";Try

デフォルトでは、すべての表示可能な「@types」パッケージがコンパイルに含まれます。任意の包含フォルダのnode_modules/@types内のパッケージは表示可能と見なされます。たとえば、./node_modules/@types/、../node_modules/@types/、../../node_modules/@types/など内のパッケージを意味します。

typeRootsが指定されている場合、typeRootsの下にあるパッケージのみが含まれます。たとえば

{
  "compilerOptions": {
    "typeRoots": ["./typings", "./vendor/types"]
  }
}

この構成ファイルには、./typingsと./vendor/typesの下にあるすべてのパッケージが含まれ、./node_modules/@typesのパッケージは含まれません。すべてのパスの基準はtsconfig.jsonです。

デフォルトでは、すべての表示可能な「@types」パッケージがコンパイルに含まれます。任意の包含フォルダのnode_modules/@types内のパッケージは表示可能と見なされます。たとえば、./node_modules/@types/、../node_modules/@types/、../../node_modules/@types/など内のパッケージを意味します。

typesが指定されている場合、リストされているパッケージのみがグローバルスコープに含まれます。例えば

{
  "compilerOptions": {
    "types": ["node", "jest", "express"]
  }
}

このtsconfig.jsonファイルには、./node_modules/@types/node、./node_modules/@types/jest、および./node_modules/@types/expressのみが含まれます。node_modules/@types/*の下にある他のパッケージは含まれません。

これはどのような影響がありますか？

このオプションは、アプリケーションコードに@types/*がどのように含まれるかには影響しません。たとえば、上記のcompilerOptionsの例で、次のようなコードがあった場合

ts
import * as moment from "moment";
moment().format("MMMM Do YYYY, h:mm:ss a");

momentのインポートは完全に型付けされます。

このオプションを設定した場合、`types`配列にモジュールを含めないことで

• プロジェクトにグローバル変数を追加しません（例：ノードのprocess、Jestのexpectなど）。
• エクスポートが自動インポートの推奨事項として表示されなくなります。

この機能はtypeRootsとは異なり、含める正確な型のみを指定することに関するものであり、typeRootsは特定のフォルダを含めたいことを指定できます。

プロジェクト内のすべてのTypeScriptまたはJavaScriptファイルに対して.d.tsファイルを生成します。これらの.d.tsファイルは、モジュールの外部APIを記述する型定義ファイルです。.d.tsファイルを使用すると、TypeScriptなどのツールは、型指定されていないコードに対してインテリセンスと正確な型を提供できます。

declarationをtrueに設定して、このTypeScriptコードでコンパイラを実行すると

ts
export let helloWorld = "hi";Try

次のようなindex.jsファイルが生成されます。

ts
export let helloWorld = "hi";
 Try

対応するhelloWorld.d.tsと共に

ts
export declare let helloWorld: string;
 Try

JavaScriptファイルの.d.tsファイルを使用する際には、emitDeclarationOnlyを使用するか、outDirを使用してJavaScriptファイルが上書きされないようにする必要があります。

宣言ファイルが出力されるルートディレクトリを設定する方法を提供します。

example
├── index.ts
├── package.json
└── tsconfig.json

このtsconfig.jsonを使用すると

{
  "compilerOptions": {
    "declaration": true,
    "declarationDir": "./types"
  }
}

index.tsのd.tsがtypesフォルダに配置されます。

example
├── index.js
├── index.ts
├── package.json
├── tsconfig.json
└── types
    └── index.d.ts

元の.tsソースファイルにマップバックする.d.tsファイルのソースマップを生成します。これにより、VS Codeなどのエディターは、「定義へ移動」などの機能を使用する際に、元の.tsファイルに移動できます。

プロジェクト参照を使用している場合は、これを有効にすることを強く検討する必要があります。

ダウンレベル化とは、TypeScriptが以前のバージョンのJavaScriptに変換することです。このフラグは、古いJavaScriptランタイムで最新のJavaScriptが新しい概念をどのように反復処理するかについて、より正確な実装をサポートするために使用されます。

ECMAScript 6では、for / ofループ（for (el of arr)）、配列スプレッド（[a, ...b]）、引数スプレッド（fn(...args)）、Symbol.iteratorなど、いくつかの新しい反復プリミティブが追加されました。downlevelIterationを使用すると、Symbol.iteratorの実装が存在する場合、これらの反復プリミティブをES5環境でより正確に使用できます。

例：for / ofへの影響

このTypeScriptコードを使用すると

ts
const str = "Hello!";
for (const s of str) {
  console.log(s);
}Try

downlevelIterationを有効にしないと、任意のオブジェクトのfor / ofループは従来のforループにダウンレベル化されます。

ts
"use strict";
var str = "Hello!";
for (var _i = 0, str_1 = str; _i < str_1.length; _i++) {
    var s = str_1[_i];
    console.log(s);
}
 Try

これは多くの場合、人々が期待することですが、ECMAScript反復プロトコルに完全に準拠しているわけではありません。絵文字（😜）などの一部の文字列は、.lengthが2（またはそれ以上）ですが、for-ofループでは1単位として反復処理する必要があります。Jonathan Newによるこのブログ投稿で、より詳細な説明を参照してください。

downlevelIterationを有効にすると、TypeScriptはSymbol.iteratorの実装（ネイティブまたはポリフィル）をチェックするヘルパー関数を使用します。この実装がない場合は、インデックスベースの反復処理に戻ります。

ts
"use strict";
var __values = (this && this.__values) || function(o) {
    var s = typeof Symbol === "function" && Symbol.iterator, m = s && o[s], i = 0;
    if (m) return m.call(o);
    if (o && typeof o.length === "number") return {
        next: function () {
            if (o && i >= o.length) o = void 0;
            return { value: o && o[i++], done: !o };
        }
    };
    throw new TypeError(s ? "Object is not iterable." : "Symbol.iterator is not defined.");
};
var e_1, _a;
var str = "Hello!";
try {
    for (var str_1 = __values(str), str_1_1 = str_1.next(); !str_1_1.done; str_1_1 = str_1.next()) {
        var s = str_1_1.value;
        console.log(s);
    }
}
catch (e_1_1) { e_1 = { error: e_1_1 }; }
finally {
    try {
        if (str_1_1 && !str_1_1.done && (_a = str_1.return)) _a.call(str_1);
    }
    finally { if (e_1) throw e_1.error; }
}
 Try

tslibをimportHelpersを介して使用して、インラインJavaScriptの量を減らすこともできます。

ts
"use strict";
var __values = (this && this.__values) || function(o) {
    var s = typeof Symbol === "function" && Symbol.iterator, m = s && o[s], i = 0;
    if (m) return m.call(o);
    if (o && typeof o.length === "number") return {
        next: function () {
            if (o && i >= o.length) o = void 0;
            return { value: o && o[i++], done: !o };
        }
    };
    throw new TypeError(s ? "Object is not iterable." : "Symbol.iterator is not defined.");
};
var e_1, _a;
var str = "Hello!";
try {
    for (var str_1 = __values(str), str_1_1 = str_1.next(); !str_1_1.done; str_1_1 = str_1.next()) {
        var s = str_1_1.value;
        console.log(s);
    }
}
catch (e_1_1) { e_1 = { error: e_1_1 }; }
finally {
    try {
        if (str_1_1 && !str_1_1.done && (_a = str_1.return)) _a.call(str_1);
    }
    finally { if (e_1) throw e_1.error; }
}
 Try

注：downlevelIterationを有効にしても、Symbol.iteratorがランタイムに存在しない場合、準拠性は向上しません。

例：配列スプレッドへの影響

これは配列スプレッドです。

js
// Make a new array whose elements are 1 followed by the elements of arr2
const arr = [1, ...arr2];

説明によると、ES5へのダウンレベル化は簡単そうです。

js
// The same, right?
const arr = [1].concat(arr2);

しかし、これは特定のまれなケースでは明らかに異なります。

たとえば、ソース配列に1つ以上のアイテムが欠落している場合（穴が含まれている場合）、スプレッド構文は空のアイテムをすべてundefinedで置き換えますが、.concatはそのまま残します。

js
// Make an array where the element at index 1 is missing
let arrayWithHole = ["a", , "c"];
let spread = [...arrayWithHole];
let concatenated = [].concat(arrayWithHole);
console.log(arrayWithHole);
// [ 'a', <1 empty item>, 'c' ]
console.log(spread);
// [ 'a', undefined, 'c' ]
console.log(concatenated);
// [ 'a', <1 empty item>, 'c' ]

for / ofと同様に、downlevelIterationはSymbol.iterator（存在する場合）を使用して、ES 6の動作をより正確にエミュレートします。

出力ファイルの書き込み時に、TypeScriptがバイトオーダーマーク（BOM）を出力するかどうかを制御します。一部のランタイム環境では、JavaScriptファイルを正しく解釈するためにBOMが必要です。一方、BOMが存在しないことが求められる環境もあります。falseのデフォルト値は、変更する理由がない限り、一般的に最適です。

.d.tsファイルのみを出力し、.jsファイルは出力しません。

この設定は、次の2つの場合に役立ちます。

• TypeScript以外のトランスパイラを使用してJavaScriptを生成している場合。
• コンシューマー向けにd.tsファイルのみを生成するためにTypeScriptを使用している場合。

特定のダウンレベル化操作では、TypeScriptはクラスの拡張、配列やオブジェクトのスプレッド、非同期操作などの操作にいくつかのヘルパーコードを使用します。デフォルトでは、これらのヘルパーはそれらを使用するファイルに挿入されます。同じヘルパーが多くの異なるモジュールで使用されている場合、コードの重複が発生する可能性があります。

importHelpersフラグがオンの場合、これらのヘルパー関数は代わりにtslibモジュールからインポートされます。tslibモジュールがランタイムでインポート可能であることを確認する必要があります。これはモジュールにのみ影響し、グローバルスクリプトファイルはモジュールのインポートを試みません。

たとえば、このTypeScriptの場合

ts
export function fn(arr: number[]) {
  const arr2 = [1, ...arr];
}

downlevelIterationとimportHelpersを有効にしてもfalseのままです。

ts
var __read = (this && this.__read) || function (o, n) {
    var m = typeof Symbol === "function" && o[Symbol.iterator];
    if (!m) return o;
    var i = m.call(o), r, ar = [], e;
    try {
        while ((n === void 0 || n-- > 0) && !(r = i.next()).done) ar.push(r.value);
    }
    catch (error) { e = { error: error }; }
    finally {
        try {
            if (r && !r.done && (m = i["return"])) m.call(i);
        }
        finally { if (e) throw e.error; }
    }
    return ar;
};
var __spreadArray = (this && this.__spreadArray) || function (to, from, pack) {
    if (pack || arguments.length === 2) for (var i = 0, l = from.length, ar; i < l; i++) {
        if (ar || !(i in from)) {
            if (!ar) ar = Array.prototype.slice.call(from, 0, i);
            ar[i] = from[i];
        }
    }
    return to.concat(ar || Array.prototype.slice.call(from));
};
export function fn(arr) {
    var arr2 = __spreadArray([1], __read(arr), false);
}
 Try

次に、downlevelIterationとimportHelpersの両方を有効にすると

ts
import { __read, __spreadArray } from "tslib";
export function fn(arr) {
    var arr2 = __spreadArray([1], __read(arr), false);
}
 Try

独自の関数の実装を提供する場合は、noEmitHelpersを使用できます。

verbatimModuleSyntaxに置き換えられました。

このフラグはimportの動作を制御し、3つの異なるオプションがあります。

• remove：型のみを参照するimport文を削除するデフォルトの動作。

• preserve：値または型が決して使用されないすべてのimport文を保持します。これにより、インポート/副作用が保持される可能性があります。

• error：すべてのインポートを保持しますが（preserveオプションと同じ）、値インポートが型としてのみ使用されている場合にエラーが発生します。これは、値が誤ってインポートされていないことを確認したいが、副作用インポートを明示的にしたい場合に役立つ場合があります。

このフラグは、import typeを使用して、JavaScriptに決して出力されるべきではないimport文を明示的に作成できるため機能します。

設定されている場合、ソースマップを提供するために.js.mapファイルを出力する代わりに、TypeScriptはソースマップの内容を.jsファイルに埋め込みます。これによりJSファイルが大きくなりますが、場合によっては便利です。たとえば、.mapファイルの提供が許可されていないWebサーバーでJSファイルをデバッグする場合などです。

sourceMapとは相互に排他的です。

たとえば、このTypeScriptの場合

ts
const helloWorld = "hi";
console.log(helloWorld);

このJavaScriptに変換されます。

ts
"use strict";
const helloWorld = "hi";
console.log(helloWorld);
 Try

inlineSourceMap を有効にしてビルドを有効にすると、ファイルの一番下に、そのファイルのソースマップを含むコメントがあります。

ts
"use strict";
const helloWorld = "hi";
console.log(helloWorld);
//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiaW5kZXguanMiLCJzb3VyY2VSb290IjoiIiwic291cmNlcyI6WyJpbmRleC50cyJdLCJuYW1lcyI6W10sIm1hcHBpbmdzIjoiO0FBQUEsTUFBTSxVQUFVLEdBQUcsSUFBSSxDQUFDO0FBQ3hCLE9BQU8sQ0FBQyxHQUFHLENBQUMsVUFBVSxDQUFDLENBQUMifQ==Try

設定されている場合、TypeScript は .ts ファイルの元のコンテンツを、ソースマップの sourcesContent プロパティを使用して、ソースマップに埋め込み文字列として含めます。inlineSourceMap と同様のケースで役立つことがよくあります。

sourceMap または inlineSourceMap のいずれかを設定する必要があります。

たとえば、このTypeScriptの場合

ts
const helloWorld = "hi";
console.log(helloWorld);Try

デフォルトでは、このJavaScriptに変換されます。

ts
"use strict";
const helloWorld = "hi";
console.log(helloWorld);
 Try

inlineSources と inlineSourceMap を有効にしてビルドを有効にすると、ファイルの一番下に、そのファイルのソースマップを含むコメントがあります。inlineSourceMap の例とは末尾が異なることに注意してください。これは、ソースマップに元のソースコードも含まれるようになったためです。

ts
"use strict";
const helloWorld = "hi";
console.log(helloWorld);
//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiaW5kZXguanMiLCJzb3VyY2VSb290IjoiIiwic291cmNlcyI6WyJpbmRleC50cyJdLCJuYW1lcyI6W10sIm1hcHBpbmdzIjoiO0FBQUEsTUFBTSxVQUFVLEdBQUcsSUFBSSxDQUFDO0FBQ3hCLE9BQU8sQ0FBQyxHQUFHLENBQUMsVUFBVSxDQUFDLENBQUMiLCJzb3VyY2VzQ29udGVudCI6WyJjb25zdCBoZWxsb1dvcmxkID0gXCJoaVwiO1xuY29uc29sZS5sb2coaGVsbG9Xb3JsZCk7Il19Try

デバッガーが生成された場所ではなく、マップファイルを見つける場所を指定します。この文字列はソースマップ内でそのまま扱われます。例：

{
  "compilerOptions": {
    "sourceMap": true,
    "mapRoot": "https://my-website.com/debug/sourcemaps/"
  }
}

index.js のソースマップが https://my-website.com/debug/sourcemaps/index.js.map にあることを宣言します。

ファイルを出力する際に使用する改行シーケンスを指定します：「CRLF」(dos) または「LF」(unix)。

JavaScriptソースコード、ソースマップ、宣言などのコンパイラ出力ファイルを出力しません。

これにより、Babel や swc などの別のツールが、TypeScriptファイルをJavaScript環境で実行できるファイルに変換するスペースが作成されます。

その後、TypeScriptをエディターの統合ツールとして、そしてソースコードの型チェッカーとして使用できます。

importHelpers を使用してヘルパーをインポートする代わりに、使用するヘルパーのグローバルスコープに実装を提供し、ヘルパー関数の出力全体を完全にオフにすることができます。

たとえば、ES5でこのasync関数は、awaitのような関数とgeneratorのような関数を実行する必要があります。

ts
const getAPI = async (url: string) => {
  // Get API
  return {};
};Try

これはかなりの量のJavaScriptを作成します。

ts
"use strict";
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};
var __generator = (this && this.__generator) || function (thisArg, body) {
    var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g;
    return g = { next: verb(0), "throw": verb(1), "return": verb(2) }, typeof Symbol === "function" && (g[Symbol.iterator] = function() { return this; }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (g && (g = 0, op[0] && (_ = 0)), _) try {
            if (f = 1, y && (t = op[0] & 2 ? y["return"] : op[0] ? y["throw"] || ((t = y["return"]) && t.call(y), 0) : y.next) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [op[0] & 2, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
        if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
    }
};
var getAPI = function (url) { return __awaiter(void 0, void 0, void 0, function () {
    return __generator(this, function (_a) {
        // Get API
        return [2 /*return*/, {}];
    });
}); };
 Try

これは、このフラグを使用して独自のグローバルに置き換えることができます。

ts
"use strict";
var getAPI = function (url) { return __awaiter(void 0, void 0, void 0, function () {
    return __generator(this, function (_a) {
        // Get API
        return [2 /*return*/, {}];
    });
}); };
 Try

エラーが報告された場合、JavaScriptソースコード、ソースマップ、宣言などのコンパイラ出力ファイルを出力しません。

これはデフォルトでfalseになっており、変更されたコードの結果を別の環境で確認する前にすべてのエラーを解決する必要がない監視環境でTypeScriptを使用しやすくします。

指定されている場合、.js（および.d.ts、.js.mapなど）ファイルは、このディレクトリに出力されます。元のソースファイルのディレクトリ構造は保持されます。計算されたルートが意図したものと異なる場合はrootDirを参照してください。

指定されていない場合、.jsファイルは、生成元の.tsファイルと同じディレクトリに出力されます。

sh
$ tsc
example
├── index.js
└── index.ts

このようなtsconfig.jsonの場合

{
  "compilerOptions": {
    "outDir": "dist"
  }
}

これらの設定でtscを実行すると、ファイルは指定されたdistフォルダに移動されます。

sh
$ tsc
example
├── dist
│   └── index.js
├── index.ts
└── tsconfig.json

指定されている場合、すべてのグローバル（非モジュール）ファイルは、指定された単一出力ファイルに連結されます。

moduleがsystemまたはamdの場合、すべてのモジュールファイルも、すべてのグローバルコンテンツの後にこのファイルに連結されます。

注：moduleがNone、System、またはAMDでない限り、outFileは使用できません。このオプションは、CommonJSまたはES6モジュールのバンドルには使用できません。

生成されたコードでconst enum宣言を削除しません。const enumは、参照ではなく列挙値を出力することにより、アプリケーションの実行時のメモリフットプリント全体を削減する方法を提供します。

たとえば、このTypeScriptの場合

ts
const enum Album {
  JimmyEatWorldFutures = 1,
  TubRingZooHypothesis = 2,
  DogFashionDiscoAdultery = 3,
}
 
const selectedAlbum = Album.JimmyEatWorldFutures;
if (selectedAlbum === Album.JimmyEatWorldFutures) {
  console.log("That is a great choice.");
}Try

デフォルトのconst enumの動作は、任意のAlbum.Somethingを対応する数値リテラルに変換し、JavaScriptから列挙型への参照を完全に削除することです。

ts
"use strict";
const selectedAlbum = 1 /* Album.JimmyEatWorldFutures */;
if (selectedAlbum === 1 /* Album.JimmyEatWorldFutures */) {
    console.log("That is a great choice.");
}
 Try

preserveConstEnumsをtrueに設定すると、enumは実行時に存在し、数値も出力されます。

ts
"use strict";
var Album;
(function (Album) {
    Album[Album["JimmyEatWorldFutures"] = 1] = "JimmyEatWorldFutures";
    Album[Album["TubRingZooHypothesis"] = 2] = "TubRingZooHypothesis";
    Album[Album["DogFashionDiscoAdultery"] = 3] = "DogFashionDiscoAdultery";
})(Album || (Album = {}));
const selectedAlbum = 1 /* Album.JimmyEatWorldFutures */;
if (selectedAlbum === 1 /* Album.JimmyEatWorldFutures */) {
    console.log("That is a great choice.");
}
 Try

これにより、そのようなconst enumは基本的にソースコードの機能のみになり、実行時のトレースはありません。

verbatimModuleSyntaxに置き換えられました。

TypeScriptがインポートを使用していることを検出できない場合があります。たとえば、次のコードを考えてください。

ts
import { Animal } from "./animal.js";
eval("console.log(new Animal().isDangerous())");