本篇文章更新時間：2026/03/23
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
JavaScript 依賴為何越變越肥？讀《The Three Pillars of JavaScript Bloat》有感
編輯前言：這篇文章來自 The Three Pillars of JavaScript Bloat。原作者點出了 Node.js 與前端生態中長年難解的「依賴膨脹」問題，並歸納出三大真正的罪魁禍首。對於任何寫 JavaScript 的人，這篇文章都像是一面照妖鏡，照出我們日常開發理所當然背後的隱性成本。
核心觀點 (Key Takeaways)
- 依賴膨脹有三個主要來源：老舊環境支援、原子化套件、過期的 ponyfills。
- 多數開發者其實不需要「跨 realm 安全性」或「ES3 支援」這些功能，但卻默默為此付出效能與維護成本。
- 套件原子化本意良好，但現實是：大量微型套件成了單一用途、重複、且容易被攻擊的供應鏈風險。
- ponyfills 若不在時機到來時退出舞台，會長期占用樹狀依賴，成為無謂負擔。
深入解析
原文把 JavaScript 生態中的 bloat（臃腫）來源分成三大類，讀完後我覺得每一項都打中了痛點，尤其是作為長期使用 npm 的開發者，依賴地獄我們都經歷過，但原因一直不夠清楚。
「這些層層相依的套件，本來只應該屬於極少數需要它的人。」
1. 老舊環境支援（ES3 / 跨 realm / 全域安全性）
這類依賴常見於早期工具鏈。例如：
- is-string
- hasown
- safe-regex
它們存在的原因包括：
- 需要支援 ES3 引擎（例如 IE6）
- 保護 global namespace 不被污染
- 需要跨 realm（iframe / VM）正確判斷資料型別
但現實是：大部分開發者使用的是過去 10 年內的 Node 版本或 evergreen browsers。我們根本不會遇到這些極端情況，卻仍默默安裝了這些 polyfill 風格的套件。
2. 套件原子化（Atomic Architecture）
這一段我邊讀邊苦笑。原文中舉的例子太經典：
- arrify：把值轉成陣列
- slash：把路徑中的反斜線換成斜線
- onetime：確保函式只能呼叫一次
- is-wsl、is-windows：判斷平台
原子化的本意，是希望日後能組合成更高層的工具。但結果是：
- 套件彼此重複使用率極低
- 多版本重複（例如 is-wsl、path-key）
- 供應鏈風險爆炸性增加
原文提到某位維護多個微型套件的作者去年帳號遭入侵，瞬間牽動數百個依賴，這就是「微型化過度」的後果。
3. 過期的 ponyfills
ponyfill 就是不用汙染全域、可取代未來 API 的替代方案。概念良好，但問題是：很多 ponyfills 在原生 API 已普及後，仍繼續留在依賴裡不走。
例如：
- globalthis（已普及於 2019）
- indexof（Array.prototype.indexOf 2010 就有了）
- object.entries（主流瀏覽器 2017 就支援）
這些 ponyfills 在今天幾乎 100% 不需要，但仍每週被下載上千萬次，只因沒人把它們移除。
筆者心得與啟發
讀完這篇後，我最大的感受是：依賴膨脹並不是因為開發者懶，而是因為歷史包袱被自動繼承下來，從沒被真正清算。
這篇文章也提醒我，在專案中：
- 要勇於問：「我真的需要這個套件嗎？」
- 面對僅做單一功能的微型套件，要三思是否值得引入
- 若原生方法已滿足需求，應該主動移除 ponyfills
- 用工具（如 knip、e18e CLI、npmgraph）檢查依賴樹，找出不必要套件
我特別認同作者最後那句：
「這小群需要特殊環境的人，應該付出自己的成本，而不是讓整個生態圈替他們買單。」
未來我們都會持續依賴 npm 生態，但依賴不必然等於臃腫。開始問「為什麼？」就是精簡的第一步。