第09章：tsconfig最小セット（まず strict）🧷

🎯目的

• tsconfig を“必要十分”で作れるようになる🧠
• strict を味方にして、TDDのサイクルを安定させる🧪
• import周りで詰まりやすい module / moduleResolution の方向性を決める🌿

---

📚まずイメージ：tsconfig は「型チェックのルールブック」📘

TypeScriptは、コードを読むときに「どう解釈する？どこまで厳しく見る？」を決めないと迷子になっちゃうのね😵‍💫 そのルールが tsconfig.json で、ここが整うと：

• テストを書く前に 型で事故が減る🛡️
• 「たまに落ちる」「環境差で動かない」が減る✨
• AIに聞いたときも、前提が揃うから回答が安定する🤖

---

✅この章の結論（最小セットで大事なのはココだけ！）💡

1. "strict": true（まずON） 　→ strict は“まとめスイッチ”で、将来のTSアップデートでチェックが増えることもあるよ（＝新しい型エラーが出ることがある）🧠✨ (typescriptlang.org)

2. module と moduleResolution を「実行環境」に合わせる

• Node寄りなら nodenext が基本になりやすい（公式もそう案内してるよ） (typescriptlang.org)
• バンドラー（Vite/Vitest）寄りなら bundler が楽（相対importで拡張子を強制しない、など） (typescriptlang.org)

3. target は今のJSに合わせる（ES2023あたり） TypeScript 5.9 だと Node向け設定として node20 みたいな“安定モード”も用意されてるよ（target es2023 を暗黙に使う、など）🧩 (typescriptlang.org) （※2026-01-19 時点の安定版は npm 上は 5.9 系） (NPM)

---

🧷まずはテンプレを1つ選ぼう（迷ったらAが無難）🙂

A) バンドラー/Vitest寄り（おすすめ）🧪🧩

Vite/Vitest系の雰囲気で進めるならこっちがラク！ （相対importで拡張子問題が起きにくいよ） (typescriptlang.org)

{
  "compilerOptions": {
    "target": "ES2023",
    "module": "ESNext",
    "moduleResolution": "Bundler",

    "strict": true,

    "noEmit": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src", "tests"]
}

B) Node（サーバー/CLI）寄り 🟩🖥️

Nodeの実行と相性を取りにいくならこっち。公式的にも Node なら nodenext が基本寄りだよ🌿 (typescriptlang.org)

{
  "compilerOptions": {
    "target": "ES2023",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",

    "strict": true,

    "outDir": "dist",
    "rootDir": "src",
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src", "tests"]
}

💬ちなみに：Node は 2026-01-13 時点で 24.13.0 (LTS) が出てるよ（参考）🟢 (nodejs.org) でも tsconfig は 「安定」優先でOK！“今の最新”に追いかけ回されるより、TDDが気持ちよく回るほうが勝ち🏁✨

---

🧪手を動かす（この章のゴール：型チェックが安定して通る）🔧💨

1) tsconfig を作る（生成→最小に整える）🧰

## まだ tsconfig が無いなら
npx tsc --init --strict

できた tsconfig.json を開いて、上の A or B に寄せて整えるよ✍️✨ （コメントだらけでもOK。まず“動く最小”が正義👑）

---

2) 型チェック用の npm script を用意する🧪

package.json にこれを足す👇

{
  "scripts": {
    "typecheck": "tsc -p tsconfig.json"
  }
}

実行✨

npm run typecheck

---

🧪ミニ演習：strict が“守ってくれる感じ”を体験しよ🛡️✨

❌わざと「strict に怒られる」コードを置く（体験が大事！）😈

src/demo.ts を作ってこれ👇

export function priceLabel(yen) {
  try {
    return yen.toFixed(0) + "円";
  } catch (e) {
    return e.message;
  }
}

npm run typecheck をすると、だいたいこんな系で怒られるはず👇

• yen が any 扱いっぽい（暗黙any）😵
• catch (e) の e が unknown で、message が読めない💥（strictの一部）

---

✅「strict と仲良くする」直し方（最小でOK）🙂

export function priceLabel(yen: number): string {
  try {
    return yen.toFixed(0) + "円";
  } catch (e: unknown) {
    if (e instanceof Error) return e.message;
    return "unknown error";
  }
}

ポイントはこれだけ💡

• 引数・戻り値をまず置く（TDDの“仕様っぽさ”が出る）🧪
• catch は unknown 前提で絞り込み（事故りにくい）🛡️

---

🌿よくある詰まりポイント（ここだけ先に潰す）🧯

① import が地獄…😵‍💫 → moduleResolution を見直す

• バンドラー寄りなら Bundler がラク（相対importで拡張子必須になりにくい） (typescriptlang.org)
• Node寄りなら NodeNext（Nodeの挙動に合わせる） (typescriptlang.org)

② Windowsでは動くのにCIで落ちる😇

だから forceConsistentCasingInFileNames: true は入れとくのが安心だよ🧷 （Windowsは大文字小文字に甘い→CIで爆発💥を予防）

③ skipLibCheck ってズル？🥺

• ズルじゃないよ！🫶
• まずは学習の足を止めないのが大事。必要になったら外せばOK✨

---

🤖AIの使い方（この章のおすすめプロンプト）💬✨

VS CodeのAIにこう聞くと超スムーズだよ〜！🥰

• 「この tsconfig の各オプションを “中学生にも分かる言葉”で1行ずつ説明して」📘
• 「npm run typecheck のエラー貼るね。原因→最小修正→直した結果どう変わるかで教えて」🧑‍🏫
• 「このプロジェクトは（Node / Vite）寄り。module と moduleResolution の最適セットを2案出して、メリデメも書いて」🧩

⚠️コツ：AIの提案はそのまま採用せず、typecheck が通るかで判断ね🧪✅

---

✅チェック（合格ライン）🎓✨

• npm run typecheck が 安定して通る✅
• わざと壊したとき、strict がどこで怒るか説明できる🗣️
• module / moduleResolution を A（Bundler）かB（NodeNext）で選べる🙂

---

必要なら次で、あなたの想定（ライブラリ？小アプリ？NodeのAPI多め？）に合わせて、A/Bどっちが本命かと、“後で困らない最小追加オプション3つ”（例：types の入れ方、lib の考え方、テスト用 tsconfig 分離）までセットで整えるよ〜🧸✨