Content

ESLint 是 JavaScript 和 TypeScript 生态中最重要的静态检查工具之一，用来发现潜在错误、约束代码风格并执行团队约定。它的核心价值不是“挑刺”，而是把代码质量要求从口头共识变成可执行规则，因此经常成为前端工程化的基础设施。

Acceptance

ESLint 是 JavaScript/TypeScript 的静态代码分析工具(linter)。它将代码解析为 AST,然后逐条运行”规则”(rule)检查潜在问题。

ESLint 管什么:

• 潜在 bug: if (x = 5) (赋值还是比较?)
• 未使用变量: let x = 5 但从未引用
• 危险 API: eval("code")
• 团队约定: 是否允许 console.log 残留

ESLint 不管什么:

• 类型是否正确 → 那是 TypeScript (tsc) 的事
• 缩进/换行/引号风格 → 那是 Prettier 的事

ESLint 和 Prettier 的冲突:
ESLint 有部分规则(如 indent, semi)也管格式,和 Prettier 重叠。需要 eslint-config-prettier 关掉 ESLint 的格式规则才能共存。这个”两个工具打架需要胶水包”的问题是 Biome 诞生的直接动机之一。

Question

• ESLint 的 --fix 能自动修复一些问题,Prettier 也能自动修改代码——两者的”自动修改”在本质上有什么区别?
• 为什么 ESLint 不能替代 TypeScript 做类型检查,即使有 @typescript-eslint 插件?
• ESLint 9.x 的 flat config 和之前的 .eslintrc 相比,设计动机是什么?

See Also

• AST

• Prettier

• Biome

• MindGym M0 session (2026-04-13) — 代码质量三维度讲解(类型/规范/格式)

• ESLint 官方文档：flat config migration guide / configuration files

YoYo’s Note

ESLint 的定位是”代码质量的第二维度”——第一维度是类型(tsc),第三维度是格式(Prettier)。三者各管一摊,互不替代。理解这个边界是理解前端工具链的基础。

ESLint 的核心抽象是”rule”:每条 rule 就是一个 AST visitor 函数,遍历语法树时在特定节点上触发检查。这意味着写一条自定义 ESLint rule 和写一个 Babel plugin 用的是同一套 visitor 模式——只是目的不同(一个检查,一个转换)。

Answer

ESLint 的 --fix 能自动修复一些问题,Prettier 也能自动修改代码——两者的”自动修改”在本质上有什么区别?

ESLint 的 --fix 是规则驱动的局部修复,重点在“这个具体问题能不能安全改掉”,比如删未使用变量、补分号、替换危险写法。Prettier 则是整体重打印,不关心单条规则,而是直接根据 AST 重建统一格式。前者更像“修错”,后者更像“重排版”。

为什么 ESLint 不能替代 TypeScript 做类型检查,即使有 @typescript-eslint 插件?

因为 ESLint 的核心模型仍然是基于语法树和规则系统做静态检查,而不是完整执行 TypeScript 的类型推导。@typescript-eslint 能借助类型信息做更强的规则,但它本质上还是挂在 lint 框架上的扩展层,无法完整替代 tsc 对类型系统一致性、声明解析和跨模块推导的职责。

ESLint 9.x 的 flat config 和之前的 .eslintrc 相比,设计动机是什么?

flat config 的核心动机是把配置模型简化成更可预测的 JS 数组结构,减少多层继承、隐式合并和历史包袱。旧 .eslintrc 时代的配置解析规则比较复杂,而 flat config 试图让“加载哪些文件,按什么顺序套哪些规则”变得更显式,也更适合现代 ESM 和 monorepo 场景。