噢，CommonJS！你为什么跟我聊天？！放弃 CommonJS 的原因-js教程-PHP中文网

这是正常的补丁日。我在没有更改代码的情况下修补并升级了我的 npm 依赖项，突然间，我的一些单元测试失败了。
Oh CommonJS! Why are you mESMing with me?! Reasons to ditch CommonJS

卧槽！

Oh CommonJS! Why are you mESMing with me?! Reasons to ditch CommonJS

我的测试失败了，因为 Jest 遇到了意外的令牌；他们失败了，因为 Jest 无法处理开箱即用的仅 ESM 包。事实上，Jest 是用 CommonJS 编写的。
但这意味着什么？为此，我们需要了解 CommonJS 和 ESM 存在的原因。

为什么我们需要模块系统？

在 Web 开发的早期，JavaScript 主要用于通过 jQuery 等库来操作文档对象模型 (DOM)。然而，Node.js 的引入也导致 JavaScript 被用于服务器端编程。这种转变增加了 JavaScript 代码库的复杂性和大小。因此，需要一种结构化方法来组织和管理 JavaScript 代码。模块系统的引入就是为了满足这种需求，使开发人员能够将代码划分为可管理、可重用的单元¹.

CommonJS 的出现

CommonJS 成立于 2009 年，最初名为 ServerJS²。它是为服务器端 JavaScript 设计的，提供了定义模块的约定。 Node.js 采用 CommonJS 作为其默认模块系统，使其在后端 JavaScript 开发人员中流行。 CommonJS 使用 require 导入，使用 module.exports 导出模块。 CommonJS 中的所有操作都是同步的，这意味着每个模块都是单独加载的。

ESM（ECMAScript 模块）的兴起

2015 年，ECMAScript 引入了一个名为 ECMAScript Modules (ESM) 的新模块系统，主要针对客户端开发。 ESM使用导入和导出语句，其操作是异步的，允许并行加载模块³。最初，ESM 是为浏览器设计的，而 CommonJS 是为服务器设计的。它越来越成为 JS 生态系统的标准。如今，现代 JavaScript 运行时支持这两种模块系统。浏览器从 2017 年开始原生支持 ESM。甚至 Typescript 也适配了 ESM 语法，每当你学习它时，你也在潜意识中学习 ESM。

How Are you not dead.jpg

CommonJS 将会继续存在

事实是，仅 CommonJS (CJS) 的软件包比仅 ESM 的软件包多得多⁴.
Oh CommonJS! Why are you mESMing with me?! Reasons to ditch CommonJS
然而，有一个明显的趋势。仅 ESM 或双模块软件包的数量正在增加，而仅 CJS 软件包的数量正在减少。这一趋势凸显了人们对 ESM 日益增长的偏好，并提出了有多少纯 CJS 软件包得到积极维护的问题。

比较

CommonJS 和 ESM 之间的一个有趣的比较涉及性能基准。由于其同步特性，CommonJS 在直接使用 require 和 import 语句时速度更快。让我们考虑以下示例：

// CommonJS -> s3-get-files.cjs
const s3 = require('@aws-sdk/client-s3');
new s3.S3Client({ region: 'eu-central-1' });

// ESM -> s3-get-files.mjs
import { S3Client } from '@aws-sdk/client-s3';

new S3Client({ region: 'eu-central-1' });

登录后复制

我使用了aws-sdk S3-Client，因为它具有双模块支持。这里我们实例化客户端，然后用node执行：

hyperfine --warmup 10 --style color 'node s3-get-files.cjs' 'node s3-get-files.mjs'

Benchmark 1: node s3-get-files.cjs
Time (mean ± σ): 82.6 ms ± 3.7 ms [User: 78.5 ms, System: 16.7 ms]
Range (min … max): 78.0 ms … 93.6 ms 37 runs
Benchmark 2: node s3-get-files.mjs
Time (mean ± σ): 93.9 ms ± 4.0 ms [User: 98.3 ms, System: 18.1 ms]
Range (min … max): 88.1 ms … 104.8 ms 32 runs

Summary
node s3-get-files.cjs ran
  1.14 ± 0.07 times faster than node s3-get-files.mjs

登录后复制

如您所见，s3-get-files.cjs 以及 CommonJS 运行得更快。
我受到 Buns 博客文章的启发。

但是，当你想要生产你的 JS 库时，你需要捆绑它。否则，您将运送所有的node_modules。使用 esbuild 因为它能够捆绑到 CJS 和 ESM。现在，让我们使用捆绑版本运行相同的基准测试。

hyperfine --warmup 10 --style color 'node s3-bundle.cjs' 'node s3-bundle.mjs'

Benchmark 1: node s3-bundle.cjs
Time (mean ± σ): 62.1 ms ± 2.5 ms [User: 53.8 ms, System: 6.7 ms]
Range (min … max): 59.5 ms … 74.5 ms 45 runs

Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: node s3-bundle.mjs
Time (mean ± σ): 45.3 ms ± 2.2 ms [User: 38.1 ms, System: 5.6 ms]
Range (min … max): 43.0 ms … 59.2 ms 62 runs

Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary

  node s3-bundle.mjs ran
    1.37 ± 0.09 times faster than node s3-bundle.cjs

登录后复制

如您所见，s3-bundle.mjs 现在比 s3-bundle.cjs 更快。 ESM 文件现在甚至比未捆绑的 CommonJS 文件更快，因为由于有效的树摇动（删除未使用的代码的过程），它会导致更小的文件大小和更快的加载时间。

拥抱 ESM！

JavaScript 模块的未来无疑倾向于 ESM。这在创建新的 NodeJS 项目甚至 React 项目时开始。每个教程和文章都使用 import 语句，这就是 ESM。尽管已有许多 CommonJS 包，但随着越来越多的开发人员和维护人员因其性能优势和现代语法而采用 ESM，这种趋势正在发生变化。另一个问题是还有多少这些仅 CJS 的项目仍在维护。

ESM 是一个可以在任何运行时（例如 NodeJS、Bun 或 Deno）以及浏览器中运行的标准，无需在服务器上运行。没有必要通过 Babel 转换为 CommonJS，因为浏览器可以理解 ESM。您仍然可以使用 Babel 转换为不同的 ECMAScript 版本，但不应转换为 CJS。

您应该仅使用 ESM 进行开发，因为现在的每个运行时和 2017 年更新的浏览器都可以理解 ESM。

如果您的代码损坏，您可能会遇到遗留问题。考虑使用不同的工具或包。例如，您可以从 Jest 迁移到 vitest，或者从 ExpressJS 迁移到 h3。语法保持不变；唯一的区别是 import 语句。

关键要点：