Mako 项目配置层重构：统一 API 与配置文件的设计思考

在构建工具领域，配置管理一直是影响开发者体验的关键因素。最近，UMI 团队旗下的 Mako 项目针对其配置系统进行了一次重要重构，将原本分散在 API 参数和配置文件中的配置项进行了统一整合。这一变化虽然带来了 breaking change，但显著提升了配置的一致性和可维护性。

重构背景

在重构前的版本中，Mako 的构建 API 存在配置分散的问题。开发者调用 build 方法时，需要同时处理两类配置：

const { build } = require('@umijs/mako');
await build({
  root: process.cwd(),
  watch: false,
  config: {}, // 第一类配置
  plugins: [], // 第二类配置
  less: {},
  forkTsChecker: true,
});

这种设计将配置人为地分成了两部分：一部分放在 config 对象中，另一部分则作为 build 方法的直接参数。这种分离不仅增加了理解成本，还导致了配置来源的不一致性。

重构方案

经过团队讨论，决定将所有配置统一到 config 对象中：

const { build } = require('@umijs/mako');
await build({
  root: process.cwd(),
  watch: false,
  config: {
    plugins: [],
    less: {},
    forkTsChecker: true
  },
});

这一变化带来了几个显著优势：

1. 配置来源单一化：所有配置都通过 config 对象传递，降低了认知负担
2. 与配置文件一致：API 配置与 mako.config.json 文件结构保持一致
3. 更好的可维护性：配置项集中管理，便于扩展和维护

技术实现细节

在具体实现上，团队面临几个技术挑战：

1. JSON 配置的限制：由于 mako.config.json 是纯 JSON 文件，其中的 plugins 只能通过路径字符串指定，而不能直接使用函数对象。但在 API 调用时，仍然支持传入函数形式的插件。

2. 配置合并策略：

   • 对于 plugins 配置，采用 extend 策略，合并 API 和配置文件中的插件列表
   • 对于 less 和 forkTsChecker 等配置，采用 merge 策略，深度合并两者配置

3. 类型系统调整：需要重新设计类型定义，确保 TypeScript 类型支持新的配置结构，同时保持向后兼容性

影响范围

此次重构属于破坏性变更，影响以下方面：

1. 直接调用 Mako API 的代码：需要将原先的顶级参数迁移到 config 对象中
2. 相关上层封装：如 @umijs/bundler-mako 等封装库需要相应调整
3. 文档和示例：需要更新所有相关文档反映这一变化

最佳实践建议

对于使用者，建议：

1. 逐步迁移到新的配置方式
2. 对于复杂插件配置，优先考虑通过 API 而非 JSON 配置文件传递
3. 利用 TypeScript 类型提示确保配置正确性

总结

Mako 项目的这次配置层重构体现了构建工具设计中的一个重要原则：配置的一致性优先。通过统一配置入口，不仅提升了开发者体验，也为未来的功能扩展打下了更好的基础。这种以终为始的设计思路，值得其他工具开发者借鉴。