ESLint

定义

ESLint 是一个用于检查 JavaScript 及 ECMAScript 代码是否符合既定规则的工具，其目标是让代码风格更一致并减少错误^[2]。它与 JSLint、JSHint 属于同类工具，不同之处在于把每条规则都做成可插拔的单元，能够在运行期间增删或替换^[2]。检查范围既包括传统意义上容易出错的写法，也包括缩进、引号、分号一类的风格约定，两种用途可以同时使用^[4]。

工具以 Node.js 编写，通过 npm 分发，通常作为开发依赖安装在项目本地，以免不同开发者因版本差异得到不一致的检查结果^[2]。在没有启用任何规则或引入共享配置的情况下，它不会对代码作出判断^[2]。

原理

ESLint 的工作过程分为解析、遍历和规则应用三个环节。源码先由解析器读取，转换为抽象语法树(Abstract Syntax Tree，AST)，树中每个节点对应变量声明、函数调用、条件语句等一种代码结构^[5]。随后工具深度优先地访问这棵树上的节点，配置中的规则则在对应节点被访问时执行判断并报告问题^[5]。

默认解析器是内置的 Espree，其行为与标准 JavaScript 运行时和语言版本保持一致；需要处理非标准语法时，可以换成自定义解析器^[1]。例如 TypeScript 代码通常交给 typescript-eslint 项目提供的解析器处理，这样 ESLint 就能读懂该类语法^[1]。

规则是 ESLint 的基本构件，一条规则校验代码是否满足某项预期，也可以携带自己的配置选项。以 semi 规则为例，它可以要求语句必须以分号结尾，也可以要求语句不得以分号结尾^[1]。内置规则有数百条，此外还能自行编写规则，或通过插件引入他人编写的规则^[1]。

规则可以在发现违规时给出修复，修复不会改变程序的业务逻辑，可通过命令行选项或编辑器扩展自动应用；另有建议型提示，因其可能改变逻辑而只能由使用者在编辑器中手动选择^[1]。配置文件中还可以声明共享配置、插件、处理器与格式化器，插件常用于支持 TypeScript 等语言扩展以及 React、Angular 等框架^[1]。

flowchart LR

A[源代码] --> B[解析器 Espree 或自定义解析器]

B --> C[抽象语法树 AST]

C --> D[遍历节点]

D --> E[按配置执行规则]

E --> F[报告问题]

F --> G[自动修复或建议]

发展历程

在 ESLint 出现之前，JavaScript 社区主要使用 JSLint 和 JSHint。这两个工具都不提供让使用者自行挂载规则的接口，若需要某条新规则，只能写好后争取被并入正式发行版本。Nicholas C. Zakas 在为 JSHint 贡献代码之后，认为这种模式难以满足项目和公司内部的定制需求，于是决定另做一个检查工具^[3]。

该项目于 2013 年 6 月启动，最初名为 JSCheck，一个月后改用现名，首个版本发布于 2013 年 6 月 30 日^[3]。早期版本使用 Esprima 解析代码，基于语法树处理规则，运行速度慢于只需一步处理的 JSHint，加之编辑器生态已被后者占据，因此并未立即取得优势^[6]。ECMAScript 6 的普及改变了这一局面，ESLint 能够分析较新的语言版本，使用范围随之扩大^[3]。

2016 年，专注于代码风格的 JSCS 团队并入 ESLint，JSCS 停止维护^[3]。同年 Palantir Technologies 推出面向 TypeScript 的 TSLint，2019 年 TSLint 并入 ESLint，成为插件 typescript-eslint^[3]。

2024 年 4 月发布的 ESLint v9.0.0 把新的平面配置(flat config)格式设为默认，配置写在 eslint.config.js 中，旧的 eslintrc 格式转为弃用并不再被自动查找^[7]。此后官方又针对 TypeScript 使用不便、扩展其他配置困难等问题作出调整，重新引入 extends 写法，并增加 defineConfig() 辅助函数与 globalIgnores() 辅助函数^[7]。

应用

最常见的用法是在命令行中对单个文件或整个目录执行检查，例如运行 npx eslint 后跟文件路径；命令行还提供指定配置、指定扩展名、指定解析器、输出到文件、按模式排除文件等选项^[8][2]。--fix 选项会尝试自动修复尽可能多的问题^[8]。

大多数文本编辑器都提供 ESLint 扩展，编辑过程中即在文件内标出检查结果，无需每次调用命令行；也可将其接入持续集成流程，在构建时统一执行检查^[1][2]。在团队协作中，常把 prettier 之类格式化工具与 ESLint 搭配使用，由前者负责排版、后者负责发现错误^[4]。

共享配置让团队不必从零配置规则，例如 eslint-config-airbnb-base 实现了 Airbnb 的 JavaScript 代码风格指南，这类配置通过 npm 分发^[1]。插件则用于特定框架的最佳实践，例如 @angular-eslint/eslint-plugin 收集了使用 Angular 时的推荐做法^[1]。除命令行外，ESLint 还提供 Node.js 接口，供插件、编辑器集成等工具以编程方式调用^[1]。

局限

ESLint 进行的是静态分析，即在不运行代码的前提下读取源码，因此无法发现只有在实际执行时才暴露的问题，例如依赖外部输入触发的逻辑错误或运行时环境差异导致的行为^[1]。它给出的结论取决于配置，未启用的规则不会生效，规则配置不当也可能产生大量与代码质量无关的提示^[2]。

受设计取舍影响，基于语法树的逐节点判断在速度上不如只做一遍扫描的早期工具，这是其面世之初未被广泛采用的原因之一^[6]。解析能力受解析器限制，遇到非标准语法必须更换相应解析器，否则无法正确解读代码^[1]。

自动修复只覆盖语法敏感、不会改变程序逻辑的违规，可能改变逻辑的改动只能以建议形式提供给使用者，需人工确认^[1]。此外，从 eslintrc 到平面配置的转换涉及选项名称与写法的变化，v9.0.0 还移除了若干格式化器和规则，旧项目升级时需要按迁移指南调整配置^[9]。

参见

• JSLint —— 较早的 JavaScript 语法检查工具，ESLint 的设计参照了它的思路。

• JSHint —— 由 JSLint 分支而来的可配置检查工具，ESLint 出现前的主要选择。

• 抽象语法树 —— ESLint 解析源码后得到的数据结构，规则即在遍历其上时生效。

• TypeScript —— ESLint 通过 typescript-eslint 插件与解析器支持该语言。

• Node.js —— ESLint 以该运行时编写并通过其包管理器分发。