Mise任务运行器中的依赖追踪问题分析与解决方案

问题背景

Mise是一个现代化的任务运行工具，它在设计上更倾向于作为任务运行器而非完整的构建系统。最近发现的一个关键问题是：当使用mise run命令执行任务时，如果任务的依赖文件被删除或修改，系统无法正确识别这些变更并触发重新构建。

问题重现

假设我们有一个简单的构建任务配置，它会合并多个输入文件到一个输出文件中。当删除其中一个输入文件后再次运行任务，Mise会错误地认为源文件没有变化而跳过构建步骤，导致输出结果仍然包含已删除文件的内容。

技术分析

当前Mise的实现主要依赖文件修改时间(mtime)来判断是否需要重新构建。这种机制存在几个固有缺陷：

1. 文件被移动但mtime未改变时无法检测
2. 文件权限变更(chmod)不会更新mtime
3. 无法感知文件被删除的情况
4. 任务配置本身的变更不会触发重建

解决方案设计

核心思路

采用轻量级的文件路径和inode信息哈希机制，而非完整的文件内容校验，以平衡准确性和性能。具体实现要点包括：

1. 为每个任务生成唯一标识符(基于配置根路径和任务名称)
2. 记录所有输入文件的路径、inode、权限、大小等元数据
3. 将哈希信息持久化存储在用户本地状态目录中
4. 比较当前文件状态与存储状态决定是否需要重建

技术细节

1. 哈希内容：包含文件路径、inode编号、权限位、所有者信息等
2. 存储位置：用户主目录下的状态目录(~/.local/state/mise/task-sources/)
3. 性能优化：避免文件内容校验，仅使用元数据哈希
4. 配置变更感知：将任务配置本身也纳入哈希计算范围

实现考量

环境变量处理

虽然环境变量理论上也是构建输入的一部分，但考虑到：

1. Mise内部大量使用环境变量进行状态管理
2. 环境变量变化频繁且难以追踪
3. 性能开销较大

决定不自动追踪环境变量变化，用户可通过手动执行清理命令来处理特殊情况。

与现有功能的关系

该方案与现有的{ auto = true }输出配置功能相辅相成，共同完善Mise的构建系统特性，同时保持其作为任务运行器的核心定位。

未来扩展方向

1. 可选的文件内容校验模式(牺牲性能换取更高准确性)
2. 更精细的依赖关系追踪(包括任务间的依赖)
3. 支持与专业构建系统(如Ninja)的集成接口

总结

通过引入基于文件元数据的哈希追踪机制，Mise可以在保持轻量级特性的同时，显著提升其构建相关功能的可靠性。这一改进使Mise更适合作为中小型项目的构建工具，同时避免了向完整构建系统转变带来的复杂性。