Vite 6 构建体积优化：深入解析 CJS/ESM 混合打包问题

在升级到 Vite 6 后，开发者可能会遇到构建产物体积显著增加的情况。本文将以 prosemirror-utils 依赖为例，深入分析这一现象背后的技术原理，并给出解决方案。

问题现象

当使用 prosemirror-utils 作为依赖时，Vite 6 生成的构建包比 Vite 5 版本大 20% 左右。通过分析构建统计文件可以发现，这是由于 CommonJS (CJS) 和 ES Module (ESM) 两种模块格式的代码同时被打包导致的。

根本原因

这个问题源于 Node.js 生态中的"双包风险"(dual package hazard)。在 Vite 6 中，模块解析缓存机制得到了修复，使得模块解析更加符合规范：

1. prosemirror-transform 包在其 package.json 中正确配置了 exports 字段，为 import 和 require 分别指定了不同的入口文件
2. Vite 5 中存在一个 bug，会混合 require 和 import 的解析缓存，导致错误的模块解析
3. Vite 6 修复了这个 bug，使得模块解析更加准确，但也暴露了双包问题

技术细节

具体来说，构建过程中出现了两条不同的模块解析路径：

1. 直接通过 import 语句引入 prosemirror-transform 的 ESM 版本
2. 通过 prosemirror-utils → prosemirror-state 的 require 链间接引入 prosemirror-transform 的 CJS 版本

在 Vite 5 中，由于缓存混合的问题，第二条路径错误地解析到了 ESM 版本，从而避免了重复打包。Vite 6 的正确行为反而导致了模块重复打包。

解决方案

这个问题的最佳解决方案是在相关依赖包的 exports 字段中添加 module 条件，指向与 import 条件相同的文件。这样构建工具就能在各种导入场景下都使用 ESM 版本，避免重复打包。

对于 prosemirror 生态的包来说，由于它们已经提供了 module 字段，添加 module 条件是一个安全的优化方案。这不仅能解决当前问题，还能进一步优化构建体积，因为其他相关依赖（如 prosemirror-tables、prosemirror-model 等）也能被更好地去重。

总结

Vite 6 的构建体积"回归"实际上是对模块解析行为的正确修复。开发者遇到此类问题时，应该：

1. 检查依赖包是否正确地配置了 exports 字段
2. 考虑升级依赖到最新版本（很多包可能已经修复了相关问题）
3. 对于维护自己包的情况，确保正确配置 module 条件

理解这些底层机制有助于开发者更好地优化构建产物，并在遇到类似问题时快速定位原因。