4 月 25 日，一個名為 is-promise 的 npm 庫進行了更新並發布了 v2.2.0 版本，沒想到這一次更新卻使 JavaScript 生態陷入危機，據媒體報導，目前已有數百萬個項目受到了影響，而事件的始作俑者竟是一個僅僅「單行」的 JavaScript 庫。
事件回顧
is-promise 庫主要用來測試 JavaScript 對象是否為「Promise」，並在開發時使用該函數返回布爾值 yes 或 no，開發者可以通過 one-liner 調用並在自己的項目中使用這個庫。4 月 25 日，is-promise 正常進行更新，發布了 is-promise v2.2.0，但由於該版本並未遵循正確的 ES 模塊標準，從而導致更新完成後，由於不正確的 ES 模塊標準，所有在構建時使用 is-promise 庫的項目幾乎全部發生故障。雖然這一錯誤不會使現有項目崩潰，但它卻對開發者編譯自己項目的新版本造成了影響。
來看一下「肇事者」：
declare function isPromise<T, S>(obj: Promise<T> | S): obj is Promise<T>;
export default isPromise;
雖然這個問題立即就被發現了，但仍影響到了一些 JavaScript 生態系統中的「大項目」，其中包括 Facebook 的 Create App，三大框架之一的 Angular，Google 的 Firebase 工具，亞馬遜的 AWS Serverless CLI，Nuxt.js，AVA 等等。很多開發者都表示受到了影響：
https://github.com/then/is-promise/issues/13
GitHub 上顯示，與該庫有依賴關係的項目超過 340 萬個。
該團隊在第一時間發布了 is-promise v2.2.1 更新，但是並未能解決問題，最終在幾個小時後發布的 is-promise v2.2.2 中修正了 ES 模塊支持的問題，這一「緊急事件」才落下帷幕。
並非第一起事故
僅僅兩行代碼就造成了這麼大的影響，實際上這並不是第一次發生。早在 2016 年 3 月，一個名為 left-pad 且僅有 17 行代碼的 npm 庫也曾引發過一起事故，起因是這個庫的作者創建了一個 npm 模塊並命名為 kik，這個名字與當時的一個聊天軟體 Kik 如出一轍，所以 Kik 的負責人找到該作者並希望他換一個名字，結果雙方並沒有談妥，該作者一氣之下突然決定取消發布所有的庫，導致無數項目出現事故。
與 2016 年一樣，「is-promise 事件」引發了一眾開發者的疑問：是否需要在 JavaScript 生態中提供 one-liner 庫？JavaScript 模塊化究竟是否必需？
JavaScript 模塊化
一部分開發者認為，當開發人員創建這種只有幾行代碼的庫時，模塊化實在是過於繁瑣；而另一部分開發者則認為，模塊化十分有必要，某一個任務可以在其對應的模塊內統一管理，而不是讓開發者以不同的方式在自己的項目中處理。
對於一個複雜的 Web 應用來說，模塊化編程顯然是一個更具優勢的選擇，很多 JavaScript 庫都是這樣實現的。在 ES6 之前，很多前端社區曾自己鑽研模塊化開發，經歷了 AMD/CMD/UMD 等階段，這裡不過多贅述。ES6 中首次引入模塊化開發規範，讓 Javascript 首次支持原生模塊化開發，從此，JavaScript 模塊化被越來越多的開發者接受。
JavaScript 模塊化也說明了 Web 的能力在不斷增強，Web 應用日趨複雜。相信未來 JavaScript 的能力會繼續提升，前端開發者們的開發效率也會更加高效。
關注我，並私信我「領取資料」，即可免費獲得InfoQ價值4999元迷你書！