compilerOptionsを全部読んだときの雑多なメモ
Fukuoka.ts用のメモです。めっちゃ荒いです。
Spreadsheetにまとめたやつ
Type Checking
allowUnreachableCode
デフォルトはtrue？
ESLintでやる方がいい気もする
Ver 1.8
allowUnusedLabels
デフォルトはtrue？
ESLintでやる方がいい気もする
Ver 1.8
alwaysStrict
デフォルトは基本falseで、strictの場合はtrue
ESMはデフォでuse strictだった気も
Ver 2.1
exactOptionalPropertyTypes
trueの場合、プロパティのoptionalの扱いが厳しくなる。property: undefinedと何もなしは厳密に違う。
具体的にどう違うのか？は実はよくわかってないでござる
Ver 4.4
noFallthroughCasesInSwitch
Ver 1.8
breakの無いcaseは許さない
ESLintでいいと思う
ESLintでいいやつを全部オフった場合、どれくらい早くなるか気になる
noImplicitAny
Ver表記なし（原初のやつ？）
デフォルトはstrictモードの場合はtrue
noImplicitOverride
サブクラスでメソッドのオーバーライドする時にoverrideと書かないと怒られるやつ
super()呼べば回避できるのか？
デフォルトはfalse？
Ver 4.3
noImplicitReturns
Ver 1.8
ESLintでよくね？
noImplicitThis
Ver 2.0
Closure。
Class以外でも怒ってくれる？
ESLintで代替できそう？
ver 2.0の時のESLintってどれくらい？古めのオプション、結構代替できるかも？
デフォルト strictモードの場合はtrue
noPropertyAccessFromIndexSignature
dot, indexed、どっち？
型定義上で存在しない（、またはしないかもしれない）値について、indexedでアクセスしてね？ってやつ。
よくよく考えるとなんでだっけ？
The goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.
@ｔｓｃｏｎｆｉｇでいつもオフにするやつ
Ver 4.2
noUncheckedIndexedAccess
Ver 4.2
デフォルトはどっちなの？
noUnusedLocals
Ver 2.0
ESLintでよさそう
noUnusedParameters
ver 2.0
ESLintでいいやつ
strict
trueにするとstrictモードファミリーのオプションが全てデフォルトで有効になる
Ver 2.3
- alwaysStrict
- strictNullChecks
- strictBindCallApply
- strictFunctionTypes
- strictPropertyInitialization
- noImplicitAny
- noImplicitThis
- useUnknownInCatchVariables
デフォルトはfalse？
strictBindCallApply
Functionのcall, bind, applyにおいて元の関数の引数で型チェックするかどうか
デフォルトは、strict モードの場合はtrue
Ver3.2
strictFunctionTypes
ver 2.6
関数のパラメタをより厳密にみる。有効時の挙動の方が直感的か？
安全で無い呼び出し時にエラーになる？そうなら無効でもいいかも？無効して遊びを作ったとて、それを使うケースが浮ばぬ
function構文のみ。arrowも？
strict時はデフォルトで有効
strictNullChecks
これは有効必須やろ。無効の場合でいいことないだろ。
Strictファミリー
Ver 2.0
strictPropertyInitialization
classのプロパティが適切に初期化されていない場合にエラー
Strictファミリー
ver 2.7
useUnknownInCatchVariables
catchした変数にunknownを指定できる
Strictファミリー
ver 4.4
Modules
allowArbitraryExtensions
Ver 5.0?
JS, TS以外のファイルのimportを許可するフラグ
allowImportingTsExtensions
ver 不明
TSの拡張子（.ts, .tsx, .mts）でimportを書けるフラグ。
—noEmit or —emitDeclarationOnly時にのみ有効。そうで無い場合、runtimeに.tsは存在しないことが大半なので。
allowUmdGlobalAccess
Ver 3.5
UMDでグローバルに定義されたモジュールへのアクセスを許可。
具体例を見たい
baseUrl
絶対パス参照ではないモジュールを解決する時の起点になるパスの指定。
node_modules以下の解決ってデフォルトで有効なのか？
Ver 不明
customConditions
module resolution が、nodenext, node16, bundler 時に有効にできる
Conditional Imports/ExportsでTSが静的解析時に参照する条件を明示的に指定できる
Conditional Imports/Exports
あんまりユースケースが思い浮かばないな
Ver 不明
module
詳しくは
トランスパイル後のファイルのモジュール形式
最近、この辺を強く意識しなくなったなー。
es6/es2015とes2020/esnextって何が違う？知らんオプションあるので知りたい。noneは何もしないってこと？
デフォルトは、targetによって変動。targetがES3,ES5の場合は、CommonJS。それ以外では、es6/es2015。
moduleResolution
おそらく利用する必要はないでしょう。
基本はmoduleに合わせて選択されるデフォルトでよいということか？
bundlerの挙動、気になる
moduleSuffixes
ver 4.7
主なユースケースはReact Nativeとのこと
noResolve
説明読んでもユースケースがよくわからん。
デフォルトの挙動: 起動時に与えられたファイルに含まれるimportとreferenceを解決し、それらもプログラムに追加（評価対象にするってことかな？）
このデフォルトの挙動を無効化。
しかし、import文は正しいモジュールを解決しているかどうかチェックされるため、これが満たされているかどうかを他の方法で確認する必要があります。
この一文が謎
Ver 不明
paths
alias作るやつ
Ver 不明
resolveJsonModule
.jsonをimport可能にする、かつ、型も付く。
allowArbitraryFile？でも行ける？まぁ旨みないと思うけど。トランスパイル時、コピーしてくれるのか
Ver 不明
resolvePackageJsonExports
package.jsonのexportsフィールドを評価するか。
moduleResolutionがnode16, nodenext, bundlerの場合はデフォルトでtrue、それ以外はfalse
Ver不明
resolvePackageJsonImports
同上
rootDir
デフォルト値
型定義ファイルでないすべての入力ファイルの中での最長の共通パス。compositeが設定されている場合、この値の代わりにtsconfig.jsonを含むディレクトリがデフォルトとなります。
Ver 1.5
rootDirs
出力時の相対パスが調整されるってことかな？
Ver 2.0
typeRoots
デフォルトはnode_modules/@types
npm パッケージの解決と同様、ルートディレクトリまで遡る
何かしら設定するとデフォルト値は上書きされるので注意
ということは、何かしら設定してしまうと、その後node_modules/@typesを指定しても同じ挙動にならない？
types
指定したパッケージの@typesだけを評価する。
デフォルトでは、すべての表示されている”@types“パッケージがコンパイル時にインクルードされます。
typeRootsのみ指定していても、typesのデフォルトの挙動でnode_modules/@typesの捜索は行われるの？
Emit
declaration
Ver 1.0
d.ts を出力するか
compositeが有効な場合、デフォルトはtrue。それ以外ではデフォルトはfalse
declarationDir
ver 2.0
d.tsを出力するディレクトリの指定
declarationMap
ver 2.9
.tsにマップする.d.tsのソースマップを出力
downlevelIteration
ver 2.3
for/ofや配列・引数のスプレッドをES5用にトランスパイルするか
Symbol.iteratorが実行時に無い場合、ESと挙動に互換性がなくなる
emitBOM
Ver 不明
デフォルトはfalse
一部の実行環境では JavaScript ファイルを正しく解釈するために、BOM が必要となりますが、他の実行環境では BOM の存在を許容しません。
一部環境とは？
emitDeclarationOnly
d.tsだけ出力するやつ
Ver 2.8
importHelpers
ダウンレベルのトランスパイル時にtslib を使うか
inlineSourceMap
source mapをインラインに吐く
sourceMap と排他
ver 1.5
inlineSources
ソースマップに.tsファイルの内容を文字列として埋め込む
sourceMap or inlineSourceMapのどちらかの設定が必要
Ver 不明
inlineSourceMapといっしょに追加されたっぽいから1.5？
mapRoot
ソースマップの位置を指定。
ex) mapRootが"https://my-website.com/debug/sourcemaps/"の場合、index.jsのソースマップはhttps://my-website.com/debug/sourcemaps/index.js.mapになる
ver 不明
newLine
改行コードの指定。"crlf" or "lf"
デフォルトは "lf"
Ver 1.5
noEmit
ver 不明
.js, .js.map, d.tsを出力せず、型チェックのみ実行
noEmitHelpers
ver 1.5
ヘルパ関数をインポートする代わりに、グローバルスコープのものを使う。
独自のヘルパ関数を利用したい場合に使う
importHelpersも有効にしないと駄目な感じ？
noEmitOnError
ver 1.4
エラー時に出力しない
デフォルトはfalse。
outDir
出力先ディレクトリ
outFile
Ver 1.0
moduleがnone, system, amdの場合に、単一ファイルで出力する。
preserveConstEnums
const enumの定義を取り除かない。
通常は数字に変換されるためメモリ使用量を削減できる。
※ドキュメントのコード例がわかりやすい
デフォルト：isolatedModulesが有効な場合はtrue, そうじゃない場合はfalse
removeComments
コメントを消すかどうか。デフォルトはfalse
sourceMap
ソースマップファイルを出力するか。
デフォルト：不明
Ver：不明
sourceRoot
デバッガが TypeScript のファイルを探索すべき場所を明示
mapRootとの違いは？
あとデバッガとソースマップ、sourceRootの関係が気になった
stripInternal
@internal が付与されたコードについて定義情報を出力しない。
コンパイラが内部で利用するためのものらしい。
「自己責任で使ってください」とのこと
デフォルトはfalse。
Ver 不明
JavaScript Support
allowJs
Ver 1.8
.jsをプロジェクトにimportできる
checkJs
Ver 2.3
allowJsと連動。JS内のエラーが報告されるようになる
全ての.jsファイルの先頭に // @ts-check を付けたのと同じ状態
maxNodeModuleJsDepth
node_modules配下で依存関係を探す際に、JSファイルをロードする最大の深さ
allowJsが有効化されているときに指定可能。
デフォルトは0。0が理想。
Editor Support
disableSizeLimit
TSに割り当てられるメモリ量の上限を取っ払う
気になる。
Ver 不明
plugins
エディタ内部で動作させるLanguage Serviceのプラグインを列挙
Language ServiceでTS・エディタ間でやり取りしているメッセージを拡張するなど。
VS CodeにはLanguage Serviceプラグインの自動読み込み機能があるらしいので、tsconfig.jsonで指定する必要がないらしい
Interop Constraints
allowSyntheticDefaultImports
雰囲気代表。
Ver 1.8
default exportされていない場合でも import React from 'react' できるようにする。
出力するJSには影響なし、型チェックのみ影響がある。
デフォルト値
esModuleInteropが有効な場合 or module is system or moduleResolution is bundler、true
それ以外では false
esModuleInterop
Ver 2.7
ES ModuleとCommonJSで相互運用可能なコードを出力
これを有効にすると、owSyntheticDefaultImportsも有効になる
デフォルト
moduleがnode16、nodenextの場合はtrue
パンドラがES Moduleのままで読むようになったのでnpm package 作る時くらいか？
forceConsistentCasingInFileNames
ファイル名を大文字小文字を区別するか
デフォルトtrue
Ver 不明
isolatedDeclarations
ver 5.5
TypeScript: Documentation - TypeScript 5.5
exportに対して明示的に型を定義していない場合にエラーになる。
現時点で恩恵はないが、型定義の出力に関するパフォーマンス的な課題を解決する目的で追加された
declaration or compositeのどちらかが有効である必要あり
デフォルトは不明。多分、false？
isolatedModules
単一ファイルのトランスパイル処理で正しく解釈できないコードがエラーになる。
- 値ではない識別子のエクスポート
- Moduleではないファイル
- const enumのメンバー参照
- const enumであるという情報がないと正しくトランスパイルできないため
デフォルト true
preserveSymlinks
verbatimModuleSyntax
teppeisさんの記事がわかりやすい
Backwards Compatibility
charset
deprecated
今はUTF8前提でエンコードされる
default utf8
importsNotUsedAsValues
importの動作を制御
remove = 型のみを参照するimportを削除
presesrve = 全てのimportを保持
error = preserveと同じだが、importで型のみをインポートしている場合にエラー
Ver 3.8
keyofStringsOnly
Deprecated
Ver 2.9
keyofがstring | numberではなくstringになる
TS 2.9より前の挙動を維持したい場合に使う
noImplicitUseStrict
TSは、ES6でないターゲットでモジュールを出力する場合に "use strict"; を付与するが、それを無効にする
noStrictGenericChecks
Ver 2.4
TSは、ジェネリクスの型パラメタを統合して比較するがそれを無効にする
out
Deprecated
outがoutFileとoutDirになったんだっけ？outFileを使えとのこと
preserveValueImports
Ver 4.5
importを常に残す
suppressExcessPropertyErrors
型に定義されていないプロパティを定義している場合に出るエラーを抑制
Ver1.6でこの辺が厳密になったので、ver1.6より前の状態にするためのやつ
suppressImplicitAnyIndexErrors
オブジェクトのインデックスにアクセスした時の暗黙的なanyに対するエラーを抑制
このオプションは影響がでかいので、@ts-ignore使うことを推奨
Language and Environment
emitDecoratorMetadata
Decorator利用時にメタデータを埋める
experimentalDecorators
Decoratorのさぽーと
jsx
Ver 2.2
preserve、react-native JSXを変換せずに.jsxを出力
react React.createElementを使って変換
react-jsx, react-jsxdevの説明がないけど、他のオプションと関係あるんだっけ？
jsxFactory
Ver 不明
デフォルト：React.createElement
jsxFragmentFactory
Ver 4.0
デフォルト：React.Fragment
JSX フラグメントファクトリ関数の指定
jsxImportSource
Ver 4.1
デフォルト： react
jsxがreact-jsxの場合は、react/jsx-runtimeになる
/** @jsxImportSource ... */ でも指定可能
lib
ver 2.0
説明不要
targetで指定した値によってJS API・ブラウザ APIの型定義が決まるが、その挙動を買えたい場合に使うやつ。
moduleDetection
ver 4.7
ファイルがscriptなのかmoduleなのかをどう判定するか
auto(default)
ファイル内にimport/export文があるかに加えて、以下の場合にmoduleと判定
- moduleがnodenext or node16の場合にpackage.jsonのtypeフィールドがmoduleである、
- jsxがreact-jsxの場合のJSXファイルである
legacy
ファイル内にimport/export文があるか
force
型定義ファイル以外の全てのファイルをmoduleとして扱う
デフォルトはauto
script or moduleって何ってのが知りたい
Scripts and modules in JavaScript
script/moduleの違いは、大まかにファイルで独自のスコープを持つか
noLib
libを無視
reactNamespace
デフォルト：React
jsxFactoryを使ってね、とのこと。
まだdepreacatedではない
target
Ver 1.0
おなじみ。
「どの JS 機能が古い JavaScript 構文にトランスパイルされ、どの機能がそのまま残されるか」
targetによってlibのデフォルト値が変わる。
emitしない場合、必要なのか？libを指定するためだけに必要って感じする。
useDefineForClassFields
targetがES2022以上の場合はtrue、それ以外はfalse
TSはClassのフィールド定義について、ESより先に実装したため、トランスパイル時にESに寄せるためのフラグ
Ver 3.7
Compiler Diagnostics
diagnostics
deprecated
Ver 不明
デバッグ用にコンパイラからの診断情報を出力するために使われてたらしい
今は extendedDiagnostics を使ってね、とのこと。こっちのほうが情報量多い的な感じ？
explainFiles
Ver 4.2
コンパイル対象のファイルと、そのファイルがなぜ対象になったかを出力
extendedDiagnostics
Ver 不明
TSがコンパイル時にどの程度の時間をどこに使っているかわかる
generateCpuProfile
Ver 3.7
v8のCPUプロファイルを出力。
ビルドが遅くなる原因を示唆してくれるらしい。
listEmittedFiles
生成されたファイル名を出力
listFiles
コンパイルされるファイル名を出力
noCheck
型チェックしない。出力だけしたいという場合によい
traceResolution
Ver 2.0
あるモジュールがコンパイル対象に含まれない理由をデバッグするために使う
Projects
composite
Ver 3.0
有効な場合、以下になる。
- rootDirのデフォルト値がtsconfig.jsonを含むディレクトリになる
- 全ての実装ファイルはincludes/filesに含まれる必要あり。
- declarationのデフォルト値がtrueになる
disableReferencedProjectLoad
Ver 4.0
デフォルトではTSは利用可能な全てのプロジェクトをメモリに読み込むが、それを無効にする。
無効にした場合、エディタでファイルを開いた時に動的にプロジェクトが読み込まれる
disableSolutionSearching
Ver 3.8
エディタのfind all referencesや定義の移動等に含めたく無いファイルを指定するのに使う。
disableSourceOfProjectReferenceRedirect
Ver 3.7
複合TSプロジェクトってなんやねん
3.7より前の挙動に戻す時に使うやつ
incremental
Ver 3.4
インクリメンタルビルドするやつ
.tsbuildinfoファイルの出力
compositeが有効な場合は常にtrue
tsBuildInfoFile
Ver 3.4
.tsbuildinfoの出力先
Output Formatting
noErrorTruncation
デフォルトはfalse
trueの場合、エラーメッセージを切り捨てない
（ん？サンプルコード、前後で全く同じじゃない？）
preserveWatchOutput
有効にすると、watchモード時にスクリーンをクリアしない
pretty
default = true
TSが出力するエラーメッセージ等をきれいに出す
Completeness
skipDefaultLibCheck
デフォルトのライブラリ型定義ファイルをチェックしない
skipLibCheckを使ってねとのこと
skipLibCheck
Ver 2.0
型定義ファイルのチェックをスキップ。
Comand Line
(なし)
Watch Options
Ver 3.8に新戦略が導入されたらしい。
が、プロジェクトによって戦略を変えることができたほうがいいよね？とのことで、watchOptionsが導入されたよ
(このあとのオプションは全部watchOptionsのやつってこと？)
assumeChangesOnlyAffectDirectDependencies
ver 3.8
変更されたファイルとそれらを直接importしているファイルのみを再チェック・再ビルドする
watchFile
Ver 3.8
ファイルの監視方法
デフォルトはuseFsEvents。ファイルシステムのネイティブイベントを利用。
fixedPollingInterval
全てのファイルの変更を一定間隔で毎秒数回
priorityPollingInterval
watchDirectory
Ver 3.8
ディレクトリツリーの監視戦略
デフォルトはuseFsEventsで、ファイルシステムのイベントを活用
fallbackPolling
Ver 3.8
ファイルシステムのイベント利用時に利用不可な場合の戦略
synchronousWatchDirectory
再帰的な監視をネイティブで対応していないプラットフォームに同期的にコールバックを呼ぶか
わからん
excludeDirectories
監視の対象外ディレクトリを指定
excludeFiles
監視の対象外ファイルを指定
Type Acquisition
JSのプロジェクト用。モジュールに対する型をバックグラウンドでダウンロードしてくれる機能。
enable
Type Acquisitionの有効化
include
DefinitelyTypedから利用するモジュールを明示的に指定。
exclude
Type Acquisitionを無効にするモジュールを指定。
jestとかmochaとか、テスト系のライブラリをアプリケーション側で無効にしたい場合に有用
disableFilenameBasedTypeAcquisition
Ver 4.1
デフォルトの挙動はファイル名でダウンロードするモジュールを選定している。
例えば、jquery.jsがプロジェクトがある場合に、DefinitelyTypedからjqueryをダウンロードするみたいな感じで。
それを無効にするオプション。
files
対象ファイルの指定
ファイルが見つからない場合はエラー
デフォルトはfalse
extends
Ver 2.1
ベースとなるファイルの設定を、継承側がオーバーライドするらしいが、これは体感と違うな〜。
files, includes, excludeはベースのファイルが上書きする。
include
Ver 2.0
含めるファイルの指定。
*, **は知っていたけど、?（ディレクトリセパレータを除く任意の1文字にマッチ）は知らなかった。
exclude
デフォルト node_modules, bower_components, jspm_packages, outDirに指定しているディレクトリ
includeに対する除外指定であり、TSが読み込むファイルから除外という意味では使えないので注意
references
デフォルト false
see https://www.typescriptlang.org/docs/handbook/project-references.html
tsconfigに関するドキュメントが追加されたの、2019/08説ある
Discussion