`tsconfig.json` を制する者はプロジェクトを制す：現場で戦うための設定術
フロントエンドの現場で「なんとなく雛形をコピペして、エラーが出たらネットで見つけた設定を適当に書き足す」という開発、正直に言おう。それ、いつか必ず自分を苦しめることになるぞ。
TypeScriptのプロジェクトにおいて `tsconfig.json` は単なる設定ファイルではない。それは「このプロジェクトがどれだけ厳格であるか」「どれだけ型安全を守り抜く意志があるか」を表明する憲法だ。今回は、中級エンジニアが避けては通れない、この設定ファイルの「真の役割」と「現場で生き残るための黄金構成」を紐解いていく。
—
1. `tsconfig.json` はブラウザの「辞書」ではない
まず大前提を整理しよう。ブラウザはTypeScriptを理解できない。ブラウザが実行するのはあくまでJavaScriptだ。
`tsconfig.json` の最大の役割は、「TSという人間にとって読みやすい言語」を「ブラウザが解釈できるJS」に変換するための『翻訳ルール』を定義することだ。
- コンパイラの挙動制御: どのファイルを見に行くのか（include）、どこを無視するのか（exclude）。
- 型チェックの厳格度: どこまで厳しくコードを縛り上げるのか（strict）。
- JSの出力形式: どのバージョンのJSで出力するか（target）、モジュールシステムはどうするか（module）。
この設定を疎かにすると、開発環境では動くのに、ビルドした途端に謎のランタイムエラーが噴出する……なんていう「現場の悲劇」が待っている。
—
2. 現場で「そのまま使える」黄金のベース構成
多くのプロジェクトで即座に採用できる、堅牢かつモダンな `tsconfig.json` を用意した。なぜこの設定なのか、一つずつ裏側を解説しよう。
{
“compilerOptions”: {
/ — 基本設定 — /
“target”: “ES2022”, // 最新のブラウザ環境を想定。ポリフィルは別途ツールで補うのが現代流
“module”: “ESNext”, // モジュール解決は最新の標準に任せる
“lib”: [“DOM”, “DOM.Iterable”, “ESNext”], // ブラウザAPIの型定義をロード
/ — 厳格さの極み（ここが最重要！） — /
“strict”: true, // 全ての「厳格モード」を有効化。これなしでTSを使う意味はない
“noUnusedLocals”: true, // 使っていない変数を許さない（クリーンなコードの第一歩）
“noUnusedParameters”: true, // 関数の引数も同様。無駄なコードを撲滅する
“noFallthroughCasesInSwitch”: true, // switch文の不意のフォールスルーを検知
/ — モジュール解決 — /
“moduleResolution”: “bundler”, // ViteやWebpack等のモダンなバンドラーに最適化
“esModuleInterop”: true, // CommonJSとESMの共存をスムーズにするための魔法
“skipLibCheck”: true, // node_modules内の型チェックをスキップし、ビルド時間を短縮する
/ — パスエイリアス — /
“baseUrl”: “.”,
“paths”: {
“@/”: [“src/”] // import { foo } from “@/utils/foo” と書けるようにする
}
},
“include”: [“src”], // src配下だけをコンパイル対象にする
“exclude”: [“node_modules”, “dist”] // ビルドに関係ないゴミは除外
}
—
3. なぜ「strict: true」から逃げてはいけないのか
中級者へのアドバイスとして、これだけは断言したい。`strict: false` で運用しているプロジェクトは、実質的に型のないJSを書いてるのと変わらない。
特に重要なのが以下のオプションだ。
- `noImplicitAny`: `any` を暗黙的に許さない。これにより「意図しない `any`」が混入するのを防ぐ。
- `strictNullChecks`: `null` や `undefined` を意識的に処理させる。現場で起きるランタイムエラーの8割はこれらを放置した結果だ。
最初は「型エラーがうるさすぎる！」と感じるかもしれない。だが、そのエラーこそが「将来の自分を救うための警告」なのだ。
—
4. チーフアーキテクトからのワンポイントアドバイス
現場でよくあるのが、後から「このオプションを有効にしたいけど、エラーが多すぎて直せない」という状況だ。そんなときは焦らず、以下の手順で進めるのがプロの流儀だ。
1. 段階的移行: `strict` を一度に有効にするのではなく、`noImplicitAny` など一つずつ有効にして、エラーを潰していく。
2. `// @ts-expect-error` を活用: どうしても修正に時間がかかる場所は、理由を明記して一時的に抑制する。ただし、これは「負債」だ。期限を決めて必ず解消すること。
3. `paths` の活用: プロジェクトが大きくなると `../../../../` のような惨状になる。`paths` を使ってパスの抽象化を行うだけで、コードの可読性と保守性は劇的に向上する。
—
まとめ
`tsconfig.json` は、プロジェクトの「健康診断書」のようなものだ。設定が甘ければ、コードは腐り、開発体験は低下し、バグの温床となる。
今日紹介した設定は、いわば「戦うための防具」だ。まずは自分のプロジェクトの `tsconfig.json` を開き、何が有効で、何が欠けているのかを見直してみてほしい。それが、君がチームを率いる次世代のアーキテクトへの第一歩になる。
何か設定で詰まったら、いつでも聞いてくれ。現場の泥臭い悩み、大歓迎だぞ。
コメント