• 你是在用CommonJS还是ES模块来组织JavaScript 代码?
  • 发布于 2个月前
  • 201 热度
    0 评论
所周知,JavaScript社区喜欢进行热烈的辩论。四年来,我们如何组织代码的问题上一直存在一个分歧——这是一个基本但令人意外地有争议的问题,继续将开发者分开。这种分歧围绕着 CommonJS 和 ES 模块,这是两个用于划分 JavaScript代码的主要系统。

理解这个分歧
当JavaScript最初被发明时,它的主要角色是作为Web浏览器的脚本语言。但是,随着Node.js的出现,似乎展现出了一系列的可能性。现在,它不仅仅是一个浏览器的语言。它可以为服务器和其他应用程序提供动力。在那种情境下,浏览器中的所有东西都在全局作用域中,你不必过多地考虑模块。但是构建一个复杂的服务器应用程序并不那么简单。你不能把所有的代码都打包在一个文件中——那将是一个噩梦。

出现的解决方案?一个叫做CommonJS的模块系统。
const moduleA = require('./moduleA');
CommonJS 使用一个叫做 require 的函数,允许你从其他文件中提取 JavaScript并访问从它们导出的函数。然而,JavaScript 很快用ES6——适应了这些想法,以满足Web应用程序的需求。他们引入了import和export。
import moduleA from './moduleA';
现在,你可能会纳闷,为什么JavaScript没有坚持已经在使用的require调用呢?require 的问题在于它是同步的,并假设所有文件都已经准备好。但是,在浏览器上下文中,你可能需要等待外部资源时,require的同步性质会让系统崩溃。

因此,分裂开始了。

兼容性难题
大多数开发者转向ES模块,因为它们不仅是新颖的,而且很有趣。但一个相当大的群体仍然坚持使用CommonJS。这种分裂导致了兼容性问题。如果你在ES模块内部运行,你可以没有问题地导入CommonJS。但是,使用CommonJS导入ES模块是不行的——除非你采用一个模拟导入的异步函数解决方法。
const moduleA = await import('./moduleA');

打包器的作用
像Babel或TypeScript这样的打包器或转译器为这个复杂问题增加了另一层,你写的内容取决于你发出的内容。你可以用ES模块写,但发出 CommonJS。
// Babel或TypeScript编译器将ES模块转换为CommonJS
const moduleA = require('./moduleA');
如果你在构建的代码中看到 require调用,你就是在发出 CommonJS,而import和export的存在表示你是ES模块的未来的一部分。

未来属于ES模块
在吸引了开发者注意的新工具中,bun 是亮点。bun 的主要亮点在于,它已经解决了CommonJS 和 ES 模块之间的互操作性问题。但是,这个修复并不完全符合规范——他们只是为了让它工作而修补了CommonJS和ES模块之间的问题。

由于支持这些不同的模块系统,JavaScript工具链可能非常复杂。采用ES模块,你正在简化Web开发。所有的Node.js长期支持版本现在都使用ES模块,这标志着一个明确的海变。尽可能使用ES模块。现在是时候结束这种分裂,拥抱未来了。现代JavaScript,统一的JavaScript。

如果你一直在使用或考虑使用 CommonJS,可能是时候仔细看看你的代码了。未来是一个有ES模块的地方,我们每个人都有责任使 JavaScript 的景观变得更加简单和有趣。
用户评论