第16章：TypeScriptで境界を守る③（CIで取り締まる）🧪👮

ここまでで「境界ルール（importの禁止とか）」は作れたはず！でもね…人間は忘れるし、忙しいと「つい…」が起きるの🥺💦

だからこの章は、CI（自動チェック）を“門番”にして、PRで壊せない仕組みを作るよ〜！🚪🛡️✨

0) 今日のゴール🎯✨

自動門番 (Automated Gatekeeper)

PRを出したら自動で👇が走って、違反があれば赤く落ちる状態にする！

境界チェック（例：内部ファイル直import禁止）🚫📦
Lint（ESLint）🧹
TypeCheck（tsc）🧠
Test（あれば）🧪

そして最後に、**main（またはmaster）へマージする前に「全部パス必須」**にする👮‍♀️✅ （GitHubの保護ブランチ＆Required status checks を使うよ）(GitHub Docs)

1) まずは“CIで叩くコマンド”を用意しよう🧰🧡

CIは「ターミナルで叩けるコマンド」しか実行できないよ！なので package.json に CI用の入口を作るのがコツ✨

{
  "scripts": {
    "lint": "eslint .",
    "typecheck": "tsc -p tsconfig.json --noEmit",
    "test": "vitest run",
    "check": "npm run lint && npm run typecheck && npm run test"
  }
}

--noEmit は「型チェックだけして、JSは出さない」って意味だよ🧠✨
test は Jest / Vitest どっちでもOK！なければ一旦 echo \"no tests\" でも🙆‍♀️（あとで育てよう🌱）

ちなみに TypeScript は現時点で npm の latest が 5.9.3 だよ（最新として表示）(npm) （境界チェックそのものは ESLint ルールでやることが多いよ：例 eslint-plugin-boundaries など）(GitHub)

2) GitHub ActionsでCIを回す🛠️🤖✨

.github/workflows/ci.yml を作って、PRのたびに走らせるよ〜！

ポイントはこれ👇

actions/setup-node は 依存関係キャッシュもできる✨(GitHub)
CIは基本 npm ci が安定（ロックファイル前提）🧊(GitHub)
Nodeは LTSを使うのが事故りにくい（今は v24 が Active LTS）🧡(Node.js)

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

      - name: Install
        run: npm ci

      - name: Lint + TypeCheck + Test
        run: npm run check

actions/setup-node は最近 v6 系が出てるよ(GitHub)
actions/checkout@v4 が基本だよ(GitHub)

Windowsでも回したい人向け🪟💞（任意）

「ランナーをWindowsにする」or「両方で回す」もできるよ！

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
runs-on: ${{ matrix.os }}

（GitHubホステッドランナー自体の仕様も公式ドキュメントにまとまってるよ）(GitHub Docs)

3) “境界違反したらCIが落ちる”を確認しよう😈✅

ここ、めっちゃ大事！ わざと違反して、CIがちゃんと赤くなるかを試すよ🔥

例：

本当は modules/user/index.ts 経由で呼ぶべきなのに
modules/user/internal/xxx.ts を直importしちゃう…とかね🙅‍♀️💥

CIが赤く落ちたら勝ち✌️✨（門番が働いてる！）

4) PRで壊させない：Required status checks を必須化👮‍♀️🚧

CIが動いたら、次は「通らないPRはマージ禁止」にするよ！

GitHub の 保護ブランチで ✅ Require status checks to pass before merging をONにする感じ🛡️(GitHub Docs)

⚠️ ここでハマりがち： 必須にしたいチェックは、過去7日以内にそのリポジトリで実行されてないと選べないことがあるの！だから最初に一回CIを回すのが大事だよ〜！(GitHub Docs)

5) “速くする”小ワザ💨✨（地味に効く）

npm ci を使う（再現性＆安定）(GitHub)
actions/setup-node の cache: npm を使う（速くなりがち）(GitHub)
ロックファイル（package-lock.json）はコミットしておく（超大事）(GitHub)

6) AIで“取り締まりテスト”を爆速にする🤖⚡

① わざと違反PRを作るプロンプト😈

「このルールに違反するimportを1箇所だけ仕込んで、CIが落ちるのを確認したい」
「どのファイルをどう直せば復旧するかも同時に出して」

② CIが落ちたログを貼って聞く🧑‍⚖️

「このCIログ、原因どこ？最短で直す差分案ちょうだい」
「境界違反か、設定ミスか、依存関係か切り分けして」

③ “落ち方”を改善する（メッセージを親切に）💬

ESLintのエラー文が分かりづらいとき、AIに

「初心者が読んでも分かるエラー文にする設定（message）案」を出させるのもアリ✨

章末ミニ課題🧩🎓✨

CIを入れて、PRで npm run check が自動実行されるようにする🧪
わざと境界違反を1箇所作って、CIが赤くなるのを確認する😈
直して緑に戻す✅
main を保護して「CI通過がマージ条件」になるようにする👮‍♀️🛡️(GitHub Docs)

おまけ：pnpm派へ（軽く）🥟✨

pnpmを使うなら Corepack を使う流れが多いけど、Corepackは実験扱い＆ Node 25 から同梱されなくなる注意があるよ⚠️（LTS運用だと安心）(Node.js) pnpmのCIガイドもあるから、必要ならそこに寄せるのが安全だよ〜！(pnpm.io)

次の章は「薄いレイヤー（層）を入れて、モジュール内の整理をもっとラクにする」だよ〜🥞✨ いく？🚀💛