TSConfig リファレンス紹介

ディレクトリ内の TSConfig ファイルは、TypeScript や JavaScript のプロジェクトルートであることを示します。 TSConfig ファイルは、tsconfig.jsonjsconfig.json のいずれかが利用可能です。どちらを選んでも同じ挙動、同じ設定変数をセットできます。

このページは TSConfig ファイルで利用できるフラグを余す所なくカバーしています。このページは、フラグ毎の概要から始まり、JSON ファイルのルート属性、オプションの大部分を占める compilerOptions を説明し、最後は watchOptions で締めくくられます。


Root Fields

Starting up are the root options in the TSConfig - these options relate to how your TypeScript or JavaScript project is set up.

#ファイルインクルージョン

これらの設定は TypeScript が適切なファイルを確実に選択できるようにします。

# Exclude - exclude

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

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

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

  • Default:

    ["node_modules", "bower_components", "jspm_packages"], plus the value of outDir if one is specified.

  • Related:

    include, files

# Extends - extends

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

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

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

configs/base.json:

{ "": { "": true, "": true } }

tsconfig.json:

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

tsconfig.nostrictnull.json:

{ "": "./tsconfig", "": { "": false } }
  • Default:

    false

  • Released:

    2.1

# Files - files

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

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

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

# Include - include

プログラムに含めるファイル名またはパターンのリストを指定します。 ファイル名は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

includeexcludeはグロブパターンのためのワイルドカードをサポートしています:

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

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

  • Default:

    [] if files is specified, otherwise ["**/*"]

  • Related:

    files, exclude

  • Released:

    2.0

# References - references

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

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

  • Default:

    false

# Type Acquisition - typeAcquisition

エディターに JavaScript プロジェクトが存在する場合、TypeScript は@typesで定義される DefinitelyTyped から提供されるファイルを用いて、node_modulesのための型ファイルを自動で提供します。 これは自動型取得と呼ばれており、また設定のtypeAcquisitionを使ってカスタマイズできます。

この機能を無効化したりカスタマイズする場合、プロジェクトのルートにjsconfig.jsonファイルを作成してください:

json
{ "typeAcquisition": { "enable": false } }

プロジェクトに含めるべき特定のモジュールがある場合(それがnode_modulesには存在しない場合):

json
{ "typeAcquisition": { "include": ["jest"] } }

モジュールが自動で取得されるべきでない場合。例えば、そのライブラリがnode_modulesに含まれてはいるが、チームでこのライブラリを利用しないことを合意している場合:

json
{ "typeAcquisition": { "exclude": ["jquery"] } }
  • Default:

    false

Compiler Options

These options make up the bulk of TypeScript’s configuration and it covers how the language should work.

#プロジェクト設定

これらの設定はプロジェクト実行時に期待される挙動を定義します。JavaScript ファイルがどこにどのように出力されるかや、既存 JavaScript コードとの統合レベルが設定されます。

# Allow JS - allowJs

.ts.tsxファイルだけでなく、JavaScript ファイルをプロジェクトへインポートできるようにします。例えば、次の JS ファイルを:

// @filename: card.js export const defaultCardDeck = "Heart";Try

TypeScript のファイルへインポートするとエラーとなるでしょう:

// @filename: index.ts import { defaultCardDeck } from "./card"; console.log(defaultCardDeck);Try

allowJsを付与するとインポートは成功します:

// @filename: index.ts import { defaultCardDeck } from "./card"; console.log(defaultCardDeck);Try

このフラグを使うと、.ts.tsxファイルが既存の JavaScript ファイルと共存可能となり、TypeScript ファイルを JS プロジェクトへ徐々に追加できるようになります。

# Check JS - checkJs

allowJsと連携動作します。checkJsが有効化されている場合、JavaScript ファイル内のエラーが報告されるようになります。 これは、プロジェクトに含まれるすべての JavaScript ファイルの先頭で// @ts-checkを付与することと等価です。

例えば、TypeScript のparseFloat定義から、次の例は誤った JavaScript です。

js
// parseFloatはstringのみを受け付けます module.exports.pi = parseFloat(3.124);

このファイルが TypeScript のモジュールにインポートされた場合:

// @filename: constants.js module.exports.pi = parseFloat(3.124); // @filename: index.ts import { pi } from "./constants"; console.log(pi);Try

いかなるエラーも報告されません。しかし、もしcheckJsを有効化すれば、JavaScript ファイルで発生したエラーメッセージを受け取れるようになります。

// @filename: constants.js Argument of type 'number' is not assignable to parameter of type 'string'.2345Argument of type 'number' is not assignable to parameter of type 'string'.module.exports.pi = parseFloat(3.124); // @filename: index.ts import { pi } from "./constants"; console.log(pi);Try

# Composite - composite

compositeオプションは、ビルドツール(--buildモードでの TypeScript 自体を含む) がプロジェクトがビルドされているかどうかを迅速に判断できるようにするために特定の制約を適用します。

この設定が有効なとき:

  • 明示的に設定されていないrootDirのデフォルト値はtsconfig.jsonファイルを含むディレクトリとなります。
  • すべての実装ファイルは、includeパターンにマッチするかfilesリストに含まれなくてはなりません。この制約に違反した場合、tscはどのファイルが指定されていないかを通知します。
  • declarationのデフォルト値がtrueになります。

TypeScript のプロジェクト機能についてのドキュメントはハンドブックから参照できます。

# Declaration - declaration

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

declarationtrueに設定している場合、次の TypeScript コードに対してコンパイラーを実行すると:

export let helloWorld = "hi";Try

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

export let helloWorld = "hi";Try

対応するhelloWorld.d.tsファイルは次のとおりです:

export declare let helloWorld: string;Try

JavaScript ファイルに対応する.d.tsを利用する場合、emitDeclarationOnlyoutDirを設定することで JavaScript ファイルを上書きしないようにできます。

# Declaration Map - declarationMap

元の.tsソースファイルにマップされる.d.tsのソースマップを生成します。

これにより、VS Code などのエディターは、Go to Definitionのような機能で元の.tsファイルにジャンプできるようになります。

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

  • Default:

    false

  • Released:

    2.9

# Downlevel Iteration - downlevelIteration

ダウンレベル化は、古いバージョンの 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ループへダウンレベルトランスパイルされます:

"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 を利用する反復処理へフォールバックします。

"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 の挙動を模倣します。

# Import Helpers - importHelpers

Class の継承、配列やオブジェクトのスプレッド構文、async の処理など、特定のダウンレベル処理に対して、TypeScript はヘルパーコードを利用します。 デフォルトでは、ヘルパーは利用されているファイルに挿入されます。 同じヘルパーが異なる多くのモジュールで利用されている場合、コードの重複となる可能性があります。

importHelpersフラグが有効な場合、ヘルパー関数はtslibモジュールからインポートされます。 tslibを実行時にインポート可能であることを確認する必要があります。 この設定はモジュールに作用します。グローバルなスクリプトファイルはモジュールをインポートしません。

例えば、次の TypeScript について:

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

downlevelIterationimportHelpersが false のときは次の出力となります:

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) { for (var i = 0, il = from.length, j = to.length; i < il; i++, j++) to[j] = from[i]; return to; }; export function fn(arr) { var arr2 = __spreadArray([1], __read(arr)); }Try

downlevelIterationimportHelpersの両方を有効化すると、次の出力になります:

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

これらのヘルパー関数の独自実装を与える場合、noEmitHelpersが利用できます。

# Incremental - incremental

最新のコンパイルでのプロジェクトグラフ情報をディスクにファイルとして保存するように TypeScript に指示します。 このオプションはコンパイルの出力先として指定されたフォルダに .tsbuildinfo のファイル群を作成します。 これらのファイルはコンパイルされた JavaScript が実行時に利用することはなく、安全に削除できます。このフラグの詳細については3.4 リリースノートで確認できます。

このファイル群の出力先フォルダを設定する場合、tsBuildInfoFileオプションを利用してください。

# Isolated Modules - isolatedModules

TypeScript を TypeScript コードから JavaScript コードを生成する用途で利用可能な一方、Babelなどの他のトランスパイラの利用も一般的です。 しかし、他のトランスパイラは一度に1ファイルのみを扱うため、全体の型システムの知識に依存したコード変換はできません。 ビルドツールで用いられる TypeScript のts.transpileModuleAPI についても、この制約が課せられます。

この制限は、TypeScript のconst enumnamespaceのような機能を利用したときに実行時の問題を引き起こします。 isolatedModulesフラグは、単一ファイルのトランスパイル処理で正しく解釈できないコードが書かれたときに、TypeScript が警告を与えるように設定します。

このフラグは、コードの挙動を変更せず、また、TypeScript のチェック・出力プロセスの挙動も変更しません。

isolatedModulesが有効な場合に機能しないコードをいくつか例示します。

値でない識別子のエクスポート

TypeScript では、をインポートしてからエクスポートできます:

import { someType, someFunction } from "someModule"; someFunction(); export { someType, someFunction };Try

someTypeという値は存在しないため、出力されたexport文はエクスポートを試行しません(これは JavaScript の実行時エラーになります):

js
export { someFunction };

単一ファイルのトランスパイラは、someTypeが値なのかどうかを知らないため、型のみを参照した名前をエクスポートするエラーになります。

Module でないファイル

isolatedModulesが設定されている場合、すべての実装ファイルはModuleでなくてはなりません(import/exportの形式を利用しているという意味)。ファイルが Module でない場合、エラーが発生します。

function fn() {} 'index.ts' cannot be compiled under '--isolatedModules' because it is considered a global script file. Add an import, export, or an empty 'export {}' statement to make it a module.1208'index.ts' cannot be compiled under '--isolatedModules' because it is considered a global script file. Add an import, export, or an empty 'export {}' statement to make it a module.Try

この制約は.d.tsファイルには適用されません。

const enumメンバーへの参照

TypeScript では、const enumのメンバへ参照すると、出力される JavaScript では、その参照は実際の値へと置換されます。TypeScript による変換は次のようになります:

declare const enum Numbers { Zero = 0, One = 1, } console.log(Numbers.Zero + Numbers.One);Try

JavaScript では:

"use strict"; console.log(0 + 1);Try

他のトランスパイラはメンバー値の知識無しにNumbersへの参照を置換できません。これが取り残されると、実行時のエラーとなります(なぜならNumbersオブジェクトは実行時に存在しないからです)。 したがって、isolatedModulesが設定されている場合、const enumメンバーへのアンビエント参照はエラーとなります。

  • Default:

    false

# JSX - jsx

JSX 構文がどのように JavaScript ファイルに出力されるかを設定します。 .tsxで終わるファイルの JS 出力にのみ影響します。

  • preserve: JSX を変更せずに.jsxファイルを出力します
  • react: JSX を等価なreact.createElementに変換して.jsファイルを出力します
  • react-native: JSX を変更せずに、.jsファイルを出力します

# Lib - lib

TypeScript には組み込みの JS API(例:Math)の型定義や、ブラウザーで利用される API(例:document)の型定義がデフォルトで組み込まれています。 指定したtargetに合致する新しい JS 機能の API の型定義も TypeScript には組み込まれています。例えば、Mapの定義はtargetES6かそれよりも新しいときに利用可能です。

いくつかの理由により、これらを変更したい場合があります:

  • プログラムはブラウザーで動作させる必要がないため、"dom"の型定義が不要である
  • 利用している実行環境では特定の JavaScript API を提供しているが(Polyfill を利用しているかもしれません)、指定された ECMAScript のすべての構文をサポートしているわけではない
  • より上位の ECMAScript バージョンについて、すべてではなく、部分的な Polyfill や実装が利用可能である

High Level libraries

Name 内容
ES5 ES3 と ES5 のすべての機能を利用するための型定義。
ES2015 ES2015(ES6)で利用可能な API - array.findPromiseProxySymbolMapSetReflectなど。
ES6 “ES2015”のエイリアス
ES2016 ES2016 で利用可能な API - array.includeなど。
ES7 “ES2016”のエイリアス
ES2017 ES2017 で利用可能な API - Object.entriesObject.valuesAtomicsSharedArrayBufferdate.formatToParts、typed arrays など。
ES2018 ES2018 で利用可能な API - async iterables、promise.finallyIntl.PluralRulesrexexp.groupsなど。
ES2019 ES2019 で利用可能な API - array.flatarray.flatMapObject.fromEntriesstring.trimStartstring.trimEndなど。
ES2020 ES2020 で利用可能な API - string.matchAllなど。
ESNext ESNext で利用可能な API - JavaScript の仕様変遷によって内容は変化します。
DOM DOMの型定義 - windowdocumentなど。
WebWorker WebWorkerコンテキストで利用可能な API
ScriptHost Windows Script Hosting Systemの API

個別のライブラリコンポーネント

Name
DOM.Iterable
ES2015.Core
ES2015.Collection
ES2015.Generator
ES2015.Iterable
ES2015.Promise
ES2015.Proxy
ES2015.Reflect
ES2015.Symbol
ES2015.Symbol.WellKnown
ES2016.Array.Include
ES2017.object
ES2017.Intl
ES2017.SharedMemory
ES2017.String
ES2017.TypedArrays
ES2018.Intl
ES2018.Promise
ES2018.RegExp
ES2019.Array
ES2019.Full
ES2019.Object
ES2019.String
ES2019.Symbol
ES2020.Full
ES2020.String
ES2020.Symbol.wellknown
ESNext.AsyncIterable
ESNext.Array
ESNext.Intl
ESNext.Symbol

もしこのリストが古くなっている場合は、完全なリストをTypeScript source codeで読むことができます。

  • Allowed:

    See main content

  • Related:

    noLib

  • Released:

    2.0

# Module - module

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

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

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

CommonJS

"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

(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

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

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

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

    CommonJS (default if target is ES3 or ES5),
    ,
    ES6/ES2015 (synonymous, default for target ES6 and higher),
    ,
    ES2020,
    None,
    UMD,
    AMD,
    System,
    ESNext

  • Related:

    moduleResolution

  • Released:

    1.0

# No Emit - noEmit

JavaScript ソースコード、ソースマップ、型定義のファイルを出力しないようにします。

これにより、Babelswcなどの TypeScript ファイルを JavaScript 環境内で実行可能なファイルへ変換するための別のツールを追加できます。

TypeScript をエディター統合やソースコードの型チェックツールとして利用できるようになります。

  • Default:

    false

# Out Dir - outDir

設定すると、.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

# Out File - outFile

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

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

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

# Plugins - plugins

エディタ内部で動作させる Language Service のプラグインを列挙します。

Language Service プラグインを用いることで、ユーザーは TypeScript ファイルから追加情報を受け取ることができます。プラグインは、TypeScript とエディタ間でやりとりされているメッセージを拡張したり、プラグイン独自エラーメッセージを提供できます。

例:

  • ts-sql-plugin — テンプレート文字列による SQL ビルダについて、SQL の構文チェックを追加します。
  • typescript-styled-plugin — テンプレート文字列内部の CSS を構文チェック機能を提供します。
  • typescript-eslint-language-service — eslint のエラーメッセージを出力や、出力されたエラーメッセージの修正機能を提供します。
  • ts-graphql-plugin — テンプレート文字列内部の GraphQL クエリについて、バリデーションと自動補完機能を提供します。

VS Code には、拡張のためのLnguage Service プラグインの自動読込 機能があるため、tsconfig.jsonにプラグインの定義を書かずにエディタ上でプラグインを動作させることもできます。

    # Remove Comments - removeComments

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

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

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

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

    export const helloWorldPTBR = "Olá Mundo";Try

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

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

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

    • Default:

      false

    # Root Dir - rootDir

    デフォルト値: 型定義ファイルでないすべての入力ファイルの中での最長の共通パス。compositeが設定されている場合、この値の代わりにtsconfig.jsonを含むディレクトリがデフォルトとなります。

    TypeScript はファイルをコンパイルするとき、入力ディレクトリ内のディレクトリ構造が同じになるように出力ディレクト内の構造を保ちます。

    例えば、いくつかの入力ファイルがあったとしましょう:

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

    推定されるrootDirの値は、型定義ファイルでないすべての入力ファイルの中での最長の共通パス、この例ではcore/となります。

    outDirdistだったとすると、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.jsonincludeexcludefiles設定との相互作用はありません。

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

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

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

    rootDircoreに、include*に設定すると、outDir外部(i.e. ../helpers.ts)に出力する必要のあるファイル(helpers.ts)が生まれるため、エラーとなります。

    • Default:

      Computed from the list of input files

    • Released:

      1.5

    # Source Map - sourceMap

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

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

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

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

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

    この設定は次のような json 形式のマップファイルも生成します:

    json
    // helloWorld.js.map { "version": 3, "file": "ex.js", "sourceRoot": "", "sources": ["../ex.ts"], "names": [], "mappings": ";;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA" }
    • Default:

      false

    # Target - target

    モダンブラウザーはすべての ES6 機能をサポートしているため、ES6は良い選択です。 もし、コードをより古い環境へデプロイするのであれば、より下位の値を、逆により新しい環境での動作が保証される場合は、より上位の値をターゲットとして選択してください。

    target設定は、どの JS 機能が古い JavaScript 構文にトランスパイルされ、どの機能がそのまま残されるかを変更します。 例えばtargetが ES5 以下である場合、アロー関数() => thisは等価なfunction式へ変換されます。

    targetの変更はlibのデフォルト値も変更します。 必要に応じてtargetlibの値を組み合わせることも可能ですが、簡単にtargetの値のみを設定することも可能です。

    もし動作環境が Node.js のみであるならば、Node のベースバージョン毎に推奨されるtargetは次のとおりです:

    Name Supported Target
    Node 8 ES2017
    Node 10 ES2018
    Node 12 ES2019

    この表はnode.greenのデータベースを元に作成しています。

    ESNext という特別な値は TypeScript がサポートしている最新のターゲットバージョンを参照します。 この設定値は、異なる TypeScript のバージョン間におけるターゲットバージョンの一致を意味せず、アップグレード予測が困難になる可能性があるため、注意して利用する必要があります。

    • Default:

      ES3

    • Allowed:

      ES3 (default),
      ES5,
      ES6/ES2015 (synonymous),
      ES7/ES2016,
      ES2017,
      ES2018,
      ES2019,
      ES2020,
      ESNext

    • Released:

      1.0

    # TS Build Info File - tsBuildInfoFile

    この設定により、インクリメンタルコンパイル情報を複合プロジェクトの一部として保存するためのファイルを指定できるため、より大きな TypeScript コードベースを迅速に構築できます。 複合プロジェクトについてはハンドブックでより詳しく知ることができます。

    このオプションは、TypeScript がプロジェクトのビルド状態を追跡するためのファイルをディスクのどこに保存するかを設定します。 デフォルトは、JavaScript ファイルの出力先と同じフォルダに保存されます。

    #厳密なチェック

    ビルド時に利用可能なすべての改善を有効化するため、strictオプションの利用を推奨します。

    TypeScript は幅広い JavaScript パターンと、デフォルトで様々なスタイルの柔軟性を許容しています。 コードベースの安全性と潜在的なスケーラビリティは、これらのテクニックとしばしば相反します。

    サポートされる JavaScript の多様さにより、TypeScript を新しいバージョンへアップグレードすると 2 種類のエラーが明らかになるでしょう:

    • すでにコードベースに存在していたエラー。TypeScript の JavaScript に対する理解が洗練されて発見されます。
    • 新しい問題領域に取り組む一連の新しいエラー。

    通常、TypeScript は後者のエラーに対するコンパイラフラグを追加しますが、デフォルトでは有効化しません。

    # Always Strict - alwaysStrict

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

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

    • Recommended:

      True

    • Default:

      false, unless strict is set

    • Related:

      strict

    • Released:

      2.1

    # No Implicit Any - noImplicitAny

    いくつかの型アノテーションが存在しないケースにおいて、TypeScript は変数の型が推論できないときに、any型へフォールバックします。

    このため、エラーを見逃す可能性があります。例えば:

    function fn(s) { // エラーにならない? console.log(s.subtr(3)); } fn(42);Try

    ただし、noImplicitAnyを有効化すると、TypeScript は型がanyに推論されるときは常にエラーを発生させます:

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

      True

    • Default:

      false, unless strict is set

    • Related:

      strict

    # No Implicit This - noImplicitThis

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

    例えば、以下の Class はthis.widththis.heightにアクセスする関数を返しています。 しかし、getAreaFunctionの内側の関数内でのコンテキストにおけるthisは Rectangle のインスタンスではありません。

    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
    • Recommended:

      True

    • Default:

      false, unless strict is set

    • Related:

      strict

    • Released:

      2.0

    # Strict - strict

    strictフラグは、プログラムの正しさを強く保証するための幅広い型チェックの挙動を有効化します。 このオプションの有効化は、以降で述べるすべてのstrict モードファミリーオプションの有効化と等価です。 必要に応じて、個別の strict モードファミリーを無効化できます。

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

    # Strict Bind Call Apply - strictBindCallApply

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

    // 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を返します:

    // strictBindCallApplyが無効な場合 function fn(x: string) { return parseInt(x); } // Note: エラーになりません。戻り値の型は'any'です。 const n = fn.call(undefined, false);Try
    • Recommended:

      True

    • Default:

      false, unless strict is set

    • Related:

      strict

    • Released:

      3.2

    # Strict Function Types - strictFunctionTypes

    有効化すると、このフラグは関数のパラメータをより正しくチェックするようになります。

    次はstrictFunctionTypesが無効な場合の基本的な例です:

    function fn(x: string) { console.log("Hello, " + x.toLowerCase()); } type StringOrNumberFunc = (ns: string | number) => void; // 安全でない代入 let func: StringOrNumberFunc = fn; // 安全でない呼び出し - エラーとなります func(10);Try

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

    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構文で記述された関数にのみ適用され、メソッドとして記述された関数には適用されません:

    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
    • Recommended:

      True

    • Default:

      false, unless strict is set

    • Related:

      strict

    • Released:

      2.6

    # Strict Null Checks - strictNullChecks

    strictNullChecksfalseのとき、nullundefinedは言語により事実上無視されます。 これは実行時の予期しないエラーの原因となります。

    strictNullCheckstrueのとき、nullundefinedはそれ自身に明示的な型が与えられ、具体的な値を期待して利用しようとした場合にエラーとなります。

    例えば、次の TypeScript コードのusers.findは実際にユーザーを見つけられる保証がありません。 しかし、ユーザーを見つけられたかのようにコードを書くことができます:

    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

    strictNullCheckstrueにすると、loggedInUserを利用する前に存在を確認していないことを示すエラーが発生します。

    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); Object is possibly 'undefined'.2532Object 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; };
    • Recommended:

      True

    • Default:

      false, unless strict is set

    • Related:

      strict

    • Released:

      2.0

    # Strict Property Initialization - strictPropertyInitialization

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

    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.addressundefinedになりうる値として宣言されており、これは値の設定が必須でないことを意味しています。
    • Recommended:

      True

    • Default:

      false, unless strict is set

    • Related:

      strict

    • Released:

      2.7

    #モジュール解決

    # Allow Synthetic Default Imports - allowSyntheticDefaultImports

    allowSyntheticDefaultImportsを true に設定すると、次のようなインポートが可能になります:

    ts
    import React from "react";

    下記のようにする必要はありません:

    ts
    import * as React from "react";

    モジュールが default export を指定していなくても利用可能です。

    このオプションは TypeScript が出力する JavaScript へは影響しません。型チェックにのみ影響があります。 このオプションにより、モジュールの default export を自然に扱えるようにする追加コードが出力されている環境では、TypeScript と Babel の挙動が揃います。

    # Allow Umd Global Access - allowUmdGlobalAccess

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

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

    • Default:

      false

    • Released:

      3.5

    # Base Url - baseUrl

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

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

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

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

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

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

      # ES Module Interop - esModuleInterop

      すべてのインポートに対して Namespace オブジェクトを生成することによって、CommonJS と ES Modules 間で相互運用可能なコードを出力します。

      TypeScript は EcmaScript のモジュール標準に準拠しています。 つまり、import React from "react"のような構文をサポートするには、そのファイルに具体的なdefault export が含まれている必要があります。 CommonJS のモジュールでは、このエクスポートの方法は稀です。esModuleInteropが true でなければ:

      // @filename: utilFunctions.js const getStringLength = (str) => str.length; module.exports = { getStringLength, }; // @filename: index.ts import utils from "./utilFunctions"; const count = utils.getStringLength("Check JS");Try

      インポート可能なオブジェクトにdefaultが無いため、このコードは動作しないでしょう。このコードが動作するように見えたとしても、です。 Babel のようなトランスパイラは、利便のために default が存在しない場合に自動で作成します。モジュールを次のようにするのです:

      js
      // @filename: utilFunctions.js const getStringLength = (str) => str.length; const allFunctions = { getStringLength, }; module.exports = allFunctions;

      このコンパイラフラグを有効化すると、allowSyntheticDefaultImportsも有効化されます。

      # Module Resolution - moduleResolution

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

      • Default:

        module === AMD or UMD or System or ES6, then Classic

        Otherwise Node

      • Related:

        module

      # Paths - paths

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

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

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

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

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

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

        シンボリックリンクを実体パスへ解決しないという Node.js の同名フラグを反映したオプションです。

        このフラグは Webpack のresolve.symlinksオプションと逆の動作をします(つまり、TypeScript のpreserveSymlinksを true に設定することは、Webpack のresolve.symlinksを false に設定することと同等です。逆も然りです)。

        このオプションを有効化すると、モジュールとパッケージへの参照(例えば、import/// <reference type="..." /> ディレクティブ)は、シンボリックリンクが解決する場所としてではなく、そのシンボリックリンクファイルからの相対パスとして解決されます。

        • Default:

          false

        # Root Dirs - rootDirs

        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")
        { "": { "": ["src/views", "generated/templates/views"] } }

        この設定は TypeScript がどのように JavaScript を出力するかには影響しません。 実行時に相対パスを使って動作可能であるという仮定がエミュレートされるだけです。

        # Type Roots - typeRoots

        デフォルトでは、表示されているすべての”@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 - types

        デフォルトでは、すべての表示されている@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 のソースマップ標準に準拠したファイルを追加で出力します。

        ソースマップは、そのソースマップが指し示す実体ファイルの隣に.mapファイルとして出力されます。

        # Inline Source Map - inlineSourceMap

        設定すると、TypeScript はソースマップを.js.mapファイルへ出力するのではなく、ソースマップの内容を.jsファイルに埋め込みます。 この結果、JS ファイルはより大きくなりますが、いくつかのシナリオにおいては便利です。 例えば、.mapファイルの提供が許可されていない web サーバーで JS ファイルをデバッグしたい、という場合です。

        このオプションは、sourceMapとは互いに排他的にです。

        例えば、次の TypeScript は:

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

        次の JavaScript に変換されます:

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

        inlineSourceMapを有効にしてビルドすると、 ファイルの末尾にこのファイルのソースマップを含んだコメントが出力されます。

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

          false

        • Released:

          1.5

        # Inline Sources - inlineSources

        設定すると、TypeScript は元の.tsファイルの内容を文字列としてソースマップに埋め込みます。 このオプションはinlineSourceMapと同様のケースで有用です。

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

        例えば、次の TypeScript について:

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

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

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

        inlineSourcesinlineSourceMapを有効にしてビルドすると、 ファイルの末尾にこのファイルのソースマップを含んだコメントが付きます。 このソースマップは元となったソースコードも含んでいるため、inlineSourceMapの例とは異なる点に留意してください。

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

          false

        • Released:

          1.5

        # Map Root - mapRoot

        生成された場所情報を利用するのではなく、デバッガがマップファイルを探索すべき場所を明示します。 この文字列はソースマップの中で、文字列そのままの値として処理されます。例えば:

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

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

          # Source Root - sourceRoot

          相対的なソースコードの場所の代わりに、デバッガが TypeScript のファイルを探索すべき場所を明示します。 この文字列は、パスや URL を使用できるソースマップの中で、文字列そのままの値として処理されます:

          json
          { "compilerOptions": { "sourceMap": true, "sourceRoot": "https://my-website.com/debug/source/" } }

          上記の設定は、index.jshttps://my-website.com/debug/source/index.tsにソースコードがある、ということを宣言しています。

            #Linter Checks

            追加のチェック集です。これらのチェックは、コンパイラとリンターの境界を多少跨いでいます。より詳細なルールを探しているのであれば、これらのオプションよりもeslintのようなツールの使用を推奨します。

            # No Fallthrough Cases In Switch - noFallthroughCasesInSwitch

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

            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
            • Default:

              false

            • Released:

              1.8

            # No Implicit Returns - noImplicitReturns

            有効化すると、TypeScript は関数内のすべてのコードパスについて、値を返却していることをチェックします。

            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
            • Default:

              false

            • Released:

              1.8

            # noPropertyAccessFromIndexSignature - noPropertyAccessFromIndexSignature

            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:

            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; // ^ = stringTry

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

            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'].// ^ = stringTry

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

            • Default:

              false

            • Released:

              4.2

            # noUncheckedIndexedAccess - noUncheckedIndexedAccess

            TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.

            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

            Turning on noUncheckedIndexedAccess will add undefined to any un-declared field in the type.

            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

            # No Unused Locals - noUnusedLocals

            利用されていないローカル変数について、エラーを報告します。

            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
            • Default:

              false

            • Released:

              2.0

            # No Unused Parameters - noUnusedParameters

            利用されていない関数のパラメータについて、エラーを報告します。

            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
            • Default:

              false

            • Released:

              2.0

            #実験的な機能

            TypeScript は、JavaScript 言語に追加が確認されている機能のみを含めるように努めています。

            機能がそのルールの例外となるほど説得力がある場合、実験的なコンパイラのフラグとなります。 JavaScript 言語にこれらの機能が組み込まれるときに、今のバージョンとは異なる可能性があり、その意味においてリスクと見なされるかもしれません。

            # Emit Decorator Metadata - emitDecoratorMetadata

            reflect-metadataモジュールとともに動作するデコレータのメタ情報を出力するための実験的なサポートを有効化します。

            例えば、次の JavaScript について、

            function LogMethod( target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor ) { console.log(target); console.log(propertyKey); console.log(descriptor); } class Demo { @LogMethod public foo(bar: number) { // do nothing } } const demo = new Demo();Try

            emitDecoratorMetadataが true に設定されていない場合(デフォルト)、次のようになります:

            "use strict"; var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) { var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d; if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc); else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r; return c > 3 && r && Object.defineProperty(target, key, r), r; }; function LogMethod(target, propertyKey, descriptor) { console.log(target); console.log(propertyKey); console.log(descriptor); } class Demo { foo(bar) { // 何もしない } } __decorate([ LogMethod ], Demo.prototype, "foo", null); const demo = new Demo();Try

            emitDecoratorMetadataが true に設定されている場合は、次のようになります:

            "use strict"; var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) { var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d; if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc); else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r; return c > 3 && r && Object.defineProperty(target, key, r), r; }; var __metadata = (this && this.__metadata) || function (k, v) { if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v); }; function LogMethod(target, propertyKey, descriptor) { console.log(target); console.log(propertyKey); console.log(descriptor); } class Demo { foo(bar) { // 何もしない } } __decorate([ LogMethod, __metadata("design:type", Function), __metadata("design:paramtypes", [Number]), __metadata("design:returntype", void 0) ], Demo.prototype, "foo", null); const demo = new Demo();Try

            # Experimental Decorators - experimentalDecorators

            デコレータの実験的なサポートを有効化します。 これは TC39 の標準化プロセスでは stage 2 の機能です。

            デコレータは JavaScript の仕様として、いまだ完全には組み込まれていない言語機能です。 これは TypeScript の実装バージョンが、TC39 が決定する JavaScript の実装と異なるかもしれないということを意味しています。

            TypeScript のデコレータのサポートについて、より詳しく知りたい場合はハンドブックを参照してください。

            #Advanced

            デバッグに役立つフラグです。

            # Allow Unreachable Code - allowUnreachableCode

            false に設定すると、到達不可能なコードに対する警告を無効化します。 この警告は、JavaScript 構文の利用によって到達不可能になり得るコードにのみ関係します。例えば:

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

            "allowUnreachableCode": falseにすると、次のようになります:

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

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

            • Default:

              undefined

            • Released:

              1.8

            # Allow Unused Labels - allowUnusedLabels

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

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

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

              false

            • Released:

              1.8

            # Assume Changes Only Affect Direct Dependencies - assumeChangesOnlyAffectDirectDependencies

            このオプションを設定すると、TypeScript は本当に影響を受ける可能性があるすべてのファイルの再チェック/再ビルドを避け、変更されたファイルとそれらを直接 import しているファイルのみを再チェック/再ビルドするようになります。

            これは監視アルゴリズムの「高速で緩い」実装と見なせます。これにより、すべてのコンパイルエラーメッセージを得るためにフルビルドが必要になりますが、インクリメンタルビルドの再ビルド時間を大幅に短縮できます。

            # Charset - charset

            以前の TypeScript のバージョンでは、このオプションでディスクからどのエンコードでファイルを読み込むかを制御していました。 今の TypeScript は UTF-8 でエンコードされていることを前提としています。ただし、UTF-16(BE および LE)または UTF-8 の BOM を正しく検出します。

            • Status:

              Deprecated

            • Default:

              utf8

            # Declaration Dir - declarationDir

            型定義ファイルが出力されるルートディレクトリを設定します。

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

            次のtsconfig.jsonは:

            { "": { "": true, "": "./types" } }

            index.tsに対応する d.ts ファイルをtypesフォルダへ配置します:

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

            # Diagnostics - diagnostics

            デバッグ用にコンパイラからの診断情報を出力するために使用されていました。このコマンドはよりユーザー向けの結果かつ分かりやすいextendedDiagnosticsのサブセットです。

            TypeScript のコンパイラエンジニアからこのフラグを用いて結果を提供するように依頼された場合、代わりに--extendedDiagnosticsを用いても問題ありません。

            # disableReferencedProjectLoad - disableReferencedProjectLoad

            In multi-project TypeScript programs, TypeScript will load all of the available projects into memory in order to provide accurate results for editor responses which require a full knowledge graph like ‘Find All References’.

            If your project is large, you can use the flag disableReferencedProjectLoad to disable the automatic loading of all projects. Instead, projects are loaded dynamically as you open files through your editor.

            # Disable Size Limit - disableSizeLimit

            非常に大規模な JavaScript プロジェクトで作業するときに発生する可能性のある使用メモリの膨張を避けるために、TypeScript が割り当てられるメモリの量には上限があります。このフラグを設定すると、この制限を取り除きます。

            • Default:

              false

            # Disable Solution Searching - disableSolutionSearching

            複合 TypeScript プロジェクトで作業する場合、このオプションはエディタでfind all references定義へ移動などの機能を使う際に含めたくないプロジェクトを宣言する方法を提供します。

            このフラグは大規模な複合プロジェクトで応答性を高めるために使用できるものです。

            # Disable Source Project Reference Redirect - disableSourceOfProjectReferenceRedirect

            複合 TypeScript プロジェクトで作業する場合、このオプションはモジュール間の境界として d.ts ファイルが使用されていた3.7 以前の挙動に戻す方法を提供します。 3.7 にて、信頼できる情報源は TypeScript のファイルになりました。

            # Emit BOM - emitBOM

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

            • Default:

              false

            # Emit Declaration Only - emitDeclarationOnly

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

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

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

            # explainFiles - explainFiles

            Print names of files which TypeScript sees as a part of your project and the reason they are part of the compilation.

            For example, with this project of just a single index.ts file

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

            Using a tsconfig.json which has explainFiles set to true:

            json
            { "compilerOptions": { "target": "es5", "module": "commonjs", "explainFiles": true } }

            Running TypeScript against this folder would have output like this:

            ❯ tsc node_modules/typescript/lib/lib.d.ts Default library for target 'es5' node_modules/typescript/lib/lib.es5.d.ts Library referenced via 'es5' from file 'node_modules/typescript/lib/lib.d.ts' node_modules/typescript/lib/lib.dom.d.ts Library referenced via 'dom' from file 'node_modules/typescript/lib/lib.d.ts' node_modules/typescript/lib/lib.webworker.importscripts.d.ts Library referenced via 'webworker.importscripts' from file 'node_modules/typescript/lib/lib.d.ts' node_modules/typescript/lib/lib.scripthost.d.ts Library referenced via 'scripthost' from file 'node_modules/typescript/lib/lib.d.ts' index.ts Matched by include pattern '**/*' in 'tsconfig.json'

            The output above show:

            • The initial lib.d.ts lookup based on target, and the chain of .d.ts files which are referenced
            • The index.ts file located via the default pattern of include

            This option is intended for debugging how a file has become a part of your compile.

            # Extended Diagnostics - extendedDiagnostics

            このフラグを使うと、TypeScript がコンパイルの際に、どの程度の時間をどこに費やしているかを調査できます。 このフラグは、コードベース全体のパフォーマンス特性を理解するために使われるツールです。

            測定の仕方および出力の解釈方法については、wiki のパフォーマンスセクションをご覧ください。

            # Force Consistent Casing In File Names - forceConsistentCasingInFileNames

            TypeScript が大文字小文字を区別するかどうかは、動作しているファイルシステムに従います。 これが問題になるのは、ある開発者はケースセンシティブなファイルシステムで作業をしている一方で、別の開発者はそうではない場合です。 あるファイルがfileManager.tsの Import を./FileManager.tsと指定したとき、ケースセンシティブでないファイルシステムではファイルが見つかりますが、ケースセンシティブなファイルシステムでは見つかりません。

            このオプションを有効化すると、TypeScript はプログラムがディスク上の大文字小文字と異なるファイルをインクルードしようとした場合にエラーを発生させます。

            • Recommended:

              True

            • Default:

              false

            # Generate CPU Profile - generateCpuProfile

            このオプションを用いると、TypeScript にコンパイラが実行中の v8 の CPU プロファイルを出力させられます。CPU プロファイルはなぜビルドが遅くなるのかについての示唆を与えてくれます。

            このオプションは CLI から--generateCpuProfile tsc-output.cpuprofileを介してのみ使用できます。

            sh
            npm run tsc --generateCpuProfile tsc-output.cpuprofile

            このファイルは Chrome や Edge Developer のような chromium をベースとしたブラウザのCPU profilerで開くことができます。 TypeScript Wiki のパフォーマンスセクションでコンパイラのパフォーマンスについて詳細を学ぶことができます。

            • Default:

              profile.cpuprofile

            • Released:

              3.7

            # Imports Not Used As Values - importsNotUsedAsValues

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

            • remove: 型のみを参照するimport文を削除するデフォルトの挙動
            • preserve: 使用されない値または型のすべてのimport文を保持します。これにより、インポート/副作用が保持されます。
            • error: すべての import を保持しますが(preserve オプションと同じ)、値の import が型としてのみ使用されている場合にエラーを出力します。これは、誤って値が import されないようにしつつ、副作用のある import を明示的にしたい場合に有用です。

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

            • Allowed:

              remove,
              preserve,
              error

            • Released:

              3.8

            # JSX Factory - jsxFactory

            JSX 要素がコンパイルされるときの.jsファイルで呼び出される関数を変更します。 preactを使う場合に、デフォルトの"React.createElement"の代わりに"h""preact.h"に変更するのが一般的な変更です。

            このオプションはBabel における/** @jsx h */ディレクティブと同じものです。

            # jsxFragmentFactory - jsxFragmentFactory

            Specify the JSX fragment factory function to use when targeting react JSX emit with jsxFactory compiler option is specified, e.g. Fragment.

            For example with this TSConfig:

            { "": { "": "esnext", "": "commonjs", "": "react", "": "h", "": "Fragment" } }

            This TSX file:

            tsx
            import { h, Fragment } from "preact"; const HelloWorld = () => ( <> <div>Hello</div> </> );

            Would look like:

            "use strict"; Object.defineProperty(exports, "__esModule", { value: true }); const preact_1 = require("preact"); const HelloWorld = () => (preact_1.h(preact_1.Fragment, null, preact_1.h("div", null, "Hello")));Try

            This option can be used on a per-file basis too similar to Babel’s /* @jsxFrag h */ directive.

            For example:

            /** @jsx h */ /** @jsxFrag Fragment */ import { h, Fragment } from "preact"; const HelloWorld = () => ( <> <div>Hello</div> </> );Try

            # jsxImportSource - jsxImportSource

            Declares the module specifier to be used for importing the jsx and jsxs factory functions when using jsx as "react-jsx" or "react-jsxdev" which were introduced in TypeScript 4.1.

            With React 17 the library supports a new form of JSX transformation via a separate import.

            For example with this code:

            tsx
            import React from "react"; function App() { return <h1>Hello World</h1>; }

            Using this TSConfig:

            { "": { "": "esnext", "": "commonjs", "": "react-jsx" } }

            The emitted JavaScript from TypeScript is:

            "use strict"; var __importDefault = (this && this.__importDefault) || function (mod) { return (mod && mod.__esModule) ? mod : { "default": mod }; }; Object.defineProperty(exports, "__esModule", { value: true }); const jsx_runtime_1 = require("react/jsx-runtime"); const react_1 = __importDefault(require("react")); function App() { return jsx_runtime_1.jsx("h1", { children: "Hello World" }, void 0); }Try

            For example if you wanted to use "jsxImportSource": "preact", you need a tsconfig like:

            { "": { "": "esnext", "": "commonjs", "": "react-jsx", "": "preact", "": ["preact"] } }

            Which generates code like:

            "use strict"; Object.defineProperty(exports, "__esModule", { value: true }); exports.App = void 0; const jsx_runtime_1 = require("preact/jsx-runtime"); function App() { return jsx_runtime_1.jsx("h1", { children: "Hello World" }, void 0); } exports.App = App;Try

            Alternatively, you can use a per-file pragma to set this option, for example:

            tsx
            /** @jsxImportSource preact */ export function App() { return <h1>Hello World</h1>; }

            Would add preact/jsx-runtime as an import for the _jsx factory.

            Note: In order for this to work like you would expect, your tsx file must include an export or import so that it is considered a module.

            # Keyof Strings Only - keyofStringsOnly

            このフラグは、 文字列インデックス記法の型として適用される際にkeyof型パラメータがstring | numberではなくstringを返すようにします。

            このフラグは、TypeScript 2.9 のリリースよりも前の挙動に保ちたいときに利用されます。

            • Status:

              Deprecated

            • Default:

              false

            • Released:

              2.9

            # List Emitted Files - listEmittedFiles

            コンパイルされ、生成されたファイル名をターミナルに出力します。

            このフラグは 2 つのケースで有用です:

            • 後続のコマンドでファイル名が処理されるターミナルのビルドチェーンの一部として TypeScript をトランスパイルしたいとき
            • TypeScript がコンパイルしてほしいファイルを対象に含めているか分からず、対象ファイル設定を部分的にデバッグしたいとき

            例えば、以下のようなときに:

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

            以下の設定をすると:

            json
            { "compilerOptions": { "declaration": true, "listFiles": true } }

            以下のような path を出力します:

            $ npm run tsc path/to/example/index.js path/to/example/index.d.ts

            通常、成功すると TypeScript は何も出力しない状態に戻ります。

            • Default:

              false

            # List Files - listFiles

            コンパイルされるファイル名を出力します。これは、コンパイルしてほしいファイルを TypeScript が対象に含めてくれているかが分からないときに有用です。

            例えば、以下のようなときに:

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

            以下の設定をすると:

            { "": { "": true } }

            出力される path は以下のようになります:

            $ npm run tsc path/to/example/node_modules/typescript/lib/lib.d.ts path/to/example/node_modules/typescript/lib/lib.es5.d.ts path/to/example/node_modules/typescript/lib/lib.dom.d.ts path/to/example/node_modules/typescript/lib/lib.webworker.importscripts.d.ts path/to/example/node_modules/typescript/lib/lib.scripthost.d.ts path/to/example/index.ts

            # Max Node Module JS Depth - maxNodeModuleJsDepth

            node_modules配下で依存関係を探す際や、JavaScript ファイルをロードする際の最大の深さです。

            このフラグはallowJsが有効化されているときのみ利用可能であり、node_modules内のすべての JavaScript について、TypeScript に型推論させたいときに用います。

            理想的には、このオプションの値は 0(デフォルト値)であるべきで、d.tsファイルでモジュールを明示的に定義すべきです。 ただし、速度と精度を犠牲にして、このオプションを有効化したいという場合もあるかもしれません。

            • Default:

              0

            # New Line - newLine

            ファイルを出力するときの改行コードを指定します: ‘CRLF’(dos)または’LF’(unix)のいずれかを指定してください。

            • Default:

              Platform specific

            • Released:

              1.5

            # No Emit Helpers - noEmitHelpers

            importHelpersを使って、ヘルパ関数をインポートする代わりに、グローバルスコープに使用するヘルパ関数のための実装を提供し、ヘルパ関数が出力されるのを完全に無効にできます。

            例えば、このasync関数を ES5 で実行するためには、awaitのような関数とgeneratorのような関数が必要です:

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

            これは、とても多くの JavaScript を生成します:

            "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 (_) 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

            このフラグを通じて、独自のグローバル実装に切り替えられます:

            "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

            # No Emit On Error - noEmitOnError

            エラーがあるときに、JavaScript ソースコードやソースマップファイル、型定義ファイルなどをコンパイラに出力させないようにします。

            デフォルト値はfalseであり、このため、すべてのエラーを解決するよりも前に別の環境でコードの変更結果を確認したいといったファイル監視環境において、TypeScript が扱いやすくなっています。

            • Default:

              false

            • Released:

              1.4

            # No Error Truncation - noErrorTruncation

            エラーメッセージを切り捨てないようにします。

            デフォルト値のfalseの場合、次のようになります。

            var x: { propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }; // 型'x'の文字列表現はエラメッセージ中で省略されます var s: string = x; Type '{ propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }' is not assignable to type 'string'.
            Variable 'x' is used before being assigned.
            2322
            2454
            Type '{ propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }' is not assignable to type 'string'.
            Variable 'x' is used before being assigned.
            Try

            trueにすると、次のようになります。

            var x: { propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }; // 型'x'の文字列表現はエラメッセージ中で省略されます var s: string = x; Type '{ propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }' is not assignable to type 'string'.
            Variable 'x' is used before being assigned.
            2322
            2454
            Type '{ propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }' is not assignable to type 'string'.
            Variable 'x' is used before being assigned.
            Try
            • Status:

              Deprecated

            • Default:

              false

            # No Implicit Use Strict - noImplicitUseStrict

            これは必要ないはずです。ES6 でないターゲットでモジュールを出力する際に、TypeScript はデフォルトで"use strict;"という前置きをファイルの一番始めに出力します。 この設定は、この前置きを無効にします。

            define(["require", "exports"], function (require, exports) { exports.__esModule = true; exports.fn = void 0; function fn() { } exports.fn = fn; });Try
            define(["require", "exports"], function (require, exports) { "use strict"; exports.__esModule = true; exports.fn = void 0; function fn() { } exports.fn = fn; });Try
            • Default:

              false

            # No Lib - noLib

            すべてのライブラリファイルについて、自動でのインクルードを無効化します。 このオプションを設定した場合、libは無視されます。

            • Default:

              false

            • Related:

              lib

            # No Resolve - noResolve

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

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

            • Default:

              false

            # No Strict Generic Checks - noStrictGenericChecks

            TypeScript は、総称型を使った 2 つの関数について、型パラメータを統合して比較します。

            type A = <T, U>(x: T, y: U) => [T, U]; type B = <S>(x: S, y: S) => [S, S]; function f(a: A, b: B) { b = a; // Ok a = b; // Error Type 'B' is not assignable to type 'A'. Types of parameters 'y' and 'y' are incompatible. Type 'U' is not assignable to type 'T'. 'T' could be instantiated with an arbitrary type which could be unrelated to 'U'.2322Type 'B' is not assignable to type 'A'. Types of parameters 'y' and 'y' are incompatible. Type 'U' is not assignable to type 'T'. 'T' could be instantiated with an arbitrary type which could be unrelated to 'U'.}Try

            このフラグを利用することで、このチェックを無効化できます。

            • Default:

              false

            • Released:

              2.4

            # Out - out

            代わりにoutFileを使ってください。

            outオプションは、予測可能でない、または一貫性のない方法によってファイルの最終的な場所を計算してしまいます。 このオプションは後方互換性の維持のためにのみ残されていますが、非推奨です。

            # Preserve Const Enums - preserveConstEnums

            コード生成時にconst enumの定義を取り除かないようにします。 const enumは、参照ではなく Enum 値を出力することによって、アプリケーション実行時の全体的なメモリの使用量を軽減します。

            例えば次の TypeScript では:

            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 への参照を除去します。

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

            preserveConstEnumstrueに設定すると、enumは実行時に残り、数値も出力されるようになります。

            "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 /* JimmyEatWorldFutures */; if (selectedAlbum === 1 /* JimmyEatWorldFutures */) { console.log("That is a great choice."); }Try

            このオプションによって、このようなconst enumsは実行時に追跡されないソースコードのみの機能になります。

            • Default:

              false

            # React Namespace - reactNamespace

            代わりに--jsxFactoryを利用してください。reactのときに TSX ファイルのcreateElementが実行されるオブジェクトを指定します。

            • Default:

              "React"

            # Resolve JSON Module - resolveJsonModule

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

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

            // @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 ファイルの型を検査できるようになります。

            // @filename: settings.json { "repo": "TypeScript", "dry": false, This condition will always return 'false' since the types 'boolean' and 'number' have no overlap.2367This condition will always return 'false' since 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
            • Default:

              false

            # Skip Default Lib Check - skipDefaultLibCheck

            代わりに--skipLibCheckを利用してください。デフォルトのライブラリ型定義ファイルをチェックしないようになります。

            • Default:

              false

            # Skip Lib Check - skipLibCheck

            型定義ファイルのチェックをスキップします。

            型システムの精度を犠牲にすることで、コンパイル実行時間を削減します。 例えば、2 つのライブラリが、同じtypeを一貫性の無い方法で定義していたとします。 すべてのd.tsファイルの完全なチェックを行わずに、TypeScript はアプリケーション内のソースコードで明示的に参照しているコードの型をチェックします。

            skipLibCheckの利用を検討する一般的なケースは、あるライブラリの型定義がnode_modules内にコピーされて複数存在している場合です。 このようなケースでは、 yarn’s resolutionsのような機能の利用を検討してツリーにおける該当の依存関係のコピーが 1 つだけであることを確認するか、 追加のツールを使わずに問題を修正するために依存関係の解決を理解して、コピーが 1 つだけであることを確認する方法を調査する必要があります。

            • Recommended:

              True

            • Default:

              false

            • Released:

              2.0

            # Strip Internal - stripInternal

            JSDoc コメントとして@internalが付与されたコードについて、定義情報を出力しないようにします。 このオプションはコンパイラが内部で利用するためのものです; コンパイラは結果の妥当性検証をしないため、自己責任で使ってください。 d.tsファイル内での可視性を細かく制御できるツールを探しているのであれば、api-extractorを参照してください。

            /** * Days available in a week * @internal */ export const daysInAWeek = 7; /** Calculate how much someone earns in a week */ export function weeklySalary(dayRate: number) { return daysInAWeek * dayRate; }Try

            このフラグがfalseであるとき(デフォルト):

            /** * 一週間の日数 * @internal */ export declare const daysInAWeek = 7; /** 一週間あたりの稼ぎを計算する */ export declare function weeklySalary(dayRate: number): number;Try

            stripInternaltrueに設定すると、d.tsは次のように編集されて出力されます。

            /** 一週間あたりの稼ぎを計算する */ export declare function weeklySalary(dayRate: number): number;Try

            JavaScript としての出力は一緒です。

            • Status:

              internal

            # Suppress Excess Property Errors - suppressExcessPropertyErrors

            このオプションにより、次の例に示すような、プロパティが過剰に定義されているときのエラーを抑止します:

            type Point = { x: number; y: number }; const p: Point = { x: 1, y: 3, m: 10 }; Type '{ x: number; y: number; m: number; }' is not assignable to type 'Point'. Object literal may only specify known properties, and 'm' does not exist in type 'Point'.2322Type '{ x: number; y: number; m: number; }' is not assignable to type 'Point'. Object literal may only specify known properties, and 'm' does not exist in type 'Point'.Try

            このフラグは、TypeScript 1.6のオブジェクトリテラルの厳密チェックへの移行を助けるために追加されました。

            モダンなコードベースでの、このフラグの利用は推奨されません。エラー抑止が必要な箇所で、都度// @ts-ignoreを利用できます。

            • Default:

              false

            # Suppress Implicit Any Index Errors - suppressImplicitAnyIndexErrors

            suppressImplicitAnyIndexErrorsを有効化すると、次の例に示すようなオブジェクトへインデックスアクセスしたときの暗黙的 any についてのエラーが抑止されます:

            const obj = { x: 10 }; console.log(obj["foo"]); Element implicitly has an 'any' type because expression of type '"foo"' can't be used to index type '{ x: number; }'. Property 'foo' does not exist on type '{ x: number; }'.7053Element implicitly has an 'any' type because expression of type '"foo"' can't be used to index type '{ x: number; }'. Property 'foo' does not exist on type '{ x: number; }'.Try

            suppressImplicitAnyIndexErrorsはかなり影響の大きい方法です。代わりに@ts-ignoreコメントの利用を推奨します:

            const obj = { x: 10 }; // @ts-ignore console.log(obj["foo"]);Try

            # Trace Resolution - traceResolution

            あるモジュールがコンパイル対象に含まれていない理由をデバッグするために用います。 traceResolutionstrueにすると TypeScript が処理された各々のファイルについてモジュール解決過程の情報を出力するようになります。

            この設定についてより詳細に知りたい場合、ハンドブックをご覧ください。

            • Default:

              false

            • Released:

              2.0

            # Use Define For Class Fields - useDefineForClassFields

            このフラグは、最新の Class フィールドの仕様へ移行するために用います。TypeScript の Class フィールド記法は、TC39 が Class フィールドの仕様の合意に至るよりも何年も前に導入されました。最新の仕様バージョンは、TypeScript の実装とは実行時の挙動が異なりますが、構文は同じです。

            このフラグにより、ECMA が定める最新の実行時挙動へ移行できます。

            移行の詳細については、3.7 リリースノートを参照してください。

            • Default:

              false

            • Released:

              3.7

            #コマンドライン

            # Preserve Watch Output - preserveWatchOutput

            watch モードについて、変更が発生するたびにスクリーンをクリアせずに以前の出力をコンソールに出し続けるかどうかを設定します。

            • Default:

              false

            • Status:

              internal

            # Pretty - pretty

            エラーやメッセージを文脈や色を使ってスタイリングします。このオプションはデフォルトで有効です— コンパイラから簡潔で単色のメッセージを受け取れるようにすることもできます。

            • Default:

              true

            #Watch Options

            TypeScript 3.8 にてディレクトリを監視するための新戦略をリリースしました。これは、node_modules の変更を効率的に検知するために極めて重要なものです。

            Linux のような OS において、TypeScript は 依存関係の変更を検出するために、node_modules と多くのサブディレクトリに、(ファイルウォッチャーではなく)ディレクトリウォッチャーをインストールします。 なぜなら、利用できるファイルウォッチャーの数を、node_modules のファイル数がしばしば上回る一方で、追跡するディレクトリ数は少なく済むからです。

            各プロジェクトは異なる戦略の下でより良く動作する可能性もあり、逆にこの新しいアプローチが一連の作業の流れでうまく動作しない可能性もあります。そのため、TypeScript 3.8 では新しく watchOptions フィールドが導入されました。このフィールドでは、ファイルやディレクトリを追跡する為に、どの監視戦略を使用すべきか、compiler/language service に伝えることができます。

            # fallbackPolling - fallbackPolling

            ファイルシステムのイベントを使用するときに、システムがネイティブのファイルウォッチャーを使い切ったり、ネイティブのファイルウォッチャーが対応していない場合、どのようなポーリング戦略を行使するかを指定するオプションです。

            • fixedPollingInterval: 一定の間隔を開けて、1 秒間に数回、全ファイルをチェックします。
            • priorityPollingInterval: 1 秒間に数回、全ファイルをチェックします。しかし、特定の種類のファイルには発見的手法を使用して、他ファイルよりも低頻度でチェックします。
            • dynamicPriorityPolling: 変更頻度の少ないファイルは、他よりも低頻度でチェックされるように動的キューを使用します。
            • synchronousWatchDirectory: ディレクトリの遅延監視を無効にします。遅延監視機能は、沢山のファイル変更が一度に引き起こされる場合は役立ちますが(例: npm install による node_modules の変更)、あまり一般的な構成ではないときに、この遅延監視フラグを無効にしたくなるかもしれません。
            • Allowed:

              fixedPollingInterval,
              priorityPollingInterval,
              dynamicPriorityPolling

            • Released:

              3.8

            # watchDirectory - watchDirectory

            The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.

            • fixedPollingInterval: Check every directory for changes several times a second at a fixed interval.
            • dynamicPriorityPolling: Use a dynamic queue where less-frequently modified directories will be checked less often.
            • useFsEvents (the default): Attempt to use the operating system/file system’s native events for directory changes.
            • Default:

              useFsEvents

            • Allowed:

              fixedPollingInterval,
              dynamicPriorityPolling,
              useFsEvents

            • Released:

              3.8

            # watchFile - watchFile

            The strategy for how individual files are watched.

            • fixedPollingInterval: Check every file for changes several times a second at a fixed interval.
            • priorityPollingInterval: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.
            • dynamicPriorityPolling: Use a dynamic queue where less-frequently modified files will be checked less often.
            • useFsEvents (the default): Attempt to use the operating system/file system’s native events for file changes.
            • useFsEventsOnParentDirectory: Attempt to use the operating system/file system’s native events to listen for changes on a file’s parent directory
            • Default:

              useFsEvents

            • Allowed:

              fixedPollingInterval,
              priorityPollingInterval,
              dynamicPriorityPolling,
              useFsEvents,
              useFsEventsOnParentDirectory

            • Released:

              3.8