Ember CLI 项目中的 ESLint 配置现代化实践

在 Ember CLI 项目中，ESLint 配置的维护和更新一直是一个重要但容易被忽视的环节。随着 JavaScript 生态系统的演进，特别是 TypeScript 和 Glimmer 模板语法（GJS/GTS）的普及，传统的 ESLint 配置方式已经显得力不从心。

传统配置的痛点

过去，Ember CLI 项目中的 ESLint 配置采用了条件构建的方式，根据项目类型（JS/TS）动态生成不同的配置规则。这种方式虽然理论上灵活，但实际上带来了几个显著问题：

1. 迁移困难：当项目需要从纯 JavaScript 迁移到 TypeScript，或者引入 Glimmer 模板语法时，开发者需要深入理解 ESLint 的工作原理才能完成配置调整。

2. 维护复杂：条件构建逻辑增加了配置的复杂度，使得问题排查和规则更新变得困难。

3. 新手不友好：对于不熟悉 ESLint 内部机制的开发者，很难理解如何正确配置项目以满足现代开发需求。

现代化解决方案

针对这些问题，Ember 社区提出了更现代化的解决方案：

1. 统一配置：放弃条件构建方式，改为提供开箱即用的完整配置，覆盖 JavaScript、TypeScript、GJS 和 GTS 等各种使用场景。

2. 简化迁移：通过预设的配置覆盖（overrides）机制，让不同类型文件的规则可以自动适配，无需开发者手动调整。

3. 明确规则：为每种文件类型（.js、.ts、.gjs、.gts）提供清晰的规则定义，避免规则冲突或遗漏。

实施建议

对于正在使用 Ember CLI 的项目，升级 ESLint 配置时可以遵循以下步骤：

1. 首先更新所有相关的 lint 依赖到最新版本，确保支持最新的语法特性。

2. 采用新的扁平化配置格式（eslint.config.mjs），替代传统的 .eslintrc.js 配置方式。

3. 为不同类型的文件分别设置适当的解析器和规则覆盖：

   • JavaScript 文件使用 @typescript-eslint/parser 并禁用类型检查
   • TypeScript 文件启用完整的类型检查
   • Glimmer 模板文件使用专门的解析器

4. 集成 Prettier 进行代码格式化，确保代码风格统一。

最佳实践

在实际项目中，建议：

1. 将 lint 配置作为项目基础设施的一部分，与框架版本同步更新。

2. 为团队提供清晰的迁移指南，特别是从旧配置迁移到新配置的步骤。

3. 定期审查 lint 规则，确保它们仍然符合项目需求和团队偏好。

4. 考虑将配置提取为可共享的预设包，便于跨项目统一管理。

通过采用这些现代化实践，Ember CLI 项目可以显著改善开发体验，降低维护成本，并更好地支持 TypeScript 和 Glimmer 模板等现代技术栈。