SWC-Node项目中.js与.d.ts文件导入问题的技术解析

问题背景

在SWC-Node项目的使用过程中，开发者遇到了一个关于模块导入的典型问题：当项目中同时存在.js实现文件和对应的.d.ts类型声明文件时，使用@swc-node/register无法正确导入JavaScript模块。这个问题在TypeScript生态系统中具有一定代表性，值得深入分析。

问题现象

具体表现为：当尝试导入一个.js文件（例如import { test } from "./test.js"），即使目录中存在对应的.d.ts类型声明文件，系统也无法正确解析模块。测试用例显示，简单的JavaScript函数导出无法被正常识别和调用。

技术分析

模块解析机制

TypeScript/JavaScript的模块解析是一个复杂的过程，涉及多个环节：

1. 类型系统解析：TypeScript编译器首先会查找.d.ts类型声明文件
2. 运行时解析：Node.js运行时需要找到实际的.js实现文件
3. 路径解析策略：根据模块系统(CommonJS/ESM)和配置决定查找顺序

SWC-Node的特殊性

SWC-Node作为TypeScript的替代工具链，其模块解析机制需要同时兼容：

• TypeScript的类型系统需求
• JavaScript的运行时要求
• SWC自身的编译管道

在当前的实现中，ts.resolveModuleName方法被用于解析模块，但这个方法倾向于优先返回.d.ts类型声明文件，而不是.js实现文件，导致了运行时错误。

解决方案探讨

短期解决方案

项目维护者建议暂时回退到1.9.0版本，该版本不存在此问题。同时计划在2.0.0大版本中彻底解决模块解析问题。

长期改进方向

技术团队提出了几个潜在的改进方案：

1. 替换解析器：考虑使用专门设计的模块解析器（如oxc-resolver），替代当前的TypeScript原生解析方案
2. 增强解析逻辑：实现自定义解析策略，确保同时满足类型检查和运行时需求
3. 路径处理优化：改进.js和.d.ts文件的路径匹配逻辑

对开发者的建议

遇到类似问题时，开发者可以：

1. 检查项目中是否存在.js和.d.ts文件的命名冲突
2. 尝试显式指定文件扩展名（虽然在此案例中无效）
3. 暂时使用无类型声明文件的纯JavaScript模块作为变通方案
4. 关注项目更新，等待官方修复

总结

这个问题揭示了TypeScript工具链中模块解析机制的复杂性，特别是在使用非官方工具链时可能遇到的兼容性问题。SWC-Node团队已经意识到这个问题，并计划在未来的主要版本中提供更健壮的解决方案。对于开发者而言，理解模块解析的基本原理有助于更快地定位和解决类似问题。