Jest 运行时报错 "Export 'emit' is not defined in module" 问题解析

问题背景

在 Jest 测试框架中，当运行包含特定测试用例的组合时，可能会遇到一个奇怪的错误："ReferenceError: Export 'emit' is not defined in module"。这个错误源于 Jest 内部对 Node.js 核心模块 process 的特殊处理方式，以及测试环境中对全局对象的意外修改。

问题现象

测试运行时会出现两种错误信息：

1. 主要错误：ReferenceError: Export 'emit' is not defined in module
2. 伴随错误：ReferenceError: You are trying to import a file after the Jest environment has been torn down

这些错误并非每次都会出现，而是在特定测试组合和特定时机下才会触发，表现出明显的竞态条件特征。

根本原因分析

Node.js process 模块的特殊性

Node.js 的 process 对象是一个特殊的全局对象，它继承自 EventEmitter 类。这意味着：

• process.emit 方法是通过原型链继承得到的
• Object.keys(process) 和 Object.entries(process) 不会包含继承的方法
• 但 process.emit 方法确实存在并可调用

Jest 的模块包装机制

Jest 在运行测试时会对模块进行特殊包装，使用 Node.js 的 vm.SyntheticModule 来模拟模块系统。对于核心模块如 process，Jest 会：

1. 首先通过 Object.keys() 获取模块的所有自有属性作为导出名称
2. 然后通过 Object.entries() 获取这些属性的值
3. 使用这些信息创建一个合成模块

竞态条件的产生

问题发生在以下情况下：

1. 某个测试或依赖库（如 source-map-support 或 pem）修改了 process 对象
2. 这种修改恰好在 Jest 包装 process 模块的过程中发生
3. 具体来说，是在 Object.keys() 调用之后，但在 Object.entries() 调用之前
4. 如果修改添加了新的自有属性（如直接给 process.emit 赋值），就会导致前后不一致

解决方案与变通方法

临时解决方案

在 Jest 配置的 setupFilesAfterEnv 中添加以下代码可以缓解问题：

process.emit = process.emit;

这行代码看似无意义，但它确保了 emit 成为 process 对象的自有属性，避免了后续修改导致的竞态条件。

根本解决方案

Jest 可以改进其核心模块包装逻辑：

1. 将 Object.keys() 和 Object.entries() 的调用同步进行
2. 使用相同的快照数据来构建合成模块
3. 避免在模块包装过程中依赖可能被修改的全局状态

改进后的代码逻辑应该是：

const allExports = Object.entries(required);
const exportNames = allExports.map(([name]) => name);

const module = new SyntheticModule(
  ['default', ...exportNames],
  function() {
    this.setExport('default', required);
    for (const [key, value] of allExports) {
      this.setExport(key, value);
    }
  },
  {context, identifier: moduleName}
);

最佳实践建议

1. 避免在库中修改全局对象：库代码不应该擅自修改像 process 这样的核心全局对象，特别是添加或覆盖方法。

2. 谨慎使用 source-map-support：这类工具应该由应用程序顶层或测试框架统一管理，而不是由各个库自行引入。

3. 注意测试隔离性：如果测试必须修改全局状态，应该确保在测试前后进行适当的清理和恢复。

4. 升级过时的依赖：像 pem 这样会擅自修改全局对象的库，应该考虑寻找替代方案或推动其维护者修复问题。

总结

这个 Jest 问题揭示了 JavaScript 测试环境中一些微妙的竞态条件和全局状态管理挑战。通过理解 Node.js 核心模块的特殊性、Jest 的模块系统实现原理，以及第三方库对全局状态的影响，开发者可以更好地诊断和解决类似问题。同时，这也提醒我们在编写库代码时要更加谨慎，避免对全局状态造成不可预测的影响。