Bun v1.2.8 版本中 Next.js 项目 TypeScript 模块加载问题分析

在 Bun v1.2.8-canary.11 版本中，Next.js 项目开发者报告了一个关键性的兼容性问题。当项目尝试通过 Module._extensions[".ts"] 直接调用 TypeScript 模块时，系统会抛出"未实现"的错误提示，导致项目无法正常启动。

问题现象

开发者在使用 Next.js 15.2.4 版本的项目中，当执行开发服务器启动命令时，控制台会显示以下错误信息：

TypeError: Calling Module._extensions[".ts"] directly is not implemented.

错误发生在 next.config.compiled.js 文件中，当尝试加载 stickConfigs.ts 模块时触发。值得注意的是，这个问题在降级到 Bun v1.2.5 版本后可以正常解决。

技术背景

在 Node.js 生态系统中，Module._extensions 是一个内部API，用于注册不同文件扩展名的加载器。传统的 Node.js 通过这个机制支持加载 .js、.json 等文件类型。随着 TypeScript 的普及，许多工具链会通过扩展这个机制来支持直接加载 .ts 文件。

Bun 作为一个现代化的 JavaScript 运行时，对模块加载系统进行了重新设计。在 v1.2.8-canary.11 版本中，Bun 团队似乎修改了内部模块加载机制，导致直接访问 Module._extensions[".ts"] 的行为不再被支持。

影响范围

这个问题主要影响以下场景：

1. 使用 Next.js 框架的项目
2. 项目配置中直接或间接依赖 TypeScript 模块加载
3. 使用了某些特定的构建工具链或插件

从报告中的配置来看，问题特别出现在 Next.js 的 next.config.ts 文件尝试加载其他 TypeScript 模块时。

解决方案

目前可行的解决方案包括：

1. 版本回退：暂时降级到 Bun v1.2.5 版本
2. 等待修复：关注 Bun 官方更新，等待此问题被修复
3. 配置调整：尝试修改 Next.js 配置，避免直接加载 TypeScript 模块

对于长期解决方案，建议开发者：

• 避免直接依赖 Node.js 内部 API 如 Module._extensions
• 考虑使用更标准的模块加载方式
• 关注 Bun 官方文档关于模块系统的更新

技术启示

这个案例反映了 JavaScript 工具链发展中的一个常见挑战：当新的运行时尝试优化或重新设计传统机制时，可能会与现有生态系统的某些实现细节产生兼容性问题。作为开发者，我们需要：

1. 理解工具链底层原理
2. 保持对依赖更新的关注
3. 建立完善的测试机制
4. 准备回退方案

Bun 团队对此问题的快速响应也展示了现代 JavaScript 工具生态的活跃性，预计在正式版本中会提供更完善的解决方案。