Nock项目在JSDOM环境下兼容性问题解析

背景介绍

Nock是一个流行的Node.js HTTP模拟库，主要用于测试中拦截和模拟HTTP请求。在最新发布的14.0.0-beta.8版本中，Nock开始使用@mswjs/interceptors作为底层拦截器实现，这带来了一些环境兼容性方面的变化。

问题现象

当开发者尝试在Jest的JSDOM测试环境中使用新版Nock时，会遇到两个主要问题：

1. TextEncoder未定义错误：这是由于JSDOM环境默认不提供TextEncoder全局变量导致的。
2. 无法找到@mswjs/interceptors/presets/node模块：这是由模块解析机制在浏览器环境下无法正确找到Node.js专用预设造成的。

技术分析

环境差异问题

在Node.js环境中，TextEncoder是全局可用的，但在JSDOM模拟的浏览器环境中，这个API需要额外引入。Nock底层依赖的@mswjs/interceptors在bufferUtils.ts中直接使用了全局TextEncoder，导致了第一个错误。

模块解析机制

@mswjs/interceptors使用了Node.js的package.json导出条件：

• 为Node.js环境提供"node"预设
• 为浏览器环境提供"browser"预设

当测试环境被设置为JSDOM时，Jest默认会使用"browser"导出条件，而Nock代码中硬编码引用了"node"预设路径，导致了模块解析失败。

解决方案

1. 自定义测试环境配置

通过Jest的testEnvironmentOptions配置自定义导出条件：

module.exports = {
  testEnvironmentOptions: {
    customExportConditions: ['browser', 'node']
  }
}

这种方法简单但可能掩盖其他模块的兼容性问题。

2. 模块路径映射

使用Jest的moduleNameMapper显式指定预设路径：

module.exports = {
  moduleNameMapper: {
    '@mswjs/interceptors/presets/node': '<rootDir>/node_modules/@mswjs/interceptors/lib/browser/presets/browser.js'
  }
}

这种方法更精确但需要开发者了解底层实现细节。

3. 自定义解析器

实现自定义的Jest解析器来处理特殊模块路径，这种方法最灵活但也最复杂。

技术建议

虽然Nock官方目前主要关注Node.js环境支持，但考虑到测试场景的多样性，开发者可以：

1. 评估是否真的需要在JSDOM环境中使用Nock
2. 考虑使用专门为浏览器设计的HTTP模拟库
3. 如果必须使用Nock，建议采用上述解决方案中的模块路径映射方法

未来展望

随着Nock对@mswjs/interceptors的深度集成，未来版本可能会提供更完善的浏览器环境支持。开发者可以关注项目更新，及时调整测试策略。

通过理解这些技术细节和解决方案，开发者可以更从容地应对测试环境中的HTTP请求模拟需求，确保测试套件的稳定运行。