Eslint 是现原我们每天都在用的工具,我们会用它的实挺 cli 或 api 来做代码错误检查和格式检查,有时候也会写一些 rule 来做自定义的简单检查和修复。 虽然每天都用,现原但我们却很少去了解它是实挺怎么实现的。而了解 Eslint 的简单实现原理能帮助我们更好的使用它,更好的现原写一些插件。 所以,实挺这篇文章我们就通过源码来探究下 Eslint 的简单实现原理吧。 Linter 是现原 eslint 最核心的类了,它提供了这几个 api: SourceCode 就是指的 AST(抽象语法树),Parser 是简单把源码字符串解析成 AST 的,而 Rule 则是现原我们配置的那些对 AST 进行检查的规则。这几个 api 比较容易理解。亿华云计算实挺 Linter 主要的简单功能是在 verify 和 verifyAndFix 里实现的,当命令行指定 --fix 或者配置文件指定 fix: true 就会调用 verifyAndFix 对代码进行检查并修复,否则会调用 verify 来进行检查。 那 verify 和 fix 是怎么实现的呢?这就是 eslint 最核心的部分了: 我们知道 Eslint 的 rule 是基于 AST 进行检查的,那就要先把源码 parse 成 AST。而 eslint 的 parser 也是可以切换的,需要先找到用啥 parser: 默认是 Eslint 自带的 espree,也可以通过配置来切换成别的 parser,比如 @eslint/babel-parser、@typescript/eslint-parser 等。 下面是 resolve parser 的逻辑: 确定了 parser 之后,就是调用 parse 方法了。 parser 的 parse 方法会把源码解析为 AST,服务器托管在 eslint 里是通过 SourceCode 来封装 AST 的。后面看到 SourceCode 就是指 AST. 有了 AST,就可以调用 rules 对 AST 进行检查了 parse 之后,会调用 runRules 方法对 AST 进行检查,返回结果就是 problems,也就是有什么错误和怎么修复的信息。 那 runRules 是怎么运行的 rule 呢? rule 的实现如下,就是注册了对什么 AST 做什么检查,这点和 babel 插件很类似。 runRules 会遍历 AST,然后遇到不同的 AST 会 emit 不同的事件。rule 里处理什么 AST 就会监听什么事件,这样通过事件监听的方式,就可以在遍历 AST 的过程中,执行不同的 rule 了。 注册 listener: 遍历 AST,emit 不同的云南idc服务商事件,触发 listener: 这样,遍历完一遍 AST,也就调用了所有的 rules,这就是 rule 的运行机制。 还有,遍历的过程中会传入 context,rule 里可以拿到,比如 scope、settings 等。 还有 ruleContext,调用 AST 的 listener 的时候可以拿到: 而 rule 里面就是通过这个 report 的 api 进行报错的,那这样就可以把所有的错误收集起来,然后进行打印。 这个 problem 是什么呢? linting problem lint problem 是检查的结果,也就是从哪一行(line)哪一列(column)到哪一行(endLine)哪一列(endColumn),有什么错误(message)。 还有就是怎么修复(fix),修复其实就是 从那个下标到哪个下标(range),替换成什么文本(text)。 为什么 fix 是 range 返回和 text 这样的结构呢?因为它的实现就是简单的字符串替换。 遍历完 AST,调用了所有的 rules,收集到了 linting problems 之后,就可以进行 fix 了。 fix 部分的相关源码是这样的: 也就是 verify 进行检查,然后根据 fix 信息自动 fix。 fix 其实就是个字符串替换: 有的同学可能注意到了,字符串替换为什么要加个 while 循环呢? 因为多个 fix 之间的 range 也就是替换的范围可能是有重叠的,如果有重叠就放到下一次来修复,这样 while 循环最多修复 10 次,如果还有 fix 没修复就不修了。 这就是 fix 的实现原理,通过字符串替换来实现的,如果有重叠就循环来 fix。 其实核心的 verify 和 fix 的流程就是上面那些,但是 Eslint 还支持之前和之后做一些处理。也就是 pre 和 post 的 process,这些也是在插件里定义的。 之前的处理是把非 js 文件解析出其中的一个个 js 文件来,这和 webpack 的 loader 很像,这使得 Eslint 可以处理非 JS 文件的 lint。 之后的处理呢?那肯定是处理 problems 啊,也就是 messages,可以过滤掉一些 messages,或者做一些修改之类的。 那 preprocess 和 postprocess 是怎么实现的呢? 这个就比较简单了,就是在 verify 之前和之后调用就行。 通过 comment directives 来过滤掉一些 problems 我们知道 eslint 还支持通过注释来配置,比如 /* eslint-disable */ /*eslint-enable*/ 这种。 那它是怎么实现的呢? 注释的配置是通过扫描 AST 来收集所有的配置的,这种配置叫做 commentDirective,也就是哪行那列 Eslint 是否生效。 然后在 verify 结束的时候,对收集到的 linting problems 做一次过滤即可。 上面讲的这些就是 Eslint 的实现原理: Linter 是实现核心功能的,上面我们介绍过了,但是在命令行的场景下还需要处理一些命令行参数,也就需要再包装一层 CLIEngine,用来做文件的读写,命令行参数的解析。 它有 executeOnFiles 和 executeOnText 等 api,是基于 Linter 类的上层封装。 但是 CLIEngine 并没有直接暴露出去,而是又包装了一层 EsLint 类,它只是一层比较好用的门面,隐藏了一些无关信息。 我们看下 eslint 最终暴露出来的这几个 api: 我们通过源码理清了 eslint 的实现原理: ESLint 的核心类是 Linter,它分为这样几步: 除了核心的 Linter 类外,还有用于处理配置和读写文件的 CLIEngine 类,以及最终暴露出去的 Eslint 类。 这就是 Eslint 的实现原理,其实还是挺简单的: 基于 AST 做检查,基于字符串做 fix,之前之后还有 pre 与 post 的process,支持注释来配置过滤掉一些 problems。 把这些理清楚之后,就算是源码层面掌握了 Eslint 了。Linter
确定 parser
parse 成 SourceCode
调用 rule 对 SourceCode 进行检查,获得 lintingProblems
通过字符串替换实现自动 fix
preprocess 和 postprocess
Eslint 和 CLIEngine 类
总结