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

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

このオプションは、プロジェクトが少数のファイルから構成されていて、グロブパターンを必要としない場合で有用です。 グロブパターンが必要な場合、includeを利用してください。

extendsの値は、別の継承対象の設定ファイルへのパスを含む文字列です。 Node.js におけるモジュール解決の流儀が用いられます。

ベースとなるファイルからの設定が最初に読み込まれ、続いて継承ファイルの設定によってオーバーライドされます。設定ファイル内のすべての相対パスは、元の設定ファイルを起点として解決されます。

継承した設定ファイルのfiles、includeおよびexcludeはベースとなる設定ファイルの内容を上書きします。 また、継承における循環参照は許容されません。

例

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はグロブパターンのためのワイルドカードをサポートしています:

• * ゼロ個以上の文字列にマッチ（ディレクトリセパレータは除く）
• ? 任意の 1 文字にマッチ（ディレクトリセパレータは除く）
• **/ 任意階層の任意ディレクトリにマッチ

グロブパターンがファイルの拡張子を含まない場合、サポートされる拡張子のみが含まれるようになります（例：.ts、.tsxと.d.tsはデフォルトでインクルードされ、.jsと.jsxはallowJsが設定された場合のみインクルードされます）。

includeの解決時にスキップさせるファイル名やパターンのリストを指定します。

重要: excludeはincludeの結果として、どのファイルが含まれるべきかのみに影響を与えます。 excludeに指定されたファイルは、コードでのimportやtypesでのインクルード、/// <reference ディレクティブ、filesリストの指定によって、コードベースの一部となり得ます。

excludeはコードベースに含まれているファイルの読み込みを防ぐための仕組みではありません。include設定の結果を変更するだけです。

プロジェクト参照は TypeScript のプログラムを小さい断片に分けて構造化するための手法です。 プロジェクト参照を用いると、ビルド時間やエディターとのインタラクションに必要な時間が大幅に改善され、コンポーネント間の論理分割が強制により、より洗練された方法でコードを整理できます。

プロジェクト参照がどのように動作するかについては、このハンドブックのProject Referencesを読んでください。

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

このオプションは、型の分析によって到達不可能と判断されたコードについてのエラーには影響しません。

false にセットすると、利用していない Label についての警告を無効化します。

JavaScript において Label を利用することは稀ですが、オブジェクトリテラルを記述しようとしたときに Label 構文になってしまうことがあります。

ts
function verifyAge(age: number) {
  // 'return'の記述が抜けている
  if (age > 18) {
    verified: true;
Unused label.7028Unused label.
  }
}Try

ファイルを ECMAScript の strict モードで解釈し、各ファイルへ”use strict”を出力することを保証します。

ECMAScript strictモードは ES5 で導入され、JavaScript エンジンが実行時にパフォーマンスを改善できるよう微調整されます。代わりにいくつかのエラーが無視されずにスローされるようになります。

With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on type or interfaces which have a ? prefix.

For example, this interface declares that there is a property which can be one of two strings: ‘dark’ or ‘light’ or it should not be in the object.

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

Without this flag enabled, there are three values which you can set colorThemeOverride to be: “dark”, “light” and undefined.

Setting the value to undefined will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn’t quite accurate; colorThemeOverride: undefined is not the same as colorThemeOverride not being defined. For example, "colorThemeOverride" in settings would have different behavior with undefined as the key compared to not being defined.

exactOptionalPropertyTypes makes TypeScript truly enforce the definition provided as an optional property:

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 文において、次の case へ処理を持ち越した場合にエラーを報告します。 switch 文内の空でない case 句がbreakまたはreturnを含むことを確約します。 これは、意図しない case への処理持ち越しによるバグを流出させない、ということ意味しています。

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) {
  // エラーにならない？
  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

When working with classes which use inheritance, it’s possible for a sub-class to get “out of sync” with the functions it overloads when they are renamed in the base class.

For example, imagine you are modeling a music album syncing system:

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

Then when you add support for machine-learning generated playlists, you refactor the Album class to have a ‘setup’ function instead:

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

In this case, TypeScript has provided no warning that download on SharedAlbum expected to override a function in the base class.

Using noImplicitOverride you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword override.

The following example has noImplicitOverride enabled, and you can see the error received when override is missing:

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 式でエラーを発生させます。

例えば、以下の Class は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

This setting ensures consistency between accessing a field via the “dot” (obj.key) syntax, and “indexed” (obj["key"]) and the way which the property is declared in the type.

Without this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:

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

Turning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.

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

The goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.

TypeScript には、オブジェクトにおいて未知のキーを持ちながらも値が既知であるプロパティをインデックスシグネチャで記述する方法があります。

ts
interface EnvironmentVars {
  NAME: string;
  OS: string;
 
  // 未知のプロパティは、次のようなインデックスシグネチャで扱うことができます。
  [propName: string]: string;
}
 
declare const env: EnvironmentVars;
 
// 既存のプロパティとして宣言されています
const sysName = env.NAME;
const os = env.OS;
      
const os: string
 
// 宣言されていませんが、インデックス
// シグネチャのおかげで、stringとして扱われます
const nodeEnv = env.NODE_ENV;
        
const nodeEnv: stringTry

noUncheckedIndexedAccessをオンにすると、型の未定義のフィールドにundefinedが追加されます。

ts
declare const env: EnvironmentVars;
 
// 既存のプロパティとして宣言されています
const sysName = env.NAME;
const os = env.OS;
      
const os: string
 
// 宣言されていませんが、インデックス
// シグネチャのおかげで、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フラグは、プログラムの正しさを強く保証するための幅広い型チェックの挙動を有効化します。 このオプションの有効化は、以降で述べるすべてのstrict モードファミリーオプションの有効化と等価です。 必要に応じて、個別の strict モードファミリーを無効化できます。

今後の TypeScript のバージョンがこのフラグの配下により厳密なチェックを導入するかもしれません。この場合、TypeScript のアップグレードにより、プログラムに新しい種類のエラーが発見されることもあるでしょう。 適切かつ可能な場合、この挙動を無効化するための対応するフラグも追加されます。

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

ts
// strictBindCallApplyが有効な場合
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
// strictBindCallApplyが無効な場合
function fn(x: string) {
  return parseInt(x);
}
 
// Note: エラーになりません。戻り値の型は'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;
 
// 安全でない代入
let func: StringOrNumberFunc = fn;
// 安全でない呼び出し - エラーとなります
func(10);Try

strictFunctionTypesを有効化すると、エラーが正しく検知されます:

ts
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
type StringOrNumberFunc = (ns: string | number) => void;
 
// 安全でない代入は抑止されます
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

私達はこの機能を開発する際、本質的に安全でない Class 階層を数多く見つけました。中には DOM のものも含まれていました。 このため、この設定はfunction構文で記述された関数にのみ適用され、メソッドとして記述された関数には適用されません:

ts
type Methodish = {
  func(x: string | number): void;
};
 
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
// 最終的に安全でない代入となりますが、エラー検知はされません
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

単純化してみると配列のfind関数が次のようになっていることから、2 つ目の例はエラーとなったのです:

ts
// strictNullChecks: trueのとき
type Array = {
  find(predicate: (value: any, index: number) => boolean): S | undefined;
};
// strictNullChecks: falseのとき、undefinedは型システムから取り除かれ、
// 常に結果が見つかるかのようにコードを書けるようになります
type Array = {
  find(predicate: (value: any, index: number) => boolean): S;
};

true に設定した場合、Class プロパティが宣言されているがコンストラクターで値がセットされていないときに、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;
    // 注 this.emailがセットされていません
  }
}Try

上記の場合:

• this.nameは具体的に設定されています。
• this.accountTypeはデフォルト値が設定されています。
• this.emailは値が設定されていないため、エラーとなります。
• this.addressはundefinedになりうる値として宣言されており、これは値の設定が必須でないことを意味しています。

In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from any to unknown. Allowing for code like:

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

This pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown is a Error subclass ahead of time. With the flag useUnknownInCatchVariables enabled, then you do not need the additional syntax (: unknown) nor a linter rule to try enforce this behavior.

In TypeScript 5.0, when an import path ends in an extension that isn’t a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of {file basename}.d.{extension}.ts. For example, if you are using a CSS loader in a bundler project, you might want to write (or generate) declaration files for those stylesheets:

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

By default, this import will raise an error to let you know that TypeScript doesn’t understand this file type and your runtime might not support importing it. But if you’ve configured your runtime or bundler to handle it, you can suppress the error with the new --allowArbitraryExtensions compiler option.

Note that historically, a similar effect has often been achievable by adding a declaration file named app.css.d.ts instead of app.d.css.ts - however, this just worked through Node’s require resolution rules for CommonJS. Strictly speaking, the former is interpreted as a declaration file for a JavaScript file named app.css.js. Because relative files imports need to include extensions in Node’s ESM support, TypeScript would error on our example in an ESM file under --moduleResolution node16 or nodenext.

For more information, read up the proposal for this feature and its corresponding pull request.

--allowImportingTsExtensions allows TypeScript files to import each other with a TypeScript-specific extension like .ts, .mts, or .tsx.

This flag is only allowed when --noEmit or --emitDeclarationOnly is enabled, since these import paths would not be resolvable at runtime in JavaScript output files. The expectation here is that your resolver (e.g. your bundler, a runtime, or some other tool) is going to make these imports between .ts files work.

allowUmdGlobalAccessを true に設定すると、モジュールの内部から UMD へグローバルにアクセスできるようになります。モジュールファイルとは、import や export を使っているファイルのことです。このフラグを利用しない場合、UMD モジュールを利用するには import 宣言文が必要です。

このフラグの利用例は、特定のライブラリ（jQuery や Lodash など）が常に実行時に利用可能であると分かっているが、import 文ではそのライブラリにアクセスできないような web プロジェクトです。

絶対パス参照でないモジュール名を解決するための基点となるディレクトリを設定できます。

絶対パスで解決するために、ルートフォルダを決めることもできます。すなわち、

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

"baseUrl": "./"とすると、このプロジェクト内では、TypeScript はtsconfig.jsonと同じフォルダからファイルの探索を行います。

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

"../"や"./"のような毎度のインポート文にうんざりしていたり、 ファイルを移動するときにインポート文を変更する必要がある場合、このオプションは修正するための良い方法です。

--customConditions takes a list of additional conditions that should succeed when TypeScript resolves from an exports or imports field of a package.json. These conditions are added to whatever existing conditions a resolver will use by default.

For example, when this field is set in a tsconfig.json as so:

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

Any time an exports or imports field is referenced in package.json, TypeScript will consider conditions called my-condition.

So when importing from a package with the following package.json

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

TypeScript will try to look for files corresponding to foo.mjs.

This field is only valid under the node16, nodenext, and bundler options for --moduleResolution.

より詳細については、ハンドブックのModulesの章を参照してください。おそらく"CommonJS"が求められるでしょう。

次のファイルに対する出力の例をいくつか示します:

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 / ES2020

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

モジュール解決の方法を’node’（Node.js）または’classic’（TypeScript pre-1.6）から設定します。おそらく利用する必要はないでしょう。

Provides a way to override the default list of file name suffixes to search when resolving a module.

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

Given the above configuration, an import like the following:

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

TypeScript will look for the relative files ./foo.ios.ts, ./foo.native.ts, and finally ./foo.ts.

Note the empty string "" in moduleSuffixes which is necessary for TypeScript to also look-up ./foo.ts.

This feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing moduleSuffixes.

デフォルトでは、TypeScript は起動時に与えられたファイルについてimportと<referenceディレクティブを確認し、解決されたファイルをプログラムに追加します。

noResolveが設定されているとき、このプロセスは発生しなくなります。 しかし、import文は正しいモジュールを解決しているかどうかチェックされるため、これが満たされているかどうかを他の方法で確認する必要があります。

In JavaScript it’s possible to import a module without actually importing any values from it.

ts
import "some-module";

These imports are often called side effect imports because the only useful behavior they can provide is by executing some side effect (like registering a global variable, or adding a polyfill to a prototype).

By default, TypeScript will not check these imports for validity. If the import resolves to a valid source file, TypeScript will load and check the file. If no source file is found, TypeScript will silently ignore the import.

This is surprising behavior, but it partially stems from modeling patterns in the JavaScript ecosystem. For example, this syntax has also been used with special loaders in bundlers to load CSS or other assets. Your bundler might be configured in such a way where you can include specific .css files by writing something like the following:

tsx
import "./button-component.css";
export function Button() {
  // ...
}

Still, this masks potential typos on side effect imports.

When --noUncheckedSideEffectImports is enabled, TypeScript will error if it can’t find a source file for a side effect import.

ts
import "oops-this-module-does-not-exist";
//     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// error: Cannot find module 'oops-this-module-does-not-exist' or its corresponding
//        type declarations.

When enabling this option, some working code may now receive an error, like in the CSS example above. To work around this, users who want to just write side effect imports for assets might be better served by writing what’s called an ambient module declaration with a wildcard specifier. It would go in a global file and look something like the following:

ts
// ./src/globals.d.ts
// Recognize all CSS files as module imports.
declare module "*.css" {}

In fact, you might already have a file like this in your project! For example, running something like vite init might create a similar vite-env.d.ts.

baseUrlからの相対的な検索場所にインポートを再マッピングするエントリです。pathsについてより網羅的な記述はハンドブックに記載されています。

pathsにより、TypeScript がどのようにrequire/importからインポートを解決すべきかを定義できます。

{
  "compilerOptions": {
    "baseUrl": ".", // "paths"を設定する場合、このオプションも設定が必要です。
    "paths": {
      "jquery": ["node_modules/jquery/dist/jquery"] // このマッピングは"baseUrl"からの相対パスです。
    }
  }
}

この設定は、import "jquery"と記述できるようにし、すべての正しい型がローカルから取得されるようになります。

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

この例は、TypeScript に対して、ファイルリゾルバーへコードを見つけるためのカスタムプレフィクスによる補助をさせています。 このパターンは、コードベース内で長い相対パスを避けるために利用できます。

‘.json’拡張子のファイルをモジュールとしてインポートできるようにします。Node のプロジェクトで一般的に利用されている手法です。 このオプションは、import時に静的な JSON の構造から型を生成します。

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

ts
// @filename: settings.json
{
    "repo": "TypeScript",
    "dry": false,
    "debug": false
}
// @filename: index.ts
import settings from "./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.
 
settings.debug === true;
settings.dry === 2;Try

このオプションを有効にすると JSON のインポートが可能となり、JSON ファイルの型を検査できるようになります。

ts
// @filename: settings.json
{
    "repo": "TypeScript",
    "dry": false,
    "debug": false
}
// @filename: index.ts
import settings from "./settings.json";
 
settings.debug === true;
settings.dry === 2;
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.Try

--resolvePackageJsonExports forces TypeScript to consult the exports field of package.json files if it ever reads from a package in node_modules.

This option defaults to true under the node16, nodenext, and bundler options for --moduleResolution.

--resolvePackageJsonImports forces TypeScript to consult the imports field of package.json files when performing a lookup that starts with # from a file whose ancestor directory contains a package.json.

This option defaults to true under the node16, nodenext, and bundler options for --moduleResolution.

Rewrite .ts, .tsx, .mts, and .cts file extensions in relative import paths to their JavaScript equivalent in output files.

For more information, see the TypeScript 5.7 release notes.

デフォルト値: 型定義ファイルでないすべての入力ファイルの中での最長の共通パス。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.ts
│   ├── b.ts
│   ├── sub
│   │   ├── c.ts

ただし、出力ディレクトリ内にcoreを含めることを意図している場合があります。 rootDir: "."をtsconfig.jsonに設定すると、TypeScript は次のツリー構造を出力します:

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

重要なこととして、rootDirはどのファイルがコンパイルに含められるかに影響しません。 tsconfig.jsonのinclude、excludeやfiles設定との相互作用はありません。

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

例えば、次のツリー構造があったとしましょう:

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

rootDirをcoreに、includeを*に設定すると、outDirの外部（i.e. ../helpers.ts）に出力する必要のあるファイル（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 を出力するかには影響しません。 実行時に相対パスを使って動作可能であるという仮定がエミュレートされるだけです。

デフォルトでは、表示されているすべての”@types“パッケージがコンパイル時にインクルードされます。 プロジェクトを囲んでいる任意のフォルダのnode_modules/@types内のパッケージが表示されているとみなされます。 例えば、./node_modules/@types/、../node_modules/@types/、../../node_modules/@types/に存在するパッケージが該当します。

typeRootsを設定すると、typeRoots配下のパッケージのみがインクルードされます。例えば:

json
{
  "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を設定すると、リストに列挙したパッケージのみがインクルードされます。例えば:

json
{
  "compilerOptions": {
    "types": ["node", "lodash", "express"]
  }
}

このtsconfig.jsonファイルは、./node_modules/@types/nodeと./node_modules/@types/lodashと./node_modules/@types/expressのみをインクルードするようになります。 node_modules/@types/*配下にある他のパケージはインクルードされません。

この機能はtypeRootsと違い、インクルードしたい types パッケージだけを厳密に指定できます。一方、typeRootsは必要としている特定のフォルダを指定できます。

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

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 などのエディターは、Go to Definitionのような機能で元の.tsファイルにジャンプできるようになります。

プエジェクト参照機能を利用している場合、このオプションの有効化を強く推奨します。

ダウンレベル化は、古いバージョンの JavaScript にトランスパイルするという意味の TypeScript の用語です。 このフラグは、モダンな JavaScript における新しいコンセプトの反復処理が古い JavaScript での実行時にどのように実装されるかについて、より正確なサポートを有効化します。

ECMAScript 6 では、いくつかの新しい反復処理のための基本構文が加えられました: for / ofループ（for (el of arr)）、配列のスプレッド（[a, ...b]）、引数のスプレッド（fn(...args)）、Symbol.iteratorです。 --downlevelIterationは、Symbol.iteratorの実装が存在している場合、ES5 環境におけるこれらの基本的な反復処理をより正確に利用可能になります。

例: for / ofでの効果

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 6 の挙動と 100%合致しているわけではありません。 特定の文字列、たとえば絵文字（😜）は、.lengthは 2（もしくはそれ以上！）ですが、for-ofループでは 1 文字分として反復されねばなりません。 より詳細な解説はJonathan New による blogを参照してください。

downlevelIterationが有効であるとき、TypeScript はSymbol.iteratorの実装（ネイティブまたはポリフィル）をチェックするヘルパー関数を利用します。 もし実装が存在しなければ、index を利用する反復処理へフォールバックします。

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

Note: Symbol.iteratorが実行時に存在しない場合、downlevelIterationは ECMAScript への準拠を保証しません。

例: 配列のスプレッドに対する効果

次のスプレッドされた配列について:

js
// 要素が1で、その後にarr2の要素が続く新しい配列を作成します
const arr = [1, ...arr2];

説明に沿って、次のように ES5 へダウンレベル化できます:

js
// 同じですよね？
const arr = [1].concat(arr2);

しかし、これは特定の稀なケースにおいてはっきりとした違いがあります。 例えば、配列に「穴」がある場合、スプレッドでは欠落したインデックスが独自のプロパティとして作成されますが、concatを利用した場合は作成されません:

js
// 「1」の要素が欠落している配列を作成します
let missing = [0, , 1];
let spreaded = [...missing];
let concated = [].concat(missing);
// true
"1" in spreaded;
// false
"1" in concated;

for / ofと同様、downlevelIterationは（利用可能であれば）Symbol.iteratorを使い、より正確に ES6 の挙動を模倣します。

TypeScript がファイルを書き込むときにバイトオーダーマーク（BOM）を出力するかどうかを制御します。 一部の実行環境では JavaScript ファイルを正しく解釈するために、BOM が必要となりますが、他の実行環境では BOM の存在を許容しません。 デフォルト値のfalseは一般的に最適な値ですが、必要であれば変更できます。

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

この設定は 2 つのケースで有用です:

• JavaScript を生成するために、TypeScript 以外のトランスパイラを使っているとき
• 利用者向けにd.tsファイルを出力するためだけに TypeScript を使っているとき

Class の継承、配列やオブジェクトのスプレッド構文、async の処理など、特定のダウンレベル処理に対して、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が利用できます。

設定すると、TypeScript はソースマップを.js.mapファイルへ出力するのではなく、ソースマップの内容を.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ファイルの内容を文字列としてソースマップに埋め込みます。 このオプションは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を使って、ヘルパ関数をインポートする代わりに、グローバルスコープに使用するヘルパ関数のための実装を提供し、ヘルパ関数が出力されるのを完全に無効にできます。

例えば、このasync関数を ES5 で実行するためには、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 = Object.create((typeof Iterator === "function" ? Iterator : Object).prototype);
    return g.next = verb(0), g["throw"] = verb(1), g["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の場合:

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

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

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

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

もしmoduleがsystemかamdの場合、この単一出力ファイルのグローバルなコンテンツの後ろにすべてのモジュールファイルも結合されます。

Note: moduleがNone、System、AMDのいずれかでない限り、outFileは使用できません。 このオプションは CommonJS または ES6 Modules にバンドルする目的では使用できません。

コード生成時にconst enumの定義を取り除かないようにします。 const enumは、参照ではなく 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 コードから完全に元の Enum への参照を除去します。

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 enumsは実行時に追跡されないソースコードのみの機能になります。

TypeScript ファイルを JavaScript へ変換するときに、すべてのコメントを除去します。デフォルト値はfalseです。

例えば、次の JSDoc コメントを持つ TypeScript ファイルに対して:

ts
/** ポルトガル語に翻訳された'Hello world' */
export const helloWorldPTBR = "Olá Mundo";

removeCommentsがtrueであるとき、次のようになります:

ts
export const helloWorldPTBR = "Olá Mundo";
 Try

removeCommentsが設定されていない・またはfalseであるときは次のようになります:

ts
/** ポルトガル語に翻訳された'Hello world' */
export const helloWorldPTBR = "Olá Mundo";
 Try

つまり、コメントは JavaScript コードに表示されるようになります。

ソースマップファイルの生成を有効化します。 これらのファイルにより、出力された JavaScript ファイルが実際に動作させるときに、デバッガーやその他のツールが元の TypeScript ソースファイルを表示できるようになります。 ソースマップファイルは.js.map（または.jsx.map）として、対応する.jsファイルとともに出力されます。

次の例のように、.jsファイルには、外部ツールにソースマップファイルがどこにあるかを示すためのソースマップコメントが含まれるようになります:

ts
// helloWorld.ts
export declare const helloWorld = "hi";

sourceMapをtrueに設定してコンパイルすると、次の JavaScript ファイルが生成されます:

js
// helloWorld.js
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.helloWorld = "hi";
//# sourceMappingURL=// helloWorld.js.map