CommonJS 和 ES Module 终于要互相兼容了???
共 4505字,需浏览 10分钟
·
2024-05-24 09:10
在现代 JavaScript
开发中,ECMAScript Module
已经逐渐成为了公认的业界标准。自 ESM
被引入 Node.js
以来,它的异步加载特性和模块解析逻辑广受大家好评。
然而,由于历史原因,很多既有代码和第三方库仍依赖于 CommonJS
模块系统,然而因为 ESM
的异步加载的设计,两个模块化方案一直是无法共存的,这也成了很多开发者的一大痛点。
最近, joyeecheung
提交的一个关键的 Pull Request
(https://github.com/nodejs/node/pull/51977) 来解决这个问题。
在开始介绍前,我们先回顾一下 JavaScript
的两大模块化方案:CJS
和 ESM
。
CJS 和 ESM 的前世今生
在 JavaScript
的世界里,模块化是构建大型应用程序的基础。模块化可以帮助开发者在不影响全局命名空间的前提下管理代码,便于功能分离、代码复用和依赖管理。在 Node.js
和浏览器环境中,有两种主流的模块系统:CommonJS(CJS)
和 ECMAScript Module(ESM)
。
CommonJS
是 Node.js
原生支持的模块系统,起初为了满足服务端模块化的需求而被引入。CJS
使用 require
函数来加载模块,用 module.exports
或 exports
对象将代码暴露为模块。CommonJS
模块的特点是同步加载,这意味着代码会在模块被加载完成后立即执行:
// 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
使用 import
和 export
语句进行模块的导入和导出,支持异步加载:
// math.js
export function add(x, y) {
return x + y;
}
// app.js
import { add } from './math.js';
console.log(add(0, 17)); // 打印出17
ESM
的设计允许浏览器优化加载和解析过程,如通过 HTTP/2
进行有效的并行加载,以及进行 tree shaking
以剔除未使用的代码,从而增强性能和效率。但是,在 Node.js
中,ESM
的异步特性与现有的大量 CommonJS
模块存在不兼容问题。
当前在 Node.js
中启用 ESM
的方法要复杂一些,因为代表性的 .js
文件扩展名默认与 CommonJS
模块关联。为了解决此问题,Node.js
允许使用 .mjs
文件扩展名或在 package.json
中明确指定 "type": "module"
属性来表示 ESM
模块。
由于 ESM
是在 Node.js
中提供支持的,所以我们可以 import cjs
,但不可能 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
注册表中对 Top
影响力的仅提供 ESM
支持的包进行 require(esm)
测试时,测试的约 30 个包中没有一个包含顶级 await
- 并且在 require()
中支持同步模块可能已经足够解决生态系统中的许多头痛问题。
早期的探索与尝试
同步 ESM
的支持其实也经历了长期的讨论、设计和试验。早在 2019
年,Node.js
社区就开始探讨如何支持 ESM
和 CommonJS
之间的互操作性。期间,不少开发人员提交了 Pull Requests
,提出不同的实现方案和改进措施。
在那个时候,一个具有里程碑意义的 PR
讨论集中在如何在 Node.js
中支持 .mjs
后缀的文件,以及如何实现一个双模块系统,可以同时支持 CommonJS
和 ESM
。
这个 pull request
试图通过在加载器中循环事件来处理顶级 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
加载器做一个类似 cache
的事情,开始再次深入研究它们时,他注意到似乎有一种更简单的实现方式 - 只需放弃“使 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
包的功能。它可以实现当 .js
文件出现 ESM
语法且其最近的 package.json
中没有 "type": "module"
字段时,回退到 ESM
加载,但这通常是用户应该避免的 - ESM
语法检测会产生开销,一旦你的项目中有足够的 ESM
模块,你可能不希望 Node.js
浪费时间去猜测你的模块类型。尤其是,当你可以只用一个显式的 "type": "module"
字段在你的 package.json
中就可以节省这些开销。
最后
说实话这个问题也困扰我很久了,相比很多 NPM
包开发者也都深受其害,希望这次 joyeecheung
的尝试可以尽早走向生产吧!
参考:
-
https://github.com/nodejs/node/pull/51977 -
https://joyeecheung.github.io/blog/2024/03/18/require-esm-in-node-js/
点赞
和在看
是最大的支持⬇️❤️⬇️