Jiti项目中的模块加载回归问题分析与修复

问题背景

Jiti是一个Node.js模块加载器，它能够动态地加载和转译TypeScript、ES模块和CommonJS模块。在从Jiti v1升级到v2的过程中，开发者发现了一个模块加载的回归问题。

问题现象

当在JavaScript文件中使用require('./extensionless-ts')语法加载一个没有扩展名的TypeScript文件时，Jiti v1可以正常工作，但在Jiti v2中会抛出"找不到模块"的错误。

技术分析

模块加载机制

Jiti的模块加载过程分为几个关键步骤：

1. 模块类型判断：Jiti首先会判断目标文件是ES模块还是CommonJS模块
2. 原生加载尝试：对于符合CommonJS规范的文件，Jiti会先尝试使用Node.js原生require加载
3. 回退机制：如果原生加载失败，会回退到使用Jiti的转译加载器

问题根源

在Jiti v2中，虽然保留了与v1相同的回退机制，但在异步上下文中该机制未能正常工作。具体表现为：

1. 当index.js被识别为CommonJS模块时，Jiti会尝试原生require
2. 原生require失败后，v2的回退机制在异步环境下失效
3. 导致最终抛出"找不到模块"的错误

解决方案

Jiti团队在v2.3.2版本中修复了这个问题，主要改进包括：

1. 修复了异步上下文中的回退机制
2. 确保在原生加载失败后能正确回退到转译加载

后续发现的问题

修复后测试发现：

1. 当package.json中指定了"type": "module"时
2. 虽然不再抛出错误，但jiti.import的返回值变成了undefined
3. 这个问题在CommonJS环境下同样存在

技术建议

对于开发者遇到类似问题，建议：

1. 明确模块系统类型（ESM/CJS）
2. 检查Jiti配置选项，特别是esmResolve和interopDefault
3. 考虑显式添加文件扩展名以避免解析歧义
4. 在混合模块系统中特别注意默认导出的处理

总结

模块加载器在Node.js生态中扮演着重要角色，Jiti的这种边界情况处理展示了模块解析的复杂性。开发者在使用时应当注意模块系统的明确性，并在升级时充分测试边界情况。