JavaScript 膨脹的三大支柱

背景

隨著 JavaScript 生態系不斷擴張，npm 依賴樹的臃腫問題日益嚴重。e18e 社群發起的「清理行動」揭示了許多現代專案仍背負著大量冗餘、過時且早已被原生 API 取代的套件，這引發了關於開發者為何持續使用這些「小微套件」以及如何優化依賴結構的深度討論。

社群觀點

針對 JavaScript 依賴臃腫的現狀，社群內部的討論呈現出明顯的兩極化趨勢。部分開發者認為這反映了技術債的隱形累積，許多專案在編譯目標設定上過於保守。即便 ES5 已普及超過十年，仍有作者堅持相容極其古老的環境，如 Node.js 0.4 或早已退役的瀏覽器。這種對相容性的執著在某些情況下顯得不切實際，因為過度的轉譯與 Polyfill 不僅讓程式碼體積膨脹、執行效率下降，甚至可能因為 Polyfill 實作不當而引入新的錯誤。例如有留言指出，為了支援舊設備而引入的大量執行環境負擔，往往反而讓那些低效能設備更難以負荷，真正要支援舊設備應該從簡化架構著手，而非依賴層層堆疊的補丁。

另一派觀點則將矛頭指向 JavaScript 破碎且混亂的構建生態。開發者在面對 CommonJS 與 ESM 的轉換、TypeScript 編譯以及各式各樣的打包工具（如 Vite、Babel）時，往往感到無所適從。在這種混亂的系統中，使用現成的微型套件往往成為一種避險手段，開發者寧可引入一個功能極其單一的依賴，也不願冒險自己實作可能在不同環境下出錯的原生邏輯。這種「原子化架構」的初衷是為了模組化與複用，但在現實中卻演變成無數單一用途的套件充斥在依賴樹中，造成嚴重的重複勞動與維護成本。

此外，社群也開始反思 JavaScript 缺乏強大標準函式庫的問題。與 Go 等語言相比，JavaScript 的文化更傾向於「套件購物」，而非推動一個受公信力機構認可的標準庫。有討論提議，或許可以開發一種更聰明的套件管理工具，透過覆蓋（Overrides）機制自動將過時的 Polyfill 替換為現代原生的實作，或者建立一個「工具型空缺」的機制，讓專案能根據目標環境動態填補所需的邏輯。然而，只要開發者仍習慣於隨意引入依賴，這種投票式的依賴循環就難以被打破。有趣的是，這種微型套件的風氣似乎也開始影響到 Rust 等新興語言，顯示這可能是現代軟體開發中一種跨語言的普遍現象。

延伸閱讀

• 80/20 Agents: 關於自動化探索與修復邊緣案例的討論。
• Node.js Primordials: 關於 Node.js 內部如何防止全域命名空間污染的技術文件。
• pnpm Overrides: 可用於替換依賴樹中特定套件的配置工具。