CommonJS 和 ES Module 終于能夠互相兼容了
ECMAScript Module（ESM）逐漸成為現代 JavaScript 開發中的公認行業標準。自從 ESM 被引入到 Node.js 以來，其異步加載特性和模塊解析邏輯受到了廣泛歡迎。
然而，由于歷史原因，許多現有代碼庫和第三方庫仍然依賴于 CommonJS（CJS）模塊系統。由于 ESM 的設計是異步加載的，這兩種模塊化方案一直無法共存，這成為了許多開發者的一個主要痛點。
最近，開發者 joyeecheung 提交了一個重要的 Pull Request 來解決這個問題。
CJS 和 ESM 的過去與現在
在 JavaScript 的世界里，模塊化是構建大型應用程序的基礎。模塊化幫助開發者管理代碼而不影響全局命名空間，使得分離功能、重用代碼和管理依賴變得更加容易。在 Node.js 和瀏覽器環境中，有兩種主流的模塊系統：CommonJS（CJS）和 ECMAScript Module（ESM）。
CommonJS 是 Node.js 原生支持的模塊系統，最初是為了滿足服務器端的模塊化需求。CJS 使用 require 函數來加載模塊，并使用 module.exports 或 exports 對象來暴露代碼。CJS 模塊的特點是同步加載，這意味著模塊加載完成后，代碼會立即執行：
// math.js
function add(x, y) {
return x + y;
}
module.exports = { add };
// app.js
const math = require('./math.js');
console.log(math.add(0, 17)); // 輸出 17在服務器環境中，同步加載通常不是問題，因為大多數文件都是本地的。然而，在瀏覽器環境中，同步加載會導致性能問題，因為它會阻塞瀏覽器的事件循環，直到腳本完全下載和解析完畢。
ESM 是現代 JavaScript 的官方標準模塊系統，并且得到了最新版本瀏覽器的原生支持。與 CommonJS 不同，ESM 被設計為靜態的，這意味著不能在運行時動態加載或創建模塊。ESM 使用 import 和 export 語句進行模塊的導入和導出，支持異步加載：
// math.js
export function add(x, y) {
return x + y;
}
// app.js
import { add } from './math.js';
console.log(add(0, 17)); // 輸出 17ESM 的設計允許瀏覽器優化加載和解析過程，例如通過 HTTP/2 高效并行加載和通過樹搖優化去除未使用的代碼，從而提升性能和效率。然而，在 Node.js 中，ESM 的異步特性與大量現有的 CommonJS 模塊之間存在不兼容的問題。
在 Node.js 中啟用 ESM 目前需要更復雜的方法，因為默認情況下，.js 文件擴展名與 CommonJS 模塊關聯。為了解決這個問題，Node.js 允許使用 .mjs 文件擴展名或在 package.json 中顯式指定 "type": "module" 屬性來指示 ESM 模塊。
雖然 Node.js 支持導入 CommonJS 模塊，但卻無法通過 require 加載 ESM 模塊。這種因 ERR_REQUIRE_ESM 錯誤導致的挫敗感困擾了許多人，并且可能是 Node.js 生態系統內時間浪費的主要原因之一。
如果包作者希望確保 CJS 和 ESM 用戶都能使用他們的包，他們要么必須繼續發布 CJS 模塊，要么發布 CJS 和 ESM 版本的雙模塊（這可能會引發一些問題，但現在已經是一種非常普遍的做法）。
同時，許多轉譯器（例如 TypeScript 編譯器）仍然配置為生成 CJS 代碼作為最終輸出。這些轉譯器的用戶使用 ESM 語法編寫代碼，但他們可能不知道他們的代碼最終由 Node.js 作為 CJS 運行。當他們的代碼使用真正的 ESM 第三方模塊（無法被 require）時，他們會看到 ERR_REQUIRE_ESM。這會非常令人困惑，因為他們可能認為他們的代碼是作為真正的 ESM 運行的。
為什么不能兼容？
自然，人們可能會問：為什么 require() 不支持加載 ESM？
長時間以來，Node.js 項目的回答一直是這樣的：
使用 require 加載 ES 模塊是不支持的，因為 ES 模塊是異步執行的。
但是，這種情況中的文檔和其他形式的溝通可能會誤導人們——或許他們只是在談論 Node.js 中的 ESM 發生了什么，而不是 ESM 本身的設計。去年，當 joyeecheung 在閱讀 V8 代碼以修復內存泄漏問題時，他偶然發現 ESM 本身并沒有被設計為無條件異步的。相反，它是有條件異步的——只有當代碼中有頂級 await 時，它才會是異步的。
所以，支持 require() 加載不包含頂級 await 的 ESM 并沒有什么問題。雖然有些庫可能有正當理由使用頂級 await，但這可能并不常見。
事實上，當 joyeecheung 后來測試了 npm 注冊表上的大約 30 個僅通過 ESM 提供支持的包時，沒有一個包含頂級 await——支持同步模塊的 require() 可能已經解決了生態系統中的許多頭痛問題。
早期探索和嘗試
對 ESM 的支持經歷了長時間的討論、設計和實驗。早在 2019 年，Node.js 社區就開始探索如何支持 ESM 和 CommonJS 之間的互操作性。在此期間，許多開發者提交了 Pull Requests，提出了不同的實現方案和改進措施。
當時，一個里程碑式的 PR 討論集中在如何在 Node.js 中支持 .mjs 擴展名的文件以及如何實現同時支持 CommonJS 和 ESM 的雙模塊系統。
該請求嘗試通過在加載器中循環事件來處理頂級 await，但其方法不安全，這就是它被關閉的原因。
在規范方面，基于語法的 ESM 同步評估的理論基礎在 2019 年已經確立。隨著時間的推移，在 Node.js 中似乎形成了一個關于“ESM 是異步的，CJS 是同步的，因此 CJS 不能加載 ESM”的神話。然而，在標準組織中，ES 規范特別確保 ESM 是有條件異步的。W3C 規范使用它來確保 Service Workers 只允許同步模塊評估。如果在 2019 年之后，規范中的語法同步性被更廣泛地認識到，可能會有更多的嘗試，文檔也不會無條件地討論 ESM 作為異步的。
支持同步 require(esm)
去年底，joyeecheung 發現根據語法，ESM 可以是同步的，只有 Node.js 引入了異步到加載過程中。因此，joyeecheung 和 GeoffreyBooth 開始討論重啟同步 require(esm)。
在 2024 年 2 月底，當 joyeecheung 在為 CJS 和 ESM 加載器做類似緩存的工作并再次深入研究它們時，他注意到似乎有一個更簡單的實現方法——只需放棄“使 ESM 加載器成為 Node.js 中唯一加載器”的想法，并為 CJS 加載器實現一些專用程序以支持同步 require(esm)。使用的現有 ESM 加載器代碼越少，越容易實現。
于是，這個 PR 誕生了。
https://github.com/nodejs/node/pull/51977。
與 2019 年的 PR 的主要區別在于，這次嘗試將 require(esm) 的范圍縮小，僅支持同步加載 ESM。事實證明，在技術指導委員會（TSC）中，這并不是一個有爭議的想法，并沒有引起太多爭議。
目前，該功能仍在通過 --experimental-require-module 標志進行實驗，并且在退出實驗階段之前需要完成一些工作。
目前，require(esm) 僅支持顯式標記為 ESM 的 ESM 模塊——要么通過 .mjs 擴展名，要么通過使用 .js 擴展名的 “type”: “module” 包字段。這足以支持 npm 中的 ESM-only 包。當一個 .js 文件包含 ESM 語法并且其最近的 package.json 中沒有 “type”: “module” 字段時，它可以“回退”到 ESM 加載，但這是用戶應該避免的事情——ESM 語法檢測會帶來開銷，一旦你的項目中有足夠的 ESM 模塊，你可能不希望 Node.js 浪費時間猜測你的模塊類型。特別是，只需在 package.json 中使用顯式的 “type”: “module” 字段，就可以節省這些開銷。
最后
老實說，這個問題困擾了我很長時間。許多 NPM 包開發者也深受其害。我希望 joyeecheung 的這次嘗試能夠盡快投入生產！
