ESLint Stylistic 项目中的缩进规则回归问题分析

在 JavaScript 代码风格检查工具 ESLint Stylistic 的最新版本中，缩进规则(indent)的一个变更引发了社区讨论。这个变更影响了多个知名项目如 Fastify 和 Undici 的代码风格检查结果，导致它们无法通过原有的 lint 检查。

问题背景

ESLint Stylistic 2.12.0 版本中对缩进规则的修改主要涉及三元表达式内部函数调用的缩进处理方式。具体表现为：

修改前接受的代码风格：

payload = (serializerFn === false)
  ? serializeError({
    error: statusCodes[statusCode + ''],
    code: error.code,
    message: error.message,
    statusCode
  })

修改后要求的代码风格：

payload = (serializerFn === false)
  ? serializeError({
      error: statusCodes[statusCode + ''],
      code: error.code,
      message: error.message,
      statusCode
    })

这一变更被开发者视为对长期存在问题的修复，但同时也被部分用户认为是破坏性变更，因为它强制改变了已被广泛接受的代码风格。

技术分析

从技术实现角度看，这个变更主要影响的是 offsetTernaryExpressions 选项的行为。该选项原本用于控制三元表达式内部的缩进方式，但之前的实现对于函数调用等特定情况的处理存在不一致性。

核心争议点在于：

1. 这是否是一个明显的错误修复
2. 还是仅仅是一种风格偏好的调整
3. 在语义化版本控制(SemVer)下，此类变更是否应该被视为破坏性变更

版本兼容性考量

在软件开发中，特别是工具链项目中，版本兼容性策略至关重要。ESLint Stylistic 团队认为这是对已知问题的修复，符合语义化版本中的"minor"版本更新原则。然而，下游项目如 neostandard 则认为这种改变用户现有代码风格的变更应该被视为破坏性变更，应当通过主版本升级来引入。

解决方案与建议

对于遇到此问题的开发者，可以考虑以下解决方案：

1. 接受新的缩进风格并运行自动修复
2. 在配置中明确设置缩进规则选项以保持原有行为
3. 暂时锁定 ESLint Stylistic 的版本以避免意外变更

从长期维护角度看，工具开发者需要在以下方面找到平衡：

• 代码风格的一致性
• 用户预期的稳定性
• 历史遗留问题的修复

最佳实践建议

对于使用代码风格检查工具的项目，建议：

1. 使用锁文件(package-lock.json 或 yarn.lock)固定依赖版本
2. 建立完善的CI测试流程，包括对新版本工具的兼容性测试
3. 对于共享配置(如 neostandard)，考虑提供过渡期和迁移指南
4. 关注工具更新日志，及时了解可能影响项目的变更

这个案例也提醒我们，在代码风格这种主观性较强的领域，工具开发者需要更加谨慎地评估变更的影响范围，并在必要时候提供兼容性选项。