标签： es module

node.js 里 ESM 与 CommonJS 的区别
可能大部分同学并不会直接用 node.js 开发 Web 后端程序，但是作为现代化前端，我们日常的各种开发都严重依赖开发脚手架，也即 node.js 环境下的各种工具链。目前已经有一些仓库逐步迁移到 ESM，所以了解一下 node.js 里 ESM 和 CommonJS 的区别也很有必要。

我还是老习惯，后文列举出的差异并非文档记录，而是我在实操中遇到的大坑小坑，希望记下来能节省将来的时间和大家的时间。

0. 设计原则

我们可以把 CommonJS 理解成按需加载，需要什么就加载什么，加载进来就执行。所以可以动态加载、条件加载、循环加载。

ESM 倾向于静态加载，方便解析依赖，优化运行效率。所以起初不能条件加载或者循环加载。不过后面考虑到实际需求，还是开放了 import() 做动态加载。

这个设计原则可以导出后面的诸多不同。

1. package.json

在 package.json 里添加 type: 'module' 可以开启本项目的 ESM。不写或者 type: 'commonjs' 则继续使用 CommonJS。

如果没有此配置，虽然我们代码中写的 好像是 ESM，但其实都会被 Babel 或其它什么工具转译成 CommonJS，最终运行的并不是 ESM。这点一定要注意。

2. __dirname

ESM 不再支持用 __dirname、__filename 获取正在执行的 JS 文件在系统中的路径。作为替代方案，可以使用 import.meta.url 获取当前文件的 URL，不过返回结果是 file:// 协议，如果要继续使用 __dirname 可以这样：
```
import {dirname} from 'path';
import { fileURLToPath } from 'url';

function getDirname(url) {
  const __filename = fileURLToPath(url);
  return dirname(__filename);
}
```
3. 解构

使用 CommonJS 时，我们可以直接对导出的对象进行解构，比如：
```
// lib.js
module.exports = {
  foo: 'bar',
};

// index.js
const {foo} = require('./lib');
```
这样的用法在 ESM 中不可行。ESM 解构只能针对使用 export foo = 'bar' 这样主动暴露出的属性。对于一般对象的解构，我们只能写成：
```
// lib.js
export default {
  foo: 'bar',
}

// index.js
import lib from './lib';

const {foo} = lib;
```
4. .mjs 文件与 .cjs 文件

我们知道，node.js 加载模块时可以省去文件扩展名，比如 require('./foo')，不需要写最后的 .js 或 .json，node.js 会自动去目录里查找对应的文件。

node.js 会根据 type 的不同使用不同默认策略加载 js，我们也可以使用特定扩展名要求 node.js 在加载时使用特定模块类型。比如，我们使用 ESM 时，node.js 会把加载进来的 JS 都当 ESM 处理，如果这些 JS 还在使用 CommonJS 加载其它 JS，就会报错（前面说了，ESM 里不支持 require）。此时，我们可以把目标文件的扩展名写为 .cjs，node.js 就会当它是 CommonJS 来处理了。

此功能在使用第三方库的时候很有用。比如 Postcss，它会加载项目里的配置文件，但它只支持 CommonJS，这时，如果执行时因没有 require 报错，就可以把配置文件的扩展名改成 .cjs。

5. 顶层 await

开启 ESM 之后，可以使用顶层 await，省去一个异步函数。

（这是促使我使用 ESM 的主要原因）

6. import 与 require

ESM 中，我们可以使用 import 导入 CommonJS 模块和 ESM 模块；但是 CommonJS 的 require 只能用来导入 CommonJS 模块。如果要在 CommonJS 中导入 ESM 模块，需要使用 import() 然后异步处理。

自然，ESM 里不能用 require。

7. 其它区别

这些区别我在实际开发中没有遇到，大家自己阅读吧：Modules: ECMAScript modules | Node.js v17.8.0 Documentation (nodejs.org)
（更多…）
2022年3月27日
在任意上下文执行代码，`new Function` vs `eval()`
0. 需求及方向

我厂的 Navigator 扩展遇到一个需求：
1. 动态生成一段 JS 在浏览器里运行
2. 能重复生成、重复运行
3. 能生成一段新代码，继续在上一次的环境里运行
其中（3）是新需求，（1）（2）已经比较完善地实现了。主要方案是使用 <script type="module">，这样加载的 JS 会自动执行，并且与全局环境相隔离，不会污染全局环境——这样就可以重复执行。

（3）的难点在于，上一段 JS 已经执行过了，环境也自然释放了，我要么把上一阶段 JS 的执行结果保存下来，要么把执行环境保存下来。前者需要对 Navlang 编译器做大幅度的修改；后者则有很大的实施难度。

经过研究和思考，我选择 保存环境 为攻关方向。即在上次执行结束前，在 window 上注册一个钩子函数，然后在后续追加执行的时候调用它，把后面的代码以函数的形式传进去，以便在上一次留下的环境里继续执行。

1. 问题：访问环境里的变量

添加钩子函数并不难，这样就行：
```
// 在上一段代码最后添加钩子函数
window.doNext = function (func) {
  func();
}

// 在新一段代码执行函数
window.doNext(function () {
  // 新生成的函数
});
```
这样做虽然看起来是在上一次的上下文环境中执行新的函数，但由于 JS 的闭包和作用域链特性，实际执行时，新函数并不能访问到上一次上下文的数据。换言之，目的并没有实现。

2. new Function() vs eval()

然后回到标题。所以我们必须在上一次的环境里重新构建函数，这并不困难，其实开发浏览器扩展时，因为要协调四、五个运行环境，所以把函数序列化传输，再重新构建执行非常常见。于是我直接操起 new Function()，然后失败了。

查阅 MDN，原来 new Function() 构造的函数，它的上下文会绑定在全局对象上（相当于 .call(null)），所以自然无法访问到上一次环境里的变量。

再看 eval() 的文档，似乎可行，于是换用之，果然有效。至此，问题解决。

3. 代码范例
```
function navlangExecuteFunction(func) {
  // 使用模版字符串构建异步函数
  eval(`(async function doNext() {
    // 捕获中间可能出现的问题
    try {
      // 执行真正的函数
      await (${func})();
      // 为兼容 node.js，mock 一个 process 来处理执行结束
      process.exit();
    } catch (e) {
       if (!e.message.startsWith('Exit code:')) {
         console.error(e);
         process.exit(1);
       }
    }
  })()`);
}
window.navlangExecuteFunction = navlangExecuteFunction;
```
```
const serializeFunction = (f) => {
  const serialized = f.toString();
  // Safari serializes async arrow functions with an invalid function keyword.
  // This needs to be removed in order for the function to be interpretable.
  const safariPrefix = 'async function ';
  if (serialized.startsWith(safariPrefix)) {
    const arrowIndex = serialized.indexOf('=>');
    const bracketIndex = serialized.indexOf('{');
    if (arrowIndex > -1 && (bracketIndex === -1 || arrowIndex < bracketIndex)) {
      return async ${serialized.slice(safariPrefix.length)};
    }
  }
  return serialized;
};

let nextStep = async function () {
  // 要执行的部分
}
nextStep = serializeFunction(nextStep);
navlangExecuteFunction(nextStep);
```
4. 可能带来的问题

MDN 明确建议大家 不要用 eval。理由如下：
1. 不安全。因为 eval() 会在当前环境执行代码，意味着攻击者可能窃取任何当前环境的数据。
2. 性能差。现代 JS 引擎会对代码进行大量优化，包括转成机器码等。eval() 会破坏这个过程，使得运行性能大大降低。
不过在我的场景下，这两个问题并不严重。一方面，被执行的追加代码都是由 Navlang 编译器生成，而不是任意第三方，它的安全性不会比其它的代码安全性低。另一方面，这个功能是帮助用户开发调试 Navlang 的，我们可以认为它大概率不会跑在性能敏感的环境里。

另外，对我厂的 Navigator 产品而言，这样的方案还会让 GC 变得比较难执行。不过一样从 便利开发 的角度出发，我觉得性价比完全 OK。

5. 总结

这个需求比较特殊，涉及到 JS 函数的很多性质，包括运行时优化的知识，还是蛮值得大家琢磨的。

另外就是所谓“尽信书不如无书”。eval() 的确存在一些问题，不能轻易使用，但是当需求摆在面前，经过充分的分析确认之后，我们该用还是要用。
2021年1月18日