ESLint Stylistic 项目规则合并的技术演进之路

ESLint Stylistic 项目近期完成了一项重要的架构调整——将原本分散的 JavaScript 和 TypeScript 规则实现合并到同一个包中。这一变革经历了四个精心规划的阶段，体现了项目团队对代码质量和用户体验的持续追求。

第一阶段：代码共置

项目团队首先采取了温和的渐进式策略，将 JavaScript 和 TypeScript 规则的实现文件放置在同一目录下，但保持它们作为独立文件存在。这种设计既实现了代码的物理聚合，又确保了运行时行为的完全一致。例如，indent 规则的目录结构变为同时包含针对不同语言的实现文件和测试文件。

这一阶段的巧妙之处在于，团队通过文件重定向的方式，使原有的子包（如 eslint-plugin-js）能够继续正常工作，只是简单地重新导出主包中的对应实现。这种设计保证了在架构调整过程中不会对现有用户造成任何破坏性影响。

第二阶段：功能整合

在第一阶段稳定运行后，团队开始着手重构各规则目录下的文件。关键目标是将 TypeScript 版本的规则实现进行增强，使其能够同时通过 JavaScript 和 TypeScript 的测试用例。这一阶段的工作为后续真正的代码合并奠定了技术基础。

通过让 TypeScript 规则实现兼容 JavaScript 用例，项目实际上创建了一个更加健壮和通用的规则基础架构。这种设计思路体现了现代前端工具链中"一次编写，多环境运行"的理念。

第三阶段：实现统一

在确保测试覆盖率完整的前提下，项目团队开始合并 JavaScript 和 TypeScript 规则的实现代码。这一过程严格遵循测试驱动的开发原则：所有重构工作都在现有测试用例的保护下进行，确保不会引入行为变更。

这种保守的重构策略虽然进度较慢，但最大程度地保障了项目的稳定性。团队对每个规则都进行了细致的合并工作，最终实现了单一代码库支持多语言场景的目标。

第四阶段：架构简化

随着技术实现的成熟，项目最终移除了冗余的子包结构，全面转向统一的包架构。这一变革伴随着大版本号的升级，标志着项目架构进入新阶段。

值得注意的是，这一架构调整虽然带来了诸多优势，但也引发了一些社区讨论，特别是关于 TypeScript 成为必要依赖的问题。项目团队认为，从长远维护和简化使用的角度考虑，这一调整利大于弊，同时也对社区贡献保持开放态度，欢迎针对纯 JavaScript 项目的优化方案。

ESLint Stylistic 的这次架构演进，展示了一个成熟开源项目如何进行平稳的技术转型，既推动了技术进步，又兼顾了用户体验和社区生态。这种分阶段、测试驱动的重构方法，值得其他项目借鉴。