Babel项目中JSX运行时导入顺序问题解析

问题背景

在Babel项目中，当使用@babel/preset-react并配置runtime: "automatic"时，Babel会自动为JSX语法添加对react/jsx-runtime的导入。这一机制在大多数情况下工作良好，但在特定场景下会出现问题。

问题现象

开发者报告了一个具体案例：当代码中同时存在普通导入和Jest的mock函数时，如果mock函数内部使用了JSX语法，就会抛出TypeError: Cannot read properties of undefined (reading 'jsx')错误。这是因为Babel默认将react/jsx-runtime的导入语句放置在文件所有现有导入之后，而Jest的mock函数会在所有导入完成前执行回调函数。

技术原理

Babel的JSX转换机制

Babel在处理JSX时有两种模式：

1. 经典模式：将JSX转换为React.createElement调用
2. 自动模式（runtime: "automatic"）：使用react/jsx-runtime提供的专用函数

在自动模式下，Babel会为每个使用JSX的文件自动添加对react/jsx-runtime的导入。默认情况下，这些导入会被放置在文件所有现有导入语句之后。

Jest的模块模拟机制

Jest的mock函数有一个特殊行为：它会提升模块模拟操作，在模块实际导入前执行模拟设置。这意味着mock回调函数中的代码会在模块导入完成前执行。

问题根源

当以下三个条件同时满足时就会出现问题：

1. 使用Babel的自动JSX运行时模式
2. 代码中包含jest.mock调用
3. mock回调函数中直接使用JSX语法

这是因为：

1. Babel将运行时导入放在文件末尾
2. Jest在模块导入完成前执行mock回调
3. 回调执行时JSX运行时尚未导入

解决方案

临时解决方案

1. 修改mock写法，避免直接使用JSX：

jest.mock('./component', () => ({ default: <>fake</>}))

2. 在测试配置中预先导入JSX运行时

根本解决方案

Babel团队认为这是Jest的行为不符合ECMAScript模块规范导致的，建议向Jest项目报告此问题。从技术规范角度，模块应该按导入顺序执行，而Jest的mock提升行为打破了这一约定。

最佳实践建议

1. 在测试代码中，避免在mock回调中直接使用JSX
2. 考虑将模拟组件提取为单独模块
3. 对于复杂测试场景，使用jest.mock的模块工厂函数形式

总结

这个问题揭示了工具链中不同工具行为差异导致的边界情况。虽然可以通过调整Babel配置临时解决，但从长远来看，测试工具应该遵循标准的模块执行顺序。开发者在使用JSX自动运行时与测试工具配合时，需要注意这种特殊场景。