ts-jest模块解析中customConditions未重置问题分析

问题背景

在TypeScript与Jest结合的测试环境中，ts-jest作为桥梁工具负责将TypeScript代码转换为Jest可执行的JavaScript代码。在实际使用中，当开发者配置了特定模块解析选项时，可能会遇到一个与customConditions相关的编译错误。

问题现象

当项目配置同时包含以下TypeScript编译选项时：

• "module": "preserve"
• "moduleResolution": "bundler"
• "customConditions": ["node"]

ts-jest在转换过程中会抛出错误提示："Option 'customConditions' can only be used when 'moduleResolution' is set to 'node16', 'nodenext', or 'bundler'."。这表明虽然原始配置是正确的，但在ts-jest内部处理过程中出现了问题。

根本原因

深入分析ts-jest源码发现，在fixupCompilerOptionsForModuleKind方法中，当处理非ES模块时，会将moduleResolution强制设置为Node.js模式（ModuleResolutionKind.Node10或ModuleResolutionKind.NodeJs）。然而，该方法没有同时清除不再适用的customConditions选项，导致TypeScript编译器在验证选项时抛出错误。

技术细节

customConditions是TypeScript较新版本引入的配置项，专门用于Node.js的Conditional Exports功能。它仅在特定的模块解析模式下有效：

• node16
• nodenext
• bundler

当ts-jest将模块解析模式改为传统的Node.js模式时，理论上应该同步移除这个不再适用的选项，但当前实现中遗漏了这一逻辑。

解决方案

修复方案相对简单直接：在修改moduleResolution的同时，将customConditions显式设置为undefined。这可以通过修改fixupCompilerOptionsForModuleKind方法的实现来完成，无论是对于CommonJS模块还是ES模块的情况。

影响范围

该问题主要影响以下使用场景：

1. 项目中使用较新TypeScript版本（支持customConditions）
2. 配置了customConditions选项
3. 使用moduleResolution为bundler模式
4. 通过ts-jest进行测试代码转换

最佳实践建议

对于需要在测试环境中使用条件导出的项目，建议：

1. 明确区分开发/构建配置与测试配置
2. 考虑在jest配置中覆盖特定的TypeScript选项
3. 关注ts-jest版本更新，及时获取相关修复

总结

这个问题展示了构建工具链中配置传递的重要性，特别是在多阶段处理过程中，需要确保各阶段的配置一致性。ts-jest作为连接TypeScript和Jest的桥梁，需要特别注意选项的兼容性和正确性处理。