RFC: 全新 Transform 和 Bundle 编译流程

[XGHeaven]

现状

现在的编译流程是以 Bundle 模式下的 Rollup 插件为准，也就是说即使是在 Transform 模式下，会创建一个 pluginContainer，来模拟 Rollup 插件的运行流程，然后触发其中的 transform 方法。

这样的好处很清晰，就是可以复用 Rollup 插件。

而缺点是复杂度比较高，仅仅为了复用插件中 transform 这一个方法，就需要较为完整的模拟 Rollup 插件的流程，且需要跟随 Rollup 插件规范进行更新。如果后续切换 bundler，则也需要对这部分进行重构和优化。

重构

可以看到上面的核心问题不希望模拟 Rollup 这个插件的流程，且我们希望编译代码的这部分的结果和能力是统一的，自然而然有两种新的编译流程，分别是：

• 换成以 Transform 为核心，Bundle 的构建复用 Transform 的结果和能力。
• 依旧以 Bundle 为核心，利用 preserveModules 的特性实现 Transform，而非模拟插件过程

以 Transform 为核心

• 暴露 compile 方法，允许开发者自定义代码的编译能力
• compile 默认作用于 Transform，并通过 Rollup 插件的形式接入 Bundle 的流程中，后续 Bundle 流程的所有代码构建逻辑都将服用 Transform。保证两者是一致的。
• 且开发者拥有了 Transform 模式下，自定义编译各类文件的能力，例如 less、png 等等。

具体的方法名字待定

优势：

• 对开发者来说比较容易理解，类似于 ICE 的 transform 配置方法。
• 利于并行化，transform 本身这个操作是原子类型的操作，可以并行编译和处理。通过插件接入 Rollup 之后也能获得一定的优势
• 不和 bundler 强绑定，可以自由替换 Bundle 下的 bundler。例如替换为 Webpack、Rspack 等

缺点：

• 会引入 Break Change，按照原先设置 Rollup 插件的方式将无法在这个流程上生效
• 虽然不和 Rollup 插件耦合，但是依旧需要设计一套编译构建的插件体系，本质上模拟了部分 Rollup 插件的能力，这部分会存在一定的复杂度。（比如能够让开发者自由的配置那些文件需要编译，那些文件只需要拷贝，以及编译的内容等等。

以 Bundle 为核心

利用 Rollup 提供的 preserveModules 的方法实现 Transform 任务，整体上的优劣和之前保持一致，与上面的相反。
且因为和 bundler 强绑定，如果后续更换的 bundler 如果没有这个能力，那么就无法更换。

结尾

需要确定哪种方式，个人更加推荐以 Transform 为核心的编译流程。
本身 PKG 是作为库开发工具，以 Transform 为核心这种方式会更加符合开发者的心智模型。

相关内容

• 不完整的rollup plugin hooks #519