CommonJS vs. ES modules in Node.js

ES 模块的产生是为了统一 JS 模块系统。它已经成为封装 JS 代码以便复用的标准格式。

CommonJS 模块系统，则是内建于 Node.js。在 Node.js 引入 ES 模块以前，CommonJS 是 Node.js 模块的标准格式。因此，有很多 Node.js 库和模块使用 CommonJS 格式书写。

在浏览器支持方面，所有浏览器都支持 ES 模块语法，你可以在 React 和 Vue.js 等框架中使用 import 和 export=。这些框架使用像 Babel 这样的转换编译器，将 =import 和 export 语法编译为 require() 。后者是老版本 Node.js 所支持的。

就算不提 ES 模块是 JS 模块的标准，它的语法也较 require() 更为易读。主要在客户端写 JS 的开发者在使用 Node.js 模块时没有遇到太多问题，这要归功于相同的语法。

一、老版本 Node.js 不支持 ES 模块

尽管 ES 模块已经成为 JS 的标准模块格式，开发者应该考虑到老版本 Node.js 缺乏支持的问题（尤其是 Node.js v9 和之前的版本）。

换句话说，一个用 ES 模块的应用不能在老版本 Node.js 上运行。

但是有了新的条件导出，我们可以构建双模式库。这些库是由 ES 模块组成，但也向后兼容老版本 Node.js 支持的 CommonJS 模块格式。

换句话说，我们可以构建一个库，它支持同时使用 import 和 require() ，这让我们解决了不兼容的问题。

考虑以下库：

  my-node-library
  ├── lib/
  │   ├── browser-lib.js (iife format)
  │   ├── module-a.js  (commonjs format)
  │   ├── module-a.mjs  (es6 module format)
  │   └── private/
  │       ├── module-b.js
  │       └── module-b.mjs
  ├── package.json
  └── …

在 package.json 文件中的 exports 位置，用两种格式导出公共模块（ module-a ），限制对私有模块（ module-b ）的访问。

// package.json
{
  "name": "my-library",
  "exports": {
    ".": {
        "browser": {
          "default": "./lib/browser-module.js"
        }
    },
    "module-a": {
        "import": "./lib/module-a.mjs"
        "require": "./lib/module-a.js"
    }
  }
}

通过提供以下关于 my-library 的信息，我们可以在任何支持它的地方使用它：

// For CommonJS
const moduleA = require('my-library/module-a')

// For ES6 Module
import moduleA from 'my-library/module-a'

// This will not work
const moduleA = require('my-library/lib/module-a')
import moduleA from 'my-awesome-lib/lib/public-module-a'
const moduleB = require('my-library/private/module-b')
import moduleB from 'my-library/private/module-b'

因为 exports 的路径，我们可以导入（和 require() ）我们的公共模块，而不需要指定绝对路径。通过导入 js 和 mjs 后缀的文件，我们可以解决不兼容的问题；我们可以将软件包映射到不同的环境，如浏览器和 Node.js，同时限制访问私有模块。

二、较新版本的 Node.js 完全支持 ES 模块

在大多数低版本 Node.js 中，ES 模块还处于试验阶段。这意味着这一阶段的 ES 模块并不完全，而且在使用时需要添加 --experimental-modules 标记。新版本则改进了这种设置。

然而，在 Node.js 中记住这一点很重要，如果一个模块是 ES 模块，它必须符合这些要求：要么模块文件的扩展名由 .js （用于 CommonJS）改为 .mjs （用于 ES 模块），要么在最近的 package.json 文件中设置 {"type": "module"} 。

这样的话，包中的所有代码都被视为 ES 模块的一部分，应该使用 import/export 语句不要使用 require() 。

在一个 ES 模块中，导入语句只能在文件开始调用。在其他位置调用会自动将表达式转移到文件开头，甚至可能报错。

另一方面， require() 函数在运行时解析。因此， require() 可以在任何地方调用。

运行时解析，是否意味着编写代码时，是不需要关心 require 的包的内容的？

你可以将它用于各种情况下加载模块，比如 if 引导的条件句、条件循环语句、和函数等。

例如，在条件语句中调用 require() ：

if (user.length > 0) {
  const userDetails = require('./userDetails.js')
  // Do something...
}

只有至少一个用户存在时，我们才能调用 userDetails 模块。

使用 require() 加载模块的限制之一就是，它是同步加载模块。这意味着模块被加载以后，是一个一个进行处理的。

正如你猜测的那样，这会为拥有成百模块的大型应用带来性能上的问题。这种情况下， import 基于它的异步表现可能好过 require() 。

然而， require() 的同步天性对于只使用几个模块的小型应用来说可能不算一个很大的问题。