Mako 项目中 watch 机制对父节点变更的支持优化

背景

在现代前端构建工具中，文件变更监听（watch）是一个核心功能。Mako 作为一款新兴的构建工具，在处理文件依赖关系时需要解决一些特殊场景下的变更触发问题。本文将深入分析 Mako 项目中 watch 机制如何支持触发父节点变更的技术实现。

问题场景分析

在实际开发中，我们经常会遇到以下两种典型场景：

1. CSS Modules 场景
   当通过 import styles from './foo.css' 导入样式时，构建工具会进行一系列转换：

   • 先将路径转换为 ./foo.css?asmodule
   • 生成两部分内容：
     • 导入 ./foo.css?modules（实际处理后的 CSS 内容）
     • 导出 CSS module 的 JavaScript 映射对象

   这种转换形成了 a.js → foo.css?asmodule → foo.css?modules 的依赖链。当原始 foo.css 文件变更时，需要正确触发整个依赖链的更新。

2. Markdown 嵌入场景
   在类似 dumi 这样的文档工具中，一个 Markdown 文件可能嵌入另一个 Markdown 文件（如 <embed src='b.md' />）。此时需要确保当被嵌入的 b.md 变更时，能够触发包含它的 a.md 文件的重新构建。

现有实现分析

当前 Mako 的实现采用了较为复杂的处理逻辑：

1. 变更检测阶段需要判断是新增(Add)还是修改(Modify)操作
2. 通过查询 module graph 检查带特殊 query 的模块是否存在
3. 构建阶段需要额外处理相关依赖链

这种实现虽然能解决问题，但存在以下不足：

• 逻辑分散在多个处理阶段
• 对特定 query 的硬编码处理
• 缺乏统一的触发机制

技术方案优化

经过深入讨论，Mako 团队提出了更优雅的解决方案：

核心机制

1. 定义触发规则
   引入常量数组 WATCH_PARENTS，包含需要触发父节点变更的特殊 query 标识（如 "modules" 和 "watch=parent"）。

2. 变更传播逻辑
   在 update 处理阶段：

   • 检测到文件变更时（如 aaa.xxx）
   • 检查 aaa.xxx?modules 和 aaa.xxx?watch=parent 是否存在于 module graph
   • 若存在，则将目标模块及其父模块加入处理队列

设计考量

1. 多 query 支持的必要性
   由于 CSS Modules 场景中 ?modules query 是必须的，如果仅使用 watch=parent，则需要组合为 ?modules&watch=parent。这会导致在变更检测时难以自动添加复合 query 进行匹配。

2. 扩展性设计
   通过定义常量数组的方式，未来可以方便地扩展更多需要触发父节点变更的场景，而无需修改核心逻辑。

实现价值

这一优化方案带来了以下优势：

1. 逻辑集中化
   将原本分散在各处的特殊处理逻辑集中到统一的机制中。

2. 更好的可维护性
   通过声明式配置替代硬编码逻辑，使代码更易于理解和维护。

3. 更强的扩展性
   新的开发者可以很容易地添加新的触发规则，而不需要深入理解整个变更传播机制。

总结

Mako 通过对 watch 机制的优化，巧妙地解决了构建过程中复杂依赖关系的变更触发问题。这种基于声明式配置的方案不仅解决了当前的技术难题，还为未来的功能扩展奠定了良好的基础。对于前端构建工具的开发者而言，这种设计思路值得借鉴和学习。