Stylelint 项目中 FixerData 的优化与重构思考

背景与问题分析

在 Stylelint 这个流行的 CSS 代码质量检查工具中，FixerData 是一个记录自动修复操作的数据结构。近期在开发过程中，我们发现其中的 fixed 标志位存在设计上的模糊性和局限性。

当前实现中，FixerData 会在以下情况下被记录：

1. 规则能够修复问题且修复被实际应用
2. 规则能够修复问题但修复未被应用（由于配置禁用等）
3. 规则根本无法修复该问题

这种设计导致数据结构中存在大量实际上没有执行修复操作的记录，而 fixed 标志位原本的意图是区分"计算修复文本"和"实际应用修复"两种场景。

设计缺陷与改进方案

经过深入分析，我们认为这种设计存在几个关键问题：

1. 语义模糊：fixed 标志位同时承担了"修复被计算"和"修复被应用"两种含义，容易造成混淆
2. 数据冗余：记录了实际上没有产生修复效果的条目
3. 功能限制：在实现新功能（如仅计算修复文本而不应用）时会产生冲突

我们提出的改进方案是：

• 完全移除 fixed 标志位
• 仅在修复确实被应用时记录 FixerData
• 通过数据结构的存在与否来表示修复是否发生

技术实现细节

在具体实现上，我们重构了 isFixApplied 函数，使其逻辑更加清晰：

function isFixApplied({ fix, line, result: { stylelint }, ruleName }) {
  // 检查是否有修复函数
  if (!isFn(fix)) return false;
  
  // 检查是否启用了修复
  const shouldFix = Boolean(config.fix && !config.rules?.[ruleName][1]?.disableFix);
  
  // 检查是否被配置注释禁用
  const mayFix = shouldFix && (config.ignoreDisables || !isDisabled(ruleName, line, disabledRanges));
  
  if (!mayFix) return false;
  
  // 执行修复并记录数据
  fix();
  addFixData({ fixersData, ruleName });
  
  return true;
}

这种实现方式确保了：

1. 只有在修复确实会影响源代码时才会记录数据
2. 不会在以下情况记录数据：
   • 修复函数未被调用
   • 全局修复被禁用
   • 仅计算修复文本的场景

对现有功能的影响

这一改动主要影响 verbose 格式化器的输出行为。原先的实现会过滤 fixed 为 false 的条目，而新实现中这些条目根本不会被记录，从而简化了数据处理流程。

未来扩展性

虽然移除了 fixed 标志位，但我们保留了修复范围(range)信息，为将来实现更详细的修复报告功能(如显示具体修改位置)奠定了基础。同时，这种设计也为以下潜在需求预留了空间：

1. 区分修复被跳过的情况（由于配置注释）
2. 标记需要多轮修复才能解决的问题
3. 提供更精确的修复统计信息

总结

通过对 FixerData 结构的这次重构，我们不仅解决了当前的设计问题，还使代码更加清晰和易于维护。这种改进体现了良好的软件设计原则：通过简化数据结构来减少歧义，同时保持足够的灵活性以适应未来的需求变化。

对于 Stylelint 用户来说，这一变化不会影响现有的使用体验，但为工具未来的功能扩展打下了更坚实的基础。开发者可以基于这个更清晰的设计，继续完善 Stylelint 的自动修复能力。