Webpack 配置中 TypeScript 支持与 Node.js v24 的兼容性问题解析

问题背景

在 Webpack 生态系统中，开发者经常使用 TypeScript 来编写 webpack 配置文件（webpack.config.ts）。这一直以来都能正常工作，直到 Node.js v24 的发布带来了原生 TypeScript 支持，这导致了一些兼容性问题。

技术原理分析

在 Node.js v24 之前，当 Webpack 遇到 .ts 配置文件时，会通过 rechoir 和 interpret 这两个库来检测并加载 TypeScript 编译器（通常是 ts-node）。这些库的实现依赖于 Node.js 的 require.extensions API，这是一个已被废弃但仍然可用的功能。

Node.js v24 引入了原生 TypeScript 支持，其实现方式是在内部填充了 require.extensions['.ts']。这导致 rechoir 错误地认为 TypeScript 编译器已经加载，而实际上 Node.js 只是进行了简单的类型剥离（type stripping），并非完整的 TypeScript 编译。

问题表现

当使用 Node.js v24 运行 webpack.config.ts 时，会出现以下问题：

1. 配置文件中的 __dirname 等 Node.js 特定变量无法使用
2. TypeScript 的高级特性如 enum、namespace 等不被支持
3. tsconfig.json 配置被忽略
4. 代码实际上只进行了类型剥离，而非完整的 TypeScript 编译

解决方案演进

Node.js 团队在 v24.3.0 中修复了这个问题，他们移除了原生 TypeScript 支持对 require.extensions 的修改，改为通过 process.features.typescript 来检测 TypeScript 支持。这一变更也被反向移植到了 Node.js v22 中。

对于 Webpack 生态系统的长期解决方案，核心维护者建议：

1. 逐步淘汰 rechoir 和 interpret 的使用
2. 明确要求用户通过 NODE_OPTIONS 环境变量显式指定 TypeScript 编译器
3. 更新文档，明确说明配置 TypeScript 环境的正确方式

最佳实践建议

对于需要使用 TypeScript 编写 Webpack 配置的开发者，建议采用以下方式：

1. 升级到 Node.js v24.3.0 或更高版本
2. 或者显式指定 TypeScript 编译器：NODE_OPTIONS='--require ts-node/register' webpack --config webpack.config.ts
3. 避免在 ES 模块作用域中使用 __dirname 等 CommonJS 特性
4. 关注 Webpack 文档关于 TypeScript 配置的最新指南

技术演进启示

这个案例展示了当底层运行时环境引入新特性时，上层工具链可能面临的兼容性挑战。它也提醒我们：

1. 依赖已废弃的 API 存在风险
2. 显式配置优于隐式魔法
3. 生态系统需要时间适应运行时环境的重大变更

随着 Node.js 原生 TypeScript 支持的成熟，Webpack 生态系统也将逐步调整以适应这一变化，最终为用户带来更流畅的开发体验。