Dependabot 6PRをpnpm overrides統合PRに集約し、PlaywrightのnetworkidleをCodexレビューで全削除した日

eurekapu-nuxt4でDependabotが7本のPRを開きっぱなしにしていて、全部CIが赤だった。順次rebaseで潰そうとしたら同じpeer依存解決で永遠にループに入りそうになったので、pnpm overrides で4ライブラリを一気に固定する統合PRに切り替えて1本でマージ。さらにE2Eのフレーキー原因だった waitForLoadState('networkidle') をCodex（GPT-5.5）レビューで「SPA遷移後のloadは再発火しないから無意味」と一刀両断され、25箇所まるごと削除。Nuxtのハイドレート前にclickが空振りする3件を expect(...).toBeVisible() の暗黙待機 + expect.toPass({ timeout }) のretryで包んで恒久対策、最終的にCIで全パス、脆弱性73→70、PR #15までマージで一日が終わった。

朝: SVG表示崩れの調査からスタート

いつも通りローカルでビルド確認していたら、トップページに紐づく contents.vue のSVGが本番で表示崩れしていることに気付いた。原因を辿ると、public/images/excel/** が .gitignore で除外されているのに、contents.vue だけが相対パスで public/images/excel/... を参照していた。mainブランチのCIではビルド時にファイルが存在しないので空SVG扱いになっていた。

該当SVGをR2配信のURLに差し替えてビルドを通した。コミットして chore/deps-batch-bump ブランチにpushしようとして、ここで一つ目の事故が起きる。

E2Eテストの期待値が実態とズレていた

ついでにローカルで pnpm test:e2e を回したら、トップページのテストが落ちていた。

// テストコード
expect(await page.locator('.card').count()).toBe(6) // ドラフト枠込みの想定

実際のトップページには .card が5枚しか描画されていない。ドラフト枠を含む期待値だったが、ドラフト枠の表示は別ルートに移っていて、このテストの想定だけが古いままだった。実態に合わせて toBe(5) に直して終了。

E2Eが落ちている本丸はこの後ろにいる。

Dependabot 7PRが全部赤のまま放置されていた

朝の修正作業中にDependabotのPR一覧を確認したら、7本ともCIが赤になっている。

PR #6: postcss
PR #7: simple-git
PR #8: defu
PR #9: vite
PR #10: drizzle-orm
PR #11: lodash
PR #12: 別ライブラリ

順次rebaseで潰そうと最初にPR #6（postcss）とPR #7（simple-git）からマージした。これは素直に通った。脆弱性が73→70に減る。残り4本（defu / vite / drizzle-orm / lodash）に手を付けたところで気付く。

それぞれのPRが微妙に被るpeer依存を持っていて、片方をrebaseするともう片方のlockfileが壊れる。順次マージしていくと、最後の1本にたどり着くまでに残り3本を毎回rebaseし直すループに入る。Dependabotのrebase待ちが直列で積み上がり、CIキューが詰まる。

統合PR #13で `pnpm overrides` 一発固定に切り替え

ループを断ち切るため、4ライブラリを一気に固定する統合PRに切り替えた。package.json に pnpm.overrides でバージョンを固定する。

{
  "pnpm": {
    "overrides": {
      "defu": "^6.1.4",
      "vite": "^7.1.12",
      "drizzle-orm": "^0.44.6",
      "lodash": "^4.17.21"
    }
  }
}

ここで一つ判断ポイントが出た。vite はDependabotがメジャー8系を提案してきていたが、Vite 8への移行は破壊的変更が多く、Nuxt側のpeer互換も怪しい。dependabotの差分を確認して、7系最新の ^7.1.12 に固定する方針に切り替えた。

pnpm install でlockfile再生成、ビルド・テストを通して、4本のDependabot PRをcloseできる統合PR #13として作成した。

別セッションがブランチ衝突を起こしていた

統合PR #13をpushしようとしたら、別セッション（朝のSVG修正側）が同じ chore/deps-batch-bump ブランチで作業を進めていた。SVG側のコミットが先にpushされていて、自分の手元の変更とコンフリクトする。

別セッションへ手紙を書いた。「chore/deps-batch-bump でpnpm overrides作業中。SVG修正は別ブランチに退避してほしい」と internal/2026-05-02/ にメモを置く。並行してこちらは git reset --soft HEAD~N で自分の変更をindexに戻し、新ブランチ chore/deps-overrides-bump に移管した。reset --soft を選んだのは作業内容を絶対に失いたくなかったからで、--hard だと未コミットの修正が消えるリスクがある。

新ブランチでpush、PR #13としてcleanにオープンし直した。CIを通して、Squash and mergeで取り込んだ。

並行してPR #14: 簿記3級ノート9章移植

別件で進めていた簿記3級ノート9章のVue移植 + SVGレビュー反映が固まっていたので、PR #14として上げた。E2EがCIで1件だけ失敗する。/quiz/random の遷移テストで、ロードに時間がかかってタイムアウトしていた。

ローカルでretryすると通る。明らかにフレーキー。再度CI回すと通ったので Squash and merge した。ただしフレーキーを放置すると後で必ず効いてくる。ユーザーから「恒久対策をPRで切ってくれ」とリクエストが来たので、PR #15を立てる。

PR #15: networkidleを25箇所から全削除

E2Eテスト全体を眺めると、page.waitForLoadState('networkidle') がSPAページ遷移直後に大量に書かれていた。4ファイル25箇所。最初は「networkidle は重いから load に置換しよう」と全置換した。

// Before
await page.goto('/quiz')
await page.waitForLoadState('networkidle')

// After（最初の修正案）
await page.goto('/quiz')
await page.waitForLoadState('load')

念のためCodex（GPT-5.5）にレビューを投げた。返ってきた指摘が一刀両断だった。

SPAでルートを切り替えた場合、load イベントは初回ナビゲーション時にしか発火しない。SPA内遷移では load も networkidle も再発火せず、waitForLoadState を呼ぶと即座にresolveするか、最初のloadイベントを参照したまま無意味に待つ。これは恒久対策にならない。削除して、要素のvisibleで暗黙的に待つべき。

その通りだった。25箇所全削除して、要素ベースの待機に切り替えた。

// After（最終案）
await page.goto('/quiz')
await expect(page.locator('.quiz-question')).toBeVisible()

expect(...).toBeVisible() はPlaywrightが自動でretryしてくれるので、ハイドレート完了を実質的に待つことになる。

ハイドレート前clickをexpect.toPassでretry

networkidle を消した後も、3件のテストがハイドレート前にclickが空振りして落ちていた。Nuxtがhydrate完了する前にPlaywrightがclickを発火させると、Vueのイベントリスナーがまだバインドされていないため何も起きない。

これを expect.toPass({ timeout }) でretryするパターンに直した。

await expect(async () => {
  await page.locator('.btn-start').click()
  await expect(page).toHaveURL(/\/quiz\/start/)
}).toPass({ timeout: 10_000 })

toPass はブロック全体を失敗時にretryしてくれる。clickが空振りしてURLが変わらなければ、再度clickしてくれる。これでハイドレート競合が消えた。

error.vue の404ボタンも同様で、Vueのhydrate前にイベントが発火しないため、click() → URL待ち の組をtoPassで包んだ。

結果: 35/36 pass + フレーキー1件

ローカルで35/36 pass。残る1件は /quiz/random ページのロード遅延で、別問題（ページ自体の初期化が遅い）として切り離した。CIに投げたら全パス。PR #15をmergeして閉じた。

振り返り

今日の試行錯誤を時系列で並べると、判断の切り替えが3回あった。

順次rebase → pnpm overrides統合PR: Dependabot 4本を順番に潰そうとしたら依存ループに入りかけた。「1本ずつ正しく」より「全部一発で固定する」方が早いと気付いた瞬間に方針転換した
別セッション衝突 → reset --soft で安全退避: 同じブランチで2セッション動かすと必ず事故る。--hard ではなく --soft を選んだことで作業内容を失わずに済んだ
networkidle置換 → 全削除: 「重いから軽い方に」という発想が、Codexレビューで「そもそも無意味」とひっくり返された。一段深い理解（SPAではload系イベントが再発火しない）に到達できたのはレビューのおかげ

E2Eのフレーキー対策で waitForLoadState を入れていた時期が長かったが、SPAでは要素ベースの待機 + expect.toPass の方が筋がいい。ハイドレート前にclickしても落ちないようretryで包む、というパターンは他のNuxt製E2Eにもそのまま転用できる。

Dependabot側は、PRが3本以上溜まったら順次マージではなく最初から pnpm overrides 統合PRを検討する運用に切り替える。今日のように依存ループに入ってから気付くと、無駄なrebaseで時間を溶かす。