安全地升級一個依賴項
目標：將一個依賴項（或一個緊密耦合的群組）移動到較新版本，要事先理解破壞性變更，而不是事後才發現。
規劃
- 確定當前狀態。 找出已安裝的版本（鎖定檔案，而不僅是清單檔案）和目標版本。如果使用者說「最新」，使用套件管理器查詢（
npm view <pkg> version、pip index versions <pkg>、cargo search等）並給出數值。 - 在乾淨的工作樹上記錄基準：安裝、建置、測試、lint、型別檢查。記下任何預先存在的失敗，以免將它們歸咎於升級。
- 閱讀真實的發行說明。 打開當前版本與目標版本之間每個版本的變更日誌、發行說明或遷移指南。提取：破壞性變更、已移除或重新命名的 API、新的最低運行時版本、更改的預設值、棄用項目。引用每個項目的來源連結。如果找不到發行說明，請說明情況，並將此升級視為更高風險。
- 評估影響。 使用
rg搜尋程式碼庫中每個已移除、重新命名或更改的 API。在編輯之前列出受影響的檔案。
執行
- 僅升級此依賴項（以及必需的對等相依項）。不要執行籠統的「全部更新」。
- 使用專案的套件管理器更新清單檔案和鎖定檔案，不要手動操作。
- 根據說明進行必要的程式碼修改，從最小的開始。當新形式等價時，取代已棄用的用法。
- 再次執行安裝、建置、測試、lint 和型別檢查。與基準進行比較。
- 對於主要版本，如果可行，也執行應用程式或主要範例路徑，並檢查套件大小、啟動警告和棄用警告。
- 如果升級需要提升最低運行時或對等版本，請在更改之前停下來詢問。
報告
Upgrade: <pkg> <from> -> <to>
Sources: <changelog links>
Breaking changes that applied: <list with file refs>
Changes made: <summary>
Verification: <commands, baseline vs after>
Warnings or follow-ups: <deprecations, skipped items, risks>
Rollback: revert <files>, or `git revert <commit>`
規則
- 絕對不要在相同的變更中同時進行升級和重構。
- 絕對不要跳過失敗的測試或放寬版本範圍來隱藏問題。
- 安全修復：僅當你在官方公告或發行說明中看到某個安全公告時，才說明該升級解決了哪個公告。
- 如果傳遞性依賴項導致衝突，請顯示衝突輸出並提出選項，而不是盲目地覆寫。