依存ライブラリ更新のリスク評価
changelogから、実際に踏む破壊的変更を掘り出す
［依存名］を［現在のバージョン］から［目標バージョン］に上げたい。プロジェクト内の呼び出しは約［N］箇所です。次をお願いします：1）2つのバージョン間の破壊的変更のうち、私に影響しうるものをすべて挙げ、実際に呼び出しているものだけに絞る；2）「必ず変更／変更したほうがよい／変更しなくてよい」に分け、それぞれ修正方法を示す；3）更新の順序を示す（どれを先に上げるか、2回に分けるべきか）；4）更新後に実行時になって初めて出やすい問題と、ローカルで事前に確かめる方法を示す。 ［changelogと依存設定を貼り付けてください］
使い方
バージョン番号だけでなく、changelogの原文も貼りましょう。なければ、実際には存在しない変更を作り上げます。
向いている場面
- メジャーバージョンをまたぐ更新（React 17→18、webpack 4→5、Spring Boot 2→3）で、changelog が長すぎて読み切れないとき。
- セキュリティ勧告で期限が決まっており、npm update の前に作業量を見積もる必要があるとき。
向いていない場面
- 1.4.2→1.4.3 のような patch 更新で、changelog に破壊的変更がないなら、そのまま上げてテストを走らせます。
- devDependencies のみ、またはビルド時にしか使わない依存なら、実行時のリスクはゼロです。本番基準で評価しません。
例
入力
"react": "17.0.2" -> "18.2.0" 呼び出し箇所：ReactDOM.render が 46 箇所、いずれも 2 つのエントリファイルに集中。componentWillReceiveProps を使うクラスコンポーネントが 3 つ。テストは enzyme に依存。 changelog：automatic batching、StrictMode での effect の二重呼び出し、ReactDOM.render の非推奨化、componentWillReceiveProps の削除。
得られるもの
ReactDOM.render の 46 箇所と componentWillReceiveProps の 3 箇所を「必ず変更」に分類し、render の呼び出しは 2 つのエントリで createRoot に集約できると示します。enzyme のアダプタ更新は「変更したほうがよい」に入れます。automatic batching による描画回数の変化は「実行時にしか出ない」と印を付け、描画回数を検証しているテストが落ちると警告します。順序はテスト環境、次にエントリファイルです。
よくある誤用
- changelog だけを貼り、自分の呼び出し箇所や使い方を渡さないと、すべての破壊的変更が自分の作業量として計上されます。
- 6 つの依存を一度に上げると、問題が出たときにどれが原因か二分探索できません。
こう変えると効く
- `grep -rn "ReactDOM.render" src | wc -l` の実数と対象ファイルを添えると、分類が「影響しうる」から「必ず変更」に変わります。
- 「一度に実行できるローカル検証スクリプトを 1 つ」と加えると、評価が実行可能な手順になります。