1. 為什么現(xiàn)在可以動手清理 package.json 了如果你維護過超過兩年的前端項目打開package.json的那一刻大概率會有一種翻舊倉庫的感覺有些依賴你根本想不起來當初為什么裝有些依賴的 GitHub 倉庫已經(jīng)兩年沒提交還有些依賴你每次npm install都會看到一行黃色的 deprecated 警告但一直懶得處理。更麻煩的是這些“僵尸依賴”并不會安靜地待著它們會拖慢安裝速度、撐大node_modules、在 CI 里制造偶發(fā)失敗甚至在安全掃描報告里給你添幾條高危告警。我最近花了幾個晚上把手上三個項目的依賴樹從頭到尾過了一遍刪掉了十幾個包其中有一批是“曾經(jīng)必須、現(xiàn)在多余”的典型代表。這篇文章就圍繞其中最有代表性的 5 個 npm 包展開講清楚它們當年為什么被裝進來、現(xiàn)在為什么可以刪、刪掉之后用什么替代、以及刪除過程中容易踩的坑。適合所有還在維護 JavaScript 項目的人看不管你是剛接手老項目的新人還是想給依賴做減法的老手都能直接照著操作。需要先說明一點這里說的“可以刪”不是絕對的而是指在現(xiàn)代運行時環(huán)境和主流構(gòu)建工具鏈下這些包提供的功能已經(jīng)被語言本身或平臺原生能力覆蓋。如果你的項目還跑在非常老的 Node 版本上或者有特殊的兼容性要求那刪除前需要自己評估。下面每一節(jié)我都會把判斷依據(jù)講清楚你可以對照自己的項目決定。2. 五個可以優(yōu)先清理的 npm 包逐個拆解2.1node-domexception被運行時原生能力取代的典型如果你在終端里見過這行警告npm warn deprecated node-domexception1.0.0: Use your platforms native DOMException instead那你項目里就躺著這個包。它的作用非常簡單在 Node 環(huán)境里提供一個DOMException的實現(xiàn)。早年 Node 沒有全局的DOMException而一些 Web API 風格的庫比如某些 fetch 實現(xiàn)、流處理庫需要拋出符合規(guī)范的異常對象于是就有人做了這個 polyfill?，F(xiàn)在的情況是Node 17 開始就已經(jīng)內(nèi)置了全局DOMException主流 LTS 版本18、20、22全都有。也就是說這個包的存在意義已經(jīng)被運行時本身接管了。它通常不是你直接安裝的而是某個上游依賴的依賴所以你在package.json里可能根本找不到它需要在node_modules里往上追。判斷方法很簡單在項目根目錄執(zhí)行npm ls node-domexception如果輸出顯示它是某個包的傳遞依賴那你要做的不是直接刪而是升級那個上游包。我遇到的情況是某個老版本的fetch相關(guān)庫鎖死了舊依賴升級到最新版之后node-domexception就自動消失了。這里有個經(jīng)驗不要手動去node_modules里刪文件夾那樣下次安裝又會回來而且可能破壞依賴樹。正確做法是通過npm dedupe或者升級上游包來解決。注意如果你的項目需要支持 Node 16 及以下版本那這個包可能還有存在價值。但 Node 16 已經(jīng)停止維護繼續(xù)支持它的成本遠高于收益建議借這個機會把運行時版本要求提上去。2.2core-js的全量引入從“保險”變成“負擔”core-js本身不是垃圾包它是 JavaScript 標準庫 polyfill 的中流砥柱。問題出在引入方式上。很多項目在入口文件里寫一行import core-js或者用babel的useBuiltIns: entry配置把整個 polyfill 庫全量打進來。這一下就是幾百 KB 的代碼而你的項目可能只用到其中不到 5% 的特性?，F(xiàn)在可以刪的理由有兩個。第一現(xiàn)代瀏覽器對 ES2015 的支持已經(jīng)非常完整Promise、Array.from、Object.assign、展開運算符這些當年需要 polyfill 的東西現(xiàn)在全都是原生支持。第二構(gòu)建工具的能力上來了babel/preset-env配合useBuiltIns: usage可以做到按需注入只為你實際用到的 API 引入對應的 polyfill而且browserslist配置能精確控制目標環(huán)境。我自己的做法是先把browserslist更新到只覆蓋最近兩年的主流瀏覽器然后把core-js的全量引入改成按需模式最后跑一遍構(gòu)建對比產(chǎn)物大小。實測一個中等規(guī)模的項目JS 產(chǎn)物從 480KB 降到了 310KBgzip 后也有明顯下降。如果你的項目壓根不需要支持 IE 或老版本 Safari甚至可以直接把core-js從依賴里移除讓構(gòu)建工具根據(jù)browserslist自動決定要不要注入。具體操作上檢查babel.config.js或.babelrc// 改造前 presets: [ [babel/preset-env, { useBuiltIns: entry, corejs: 3 }] ] // 改造后 presets: [ [babel/preset-env, { useBuiltIns: usage, corejs: 3 }] ]同時把入口文件里的import core-js刪掉。改完之后一定要跑完整的回歸測試因為按需注入偶爾會漏掉一些動態(tài)調(diào)用的場景比如通過字符串拼接調(diào)用的方法。2.3moment體積與不可變性的雙重問題moment曾經(jīng)是日期處理的默認選擇但它的問題這些年被討論得很充分體積大壓縮后約 70KBgzip 后約 20KB、不支持 tree-shaking、對象可變導致容易寫出 bug、時區(qū)處理需要額外加載數(shù)據(jù)。更重要的是官方自己已經(jīng)在文檔里建議新項目考慮其他方案?，F(xiàn)在替代方案很成熟。如果只是做簡單的格式化和計算date-fns是首選它按函數(shù)導入tree-shaking 友好而且所有操作都是純函數(shù)不會意外修改原對象。如果項目對時區(qū)有強需求Luxon或者Day.js配合時區(qū)插件都能覆蓋。Day.js的 API 和moment高度相似遷移成本最低體積卻只有 2KB 左右。遷移的時候有個細節(jié)要注意moment的format占位符和date-fns不完全一樣。比如moment用YYYY-MM-DDdate-fns也是yyyy-MM-dd大小寫有區(qū)別。我建議寫一個小的適配層把項目里常用的格式化、解析、比較操作封裝成統(tǒng)一函數(shù)底層換實現(xiàn)這樣業(yè)務代碼改動最小。// 適配層示例 import { format, parseISO, differenceInDays } from date-fns; export function formatDate(date, pattern yyyy-MM-dd) { return format(typeof date string ? parseISO(date) : date, pattern); }這樣遷移的時候只需要改這一個文件業(yè)務代碼里的調(diào)用方式保持不變。實測一個用了moment三年多的項目半天時間就完成了替換產(chǎn)物里直接少了一個大塊頭。2.4request早已停止維護的 HTTP 客戶端request這個包在 Node 生態(tài)里曾經(jīng)是神一樣的存在下載量長期霸榜。但它在 2020 年就已經(jīng)進入維護停止狀態(tài)官方明確表示不再添加新功能只做最低限度的安全修復?，F(xiàn)在繼續(xù)用它等于把一個不再更新的網(wǎng)絡層放在項目最核心的位置。替代方案在 Node 18 里非常直接全局fetch已經(jīng)可用不需要任何依賴。如果項目需要更細粒度的控制比如攔截器、超時重試、代理配置undici是 Node 官方團隊維護的底層實現(xiàn)axios也依然活躍且生態(tài)成熟。我的建議是新代碼一律用原生fetch老代碼逐步遷移。遷移request的難點在于它的 API 風格和fetch差異較大。request用回調(diào)配置項叫uri、qs、form而fetch用 Promise配置項是url、searchParams、body。我通常寫一個薄封裝來抹平差異async function httpGet(url, options {}) { const res await fetch(url, { method: GET, ...options }); if (!res.ok) throw new Error(HTTP ${res.status}); return res.json(); }然后把項目里所有request.get(...)替換成httpGet(...)。這個過程比較機械但收益很明顯少了一個不再維護的依賴網(wǎng)絡層的行為也更符合現(xiàn)代標準。2.5tslint被 ESLint 完全取代的 lint 工具tslint是 TypeScript 早期的 lint 工具但它的使命已經(jīng)結(jié)束。TypeScript 官方在 2019 年就宣布轉(zhuǎn)向 ESLinttslint進入廢棄狀態(tài)。現(xiàn)在typescript-eslint提供了完整的規(guī)則集而且能和 ESLint 生態(tài)里的其他插件React、Vue、import 排序等無縫配合。如果你的項目還在用tslint遷移到 ESLint 是遲早的事。好消息是官方提供了tslint-to-eslint-config工具可以自動轉(zhuǎn)換大部分配置。操作步驟大致是先安裝eslint、typescript-eslint/parser、typescript-eslint/eslint-plugin然后運行轉(zhuǎn)換工具生成.eslintrc最后逐條檢查規(guī)則映射有些tslint規(guī)則在 ESLint 里沒有直接對應需要手動調(diào)整或放棄。我遷移過一個中型項目轉(zhuǎn)換工具覆蓋了大約 80% 的規(guī)則剩下的 20% 里有一部分是tslint特有的格式規(guī)則現(xiàn)在交給 Prettier 處理更合適。遷移完成后tslint.json和tslint依賴都可以刪掉CI 里的 lint 步驟也統(tǒng)一成一條eslint命令維護成本明顯下降。3. 刪除依賴前的安全操作流程3.1 先摸清依賴樹的真實結(jié)構(gòu)直接打開package.json刪行是最危險的做法因為你看到的只是直接依賴真正的問題往往藏在傳遞依賴里。動手之前先用幾條命令把依賴樹摸清楚。# 查看某個包為什么被安裝 npm ls package-name # 查看所有過時的包 npm outdated # 查看所有 deprecated 的包 npm ls --all 21 | grep -i deprecatednpm ls的輸出會告訴你這個包是被誰引入的是直接依賴還是傳遞依賴。如果是傳遞依賴你要做的是升級上游包而不是直接刪。我習慣把輸出重定向到文件里慢慢分析因為大型項目的依賴樹可能有幾千行。另外npm outdated能幫你發(fā)現(xiàn)哪些包有新版本可用。很多時候升級一個上游包就能順帶解決好幾個 deprecated 的傳遞依賴這比逐個手動處理高效得多。3.2 用鎖文件和 CI 保證刪除不破壞構(gòu)建刪除依賴之后package-lock.json必須同步更新。我的習慣是刪完package.json里的條目后執(zhí)行一次干凈的安裝rm -rf node_modules package-lock.json npm install這樣能確保鎖文件反映真實的依賴關(guān)系不會殘留已經(jīng)刪除的包的記錄。然后跑一遍完整的構(gòu)建和測試包括單元測試、集成測試、以及如果有的話端到端測試。CI 在這里的作用很關(guān)鍵。我會在刪除依賴的 PR 里特意觀察 CI 的安裝耗時和產(chǎn)物大小變化。通常刪掉幾個大包之后npm install能快十幾秒構(gòu)建產(chǎn)物也能小幾十 KB。這些數(shù)據(jù)可以作為刪除決策的佐證也能在代碼評審時說服同事。提示如果項目用了 monorepo 或者 workspace刪除依賴時要檢查所有子包的package.json別只改了根目錄。我踩過一次坑根目錄刪了moment結(jié)果某個子包還在用CI 直接報模塊找不到。3.3 灰度發(fā)布與回滾預案依賴變更屬于基礎設施層面的改動一旦出問題影響面比較大。我的做法是先把改動合并到一個獨立分支部署到預發(fā)環(huán)境跑一兩天觀察錯誤監(jiān)控和性能指標。確認沒問題再合并到主分支。回滾預案也要提前準備好。因為package-lock.json也變了回滾的時候不能只 revert 代碼還要把鎖文件一起恢復。我通常會在 PR 描述里寫清楚回滾步驟比如“revert 這個 commit 后執(zhí)行npm ci重新安裝”。這樣萬一線上出問題值班的人能快速操作。4. 替代方案選型與遷移實操4.1 日期庫遷移從 moment 到 date-fns 的完整對照日期處理是遷移工作量最大的部分因為moment的 API 太靈活了。我把常見的操作整理成對照表遷移的時候可以直接查。操作moment 寫法date-fns 寫法當前時間moment()new Date()格式化moment(d).format(YYYY-MM-DD)format(d, yyyy-MM-dd)解析字符串moment(2026-01-01)parseISO(2026-01-01)加減天數(shù)moment(d).add(7, days)addDays(d, 7)差值moment(a).diff(b, days)differenceInDays(a, b)是否之前moment(a).isBefore(b)isBefore(a, b)注意date-fns的所有函數(shù)都是純函數(shù)不會修改傳入的日期對象。這其實是好事能避免很多隱蔽的 bug但遷移時要檢查業(yè)務代碼里有沒有依賴moment可變性的寫法。比如有些代碼會先const m moment()然后多次調(diào)用m.add(1, day)并期望m本身變化這種寫法在date-fns里必須改成接收返回值。4.2 HTTP 客戶端遷移request 到 fetch 的注意事項fetch和request最大的行為差異在于錯誤處理。request默認把 4xx 和 5xx 也當作正常響應返回需要你自己判斷statusCode而fetch只有在網(wǎng)絡層面失敗時才 rejectHTTP 錯誤狀態(tài)碼不會觸發(fā) catch。所以遷移時一定要顯式檢查res.ok。另一個差異是超時。fetch沒有內(nèi)置的超時配置需要用AbortController實現(xiàn)async function fetchWithTimeout(url, options {}, timeout 5000) { const controller new AbortController(); const timer setTimeout(() controller.abort(), timeout); try { const res await fetch(url, { ...options, signal: controller.signal }); return res; } finally { clearTimeout(timer); } }還有一點fetch不會自動帶上 cookie需要設置credentials: include。如果原來的request配置里有jar: true遷移時別忘了這一項否則登錄態(tài)會丟失。這些都是我實際遷移時踩過的坑寫出來供你參考。4.3 lint 工具遷移tslint 到 typescript-eslint 的配置轉(zhuǎn)換tslint的配置文件是tslint.json規(guī)則名用駝峰或短橫線ESLint 用.eslintrc.js或eslint.config.js規(guī)則名用斜杠分隔。官方轉(zhuǎn)換工具能處理大部分映射但有幾類規(guī)則需要特別注意。格式類規(guī)則比如max-line-length、quotemark、semicolon建議直接關(guān)掉交給 Prettier 處理。類型檢查類規(guī)則比如no-unnecessary-type-assertion在typescript-eslint里有對應實現(xiàn)但需要配置parserOptions.project指向tsconfig.json否則規(guī)則不生效。還有一類tslint特有的規(guī)則比如member-ordering在 ESLint 里也有但配置格式不同需要手動調(diào)整。遷移完成后記得把tslint從devDependencies里刪掉同時刪除tslint.json。CI 配置里的tslint命令也要換成eslint。我建議在遷移的 PR 里單獨提交配置文件的改動和業(yè)務代碼分開這樣評審的時候更清晰。5. 常見問題與排查技巧實錄5.1 刪了包之后構(gòu)建報錯怎么辦最常見的原因是漏改了引用。比如刪了moment但某個工具函數(shù)里還有import moment from moment。排查方法是全局搜索包名grep -r from moment src/ grep -r require(moment) src/如果搜索結(jié)果顯示還有引用要么改掉要么暫時保留這個包。另一種情況是傳遞依賴被破壞比如你升級了某個包它依賴的另一個包版本變了導致 API 不兼容。這時候看構(gòu)建報錯的堆棧定位到具體是哪個包拋的錯然后查它的 changelog 找破壞性變更。還有一種比較隱蔽的情況某些包在運行時動態(tài)加載靜態(tài)搜索搜不到。比如通過字符串拼接的require或者配置文件里寫的包名。這種只能靠完整的回歸測試來覆蓋所以刪除依賴后一定要跑全量測試不能只跑單元測試。5.2 npm install 變慢或報錯怎么處理刪除依賴后如果npm install反而變慢通常是鎖文件沒有正確更新導致 npm 在解析依賴樹時做了多余的工作。解決辦法是刪掉node_modules和package-lock.json重新安裝一次。如果用的是 npm 7 以上版本可以試試npm install --legacy-peer-deps看是不是 peer 依賴沖突導致的。如果報錯信息里有ERESOLVE說明依賴樹里有版本沖突。這時候不要盲目加--force而是用npm ls 沖突的包找到?jīng)_突源頭然后決定是升級還是降級。我遇到過一次ERESOLVE追下去發(fā)現(xiàn)是兩個包分別依賴了同一個庫的不同大版本最后通過升級其中一個包解決了。5.3 如何判斷一個包是否真的可以刪我總結(jié)了一個簡單的判斷清單你可以對照使用判斷維度可以刪的信號需要保留的信號維護狀態(tài)官方標記 deprecated 或兩年無更新近期有活躍提交功能覆蓋運行時或標準庫已原生支持功能獨特無替代使用頻率全局搜索引用少于 3 處核心鏈路大量使用體積占比壓縮后超過 20KB 且可替代體積小且無替代安全記錄有未修復的高危漏洞無已知漏洞按這個清單過一遍大部分“僵尸依賴”都能識別出來。我的經(jīng)驗是一個項目里真正必需的依賴通常不超過直接依賴總數(shù)的一半剩下的要么是歷史遺留要么是可以用更輕量方案替代的。5.4 刪除依賴后如何驗證沒有副作用驗證分三層。第一層是靜態(tài)檢查跑eslint和tsc --noEmit確保沒有類型錯誤和未解析的導入。第二層是單元測試和集成測試覆蓋核心業(yè)務邏輯。第三層是端到端測試模擬真實用戶操作路徑。如果項目沒有端到端測試至少要在預發(fā)環(huán)境手動過一遍關(guān)鍵流程。我通常會列一個檢查清單包括登錄、核心功能、支付如果有、數(shù)據(jù)展示等逐項確認。另外觀察錯誤監(jiān)控平臺一到兩天看有沒有新增的異常。這些步驟看起來繁瑣但比起線上出故障再回滾成本低得多。6. 把依賴清理變成常規(guī)動作依賴清理不應該是一次性的運動而應該變成常規(guī)動作。我現(xiàn)在每個季度會花半天時間做一次依賴審查流程固定下來之后其實很快。先跑npm outdated和npm ls --all | grep deprecated把候選名單列出來然后按上面的判斷清單逐個評估能刪的刪能升級的升級。這樣做的好處是每次改動量都不大風險可控不會像攢了三年再一次性清理那樣牽一發(fā)而動全身。而且依賴樹保持精簡之后npm install快、構(gòu)建快、安全掃描干凈整個開發(fā)體驗都會好很多。最后分享一個我常用的小技巧在package.json里加一個engines字段明確聲明項目支持的 Node 版本范圍。這樣團隊成員和 CI 環(huán)境都會用統(tǒng)一的運行時避免因為 Node 版本差異導致某些 polyfill 包“看起來需要、實際上不需要”的誤判。配合.nvmrc文件新同學克隆項目后一條nvm use就能對齊環(huán)境省去很多溝通成本。