フロントエンドプロジェクトのライブラリEOL(End of Life)対応計画を作成し、Markdownファイルに出力します。
Creates a comprehensive EOL upgrade plan for frontend libraries, outputting a Markdown file with phased migration steps. Use when you need to update dependencies, especially for major version upgrades or security vulnerabilities.
/plugin marketplace add snhrm/claude-plugin/plugin install fe-eol-checker@claude-pluginフロントエンドプロジェクトのライブラリEOL(End of Life)対応計画を作成し、Markdownファイルに出力します。
$ARGUMENTS: フリーワードで要件を指定できます
/eol-plan react@19 next@15
/eol-plan Node.jsを22系までアップデートしライブラリを可能な範囲で最新化
/eol-plan recoilをjotaiに置き換え
/eol-plan セキュリティ脆弱性のあるパッケージのみ対応
このコマンドは以下のフローで実行します。サブエージェントへの無駄な呼び出しを避けるため、情報収集はこのコマンド内で完結させます。
[Step 1-4] 情報収集(このコマンドで実行)
↓
[Step 5] サブエージェント呼び出し(調査のみ依頼)
↓
[Step 6-7] 戦略決定・計画書作成(このコマンドで実行)
以下の情報を一括で収集(並列実行可能):
# CLAUDE.mdから出力先を確認
grep -i "EOL計画出力先" CLAUDE.md
指定がない場合: プロジェクトルートに eol-plan.md を作成
# ロックファイルの存在確認(優先順位: bun > pnpm > yarn > npm)
ls bun.lockb bun.lock pnpm-lock.yaml yarn.lock package-lock.json 2>/dev/null | head -1
# ソース/テストディレクトリの特定
ls -d src/ app/ pages/ components/ __tests__/ tests/ 2>/dev/null
# バージョンファイルの確認
cat .nvmrc .node-version .tool-versions 2>/dev/null || grep '"node"' package.json
# バージョン管理ツールの特定(優先順位: プロジェクト既存ツール > mise)
ls .nvmrc .node-version .tool-versions mise.toml .mise.toml 2>/dev/null | head -1
| ファイル | ツール |
|---|---|
.nvmrc | nvm |
.node-version | nodenv, fnm, mise等 |
.tool-versions | asdf, mise |
mise.toml / .mise.toml | mise |
| なし | ユーザーに確認(推奨: mise) |
npx npm-check-updates --jsonUpgraded 2>/dev/null || npx npm-check-updates
# パッケージマネージャーに応じて実行
npm audit --json 2>/dev/null || npm audit
yarn audit --json 2>/dev/null || yarn audit
pnpm audit --json 2>/dev/null || pnpm audit
cat package.json
引数の内容を解析し、対象ライブラリを決定:
| パターン | 例 | 処理 |
|---|---|---|
| バージョン指定 | react@19 | 指定バージョンへ更新 |
| ランタイム指定 | Node.js 22系 | 互換ライブラリも含めて計画 |
| ライブラリ置換 | recoilをjotaiに置き換え | 移行計画を作成 |
| 範囲指定 | 可能な範囲で最新化 | 破壊的変更が少ないものから |
| 制約条件 | React 18のまま | 指定ライブラリは現状維持 |
| セキュリティ優先 | 脆弱性のみ | audit結果から絞り込み |
引数がない場合の優先順位:
依存関係が自明なライブラリをグループ化(サブエージェントへの呼び出し回数を削減):
| グループ | メインライブラリ | 関連ライブラリ |
|---|---|---|
| React コア | react | react-dom, @types/react, @types/react-dom |
| Next.js | next | react, react-dom, eslint-config-next |
| Vue コア | vue | @vue/compiler-sfc, vue-router, pinia |
| ESLint | eslint | eslint-config-, eslint-plugin- |
| TypeScript | typescript | @types/*, ts-node |
グループ1: Next.js
- next: 14.0.4 → 15.0.0
- react: 18.2.0 → 19.0.0
- react-dom: 18.2.0 → 19.0.0
- eslint-config-next: 14.0.4 → 15.0.0
グループ2: ESLint
- eslint: 8.x → 9.x
- eslint-plugin-react: x.x → y.y
...
単体: lodash 4.17.20 → 4.17.21
各グループに対して1回ずつサブエージェントを呼び出す。 収集済みの情報を渡し、調査のみを依頼する。
調査対象:
メインライブラリ: next
現在バージョン: 14.0.4
目標バージョン: 15.0.0
関連ライブラリ: [react@18.2.0→19.0.0, react-dom@18.2.0→19.0.0, eslint-config-next@14.0.4→15.0.0]
プロジェクト情報:
パッケージマネージャー: pnpm
Node.jsバージョン: 20.10.0
ソースディレクトリ: src/, app/
テストディレクトリ: __tests__/, *.test.tsx
{
"library": "next",
"breakingChanges": [...],
"deprecations": [...],
"packagesToRemove": [...],
"packagesToUpdate": [...],
"testCoverage": {...},
"summary": {
"affectedFileCount": 5,
"breakingChangeCount": 3,
"estimatedEffort": "medium",
"riskLevel": "medium"
},
"references": {...}
}
サブエージェントの結果を集約し、戦略を決定:
重要: 各Phaseの完了時に必ずlint/testを実行し、問題がないことを確認してから次のPhaseに進む
以下の場合は、1バージョンずつ段階的にアップデートし、各バージョンで挙動を確認する:
| ケース | 例 | 対応 |
|---|---|---|
| メジャーバージョンが2つ以上離れている | React 16 → 18 | 16 → 17 → 18 と順次アップ |
| マイナーバージョンに破壊的変更がある | Next.js 14.1 → 14.2 (App Router変更等) | 1マイナーずつ確認 |
| 非推奨警告が大量に出ている | 警告を解消してから次へ | 警告対応 → アップデート |
# 悪い例: 一気にアップデート
react: 16.8.0 → 19.0.0 ❌
# 良い例: 段階的にアップデート
react: 16.8.0 → 17.0.0 (確認) → 18.0.0 (確認) → 19.0.0 (確認) ✅
複数ライブラリで段階的アップデートが必要な場合、Phase 1〜6を複数サイクル繰り返す:
例: Node.js 20系、React 17系、TanStack Query 3系 を最新化
■ サイクル1(1メジャーずつ上げる)
Phase 1: Node.js 20 → 22
Phase 2: ESLint等を互換バージョンへ
Phase 3: React 17 → 18
Phase 4: UIライブラリを互換バージョンへ
Phase 5: TanStack Query 3 → 4
→ lint/test確認 ✅
■ サイクル2(さらに1メジャー上げる)
Phase 1: Node.js 22 → 24
Phase 2: ESLint等を互換バージョンへ
Phase 3: React 18 → 19
Phase 4: UIライブラリを互換バージョンへ
Phase 5: TanStack Query 4 → 5
→ lint/test確認 ✅
サイクルの組み方:
| 順序 | カテゴリ | 理由 |
|---|---|---|
| 1 | ランタイム・言語基盤 | 他のすべてのライブラリの動作基盤となるため最初に |
| 2 | 品質担保ツール | 以降のアップデートで問題を正しく検知するため |
| 3 | 主要フレームワーク | アプリケーションの中核。周辺ライブラリより先に安定させる |
| 4 | UIライブラリ | フレームワークのバージョンに依存することが多いため、フレームワーク更新後に |
| 5 | 状態管理・データ取得・その他 | UIと連携するため、UIライブラリ更新後に。影響範囲も限定的 |
| 6 | ライブラリ置換 | 既存コードの大幅な変更を伴うため最後に |
サブエージェントの結果を統合し、以下のフォーマットでMDファイルを出力:
# EOL対応計画
作成日: {日付}
対象プロジェクト: {プロジェクト名}
パッケージマネージャー: {npm/yarn/pnpm/bun}
## 概要
| 項目 | 内容 |
|------|------|
| 対象ライブラリ数 | X件 |
| セキュリティ脆弱性 | X件 |
| リスクレベル | {低/中/高} |
| 推奨戦略 | {一括/段階的} |
## セキュリティ監査結果
| パッケージ | 脆弱性レベル | 説明 | 修正バージョン |
|-----------|------------|------|--------------|
## ライブラリグループ
| グループ | メインライブラリ | 関連ライブラリ | 一括アップグレード |
|---------|----------------|---------------|------------------|
## 削除対象パッケージ
| パッケージ | 理由 | 削除タイミング |
|-----------|------|--------------|
## アップグレード戦略
### 推奨アプローチ: {一括/段階的}
{選択理由}
## 段階的アップグレード計画
### Phase 0: 事前準備
**目的**: 破壊的変更が入る箇所を特定し、変更前の挙動を保証するテストを追加する
**破壊的変更の影響箇所**:
| ファイル | 影響を受ける変更 | 現在のテスト有無 |
|---------|----------------|----------------|
**テスト追加が必要な箇所**:
| ファイル | 追加すべきテスト | 理由 |
|---------|----------------|------|
**確認項目**:
- [ ] 破壊的変更の影響箇所をすべてリストアップ
- [ ] 影響箇所のテストを追加(変更前の挙動を保証)
- [ ] `{pm} run lint:fix` 成功
- [ ] `{pm} run test` 成功
- [ ] 現状のテストカバレッジを記録
⚠️ **Phase 0が完了するまで、ライブラリのアップデートは行わない**
💡 テストがあることで、アップデート後に挙動が変わった箇所を検知できる
**lint:fixコマンドがない場合は追加**:
```json
{
"scripts": {
"lint:fix": "eslint src --ext .js,.jsx,.ts,.tsx --fix && tsc --noEmit"
}
}
対象:
破壊的変更への対応:
| 変更内容 | 影響ファイル | 対応方法 |
|---|
アップデートコマンド:
{コマンド}
確認項目:
{pm} run lint:fix 成功{pm} run test 成功(ライブラリ置換が指定された場合のみ)
| 旧API | 新API | 備考 |
|---|
| リスク | 発生確率 | 影響度 | 対策 |
|---|
各フェーズでの問題発生時:
---
## 注意事項
- **情報収集はこのコマンド内で完結**: サブエージェントにはプロジェクト情報を渡す
- **サブエージェントはグループ単位で呼び出し**: 個別ライブラリごとに呼び出さない
- **並列呼び出しを活用**: 依存関係がないグループは並列で調査
- **破壊的変更が多い場合は必ず段階的アップグレード**
- **アップグレードの実行順序を厳守**:
1. Phase 0で不足テストを追加し、lint/testが通ることを確認(ベースライン確立)
2. 各Phaseでアップデート実施後、必ずlint/testを実行して問題がないことを確認
3. 問題があれば解決してから次のPhaseに進む
- **Node.jsのアップデートにはプロジェクトのバージョン管理ツールを使用**:
- プロジェクトに既存のバージョン管理ツール(nvm, nodenv, asdf等)があればそれを使用
- バージョン管理ツールが特定できない場合は、**ユーザーに確認する**(デフォルト推奨: [mise](https://mise.jdx.dev/getting-started.html))
- 計画書にはバージョン管理ツールを使ったアップデート手順を記載すること