代码错误检查和自动格式化对于我们来说都不陌生，它往往陪伴着我们的每一行代码输出、每一次保存提交，我们享受着自动格式化带来的便利，但偶尔也有些小问题影响体验。
比如，面对同一个项目，各位项目协作者格式化方案却不一致，导致文件提交中频繁的出现代码格式的变动，微微到影响代码review；完成某条分支的代码merge，开开心心 commit，却被一堆 eslint error 阻止了脚步，确认提醒无伤大雅之后， --no-verify 解决一切；自动保存的时候，发现引号在单双之间横跳 ...
那么，是谁赋予了编辑器自动代码检查的能力，格式化的规则从何而来又如何生效，使用格式化工具会遇到哪些问题，他们如何产生又如何解决呢？下面就来介绍本文的主角：ESLint[1]。
ESLint[2] 是一个JS代码检查工具，用于发现并修正语法错误和统一代码格式。也就是说 ESLint 关注两方面的问题：
为什么我们需要代码检查呢？JS 作为一种弱类型动态语言，写法会比较随心所欲，这便很容易引入问题并增加我们发现问题的成本。通过编写合适的规则来约束代码，利用代码校验工具来发现并修复问题，能让我们的代码更健壮，工程更可靠。ESLint 就是这么一个通过各种规则对我们的代码添加约束的工具。
JS 代码检查工具的发展历史中有三个里程碑式的存在：JSLint、JSHint 和 ESLint 。
JSLint 属于开山鼻祖，让广大前端工程师在如何更好的使用 JS 方面受益匪浅，其核心是使用JS实现了一个JS解析器Pratt，但它缺乏可配置性。
在强烈的可配置性的诉求下，JSHint应运而生，并快速取代了JSLint，其核心依然是 Pratt 解析器。随着前端技术爆炸式发展，JSHint 中规则检查和 Pratt 解析器强耦合的问题限制了其扩展性，难以满足快速 更新的ECMAScript 规则。
ESLint 重新出发，解耦解析器和规则检查的工作。解析器专注于源码的词法解析、语法解析，并生成符合 ESTree[3] 规范的 AST。ESLint 核心部分专注于配置生成、规则管理、上下文维护、遍历 AST、报告产出等主流程。ESLint 的规则、报告部分则通过约定接口的形式独立出来，方便自定义扩展。这良好的架构使得 ESLint 从一众 Linter 工具中脱颖而出。
基本的下载和初始化Getting Started with ESLint[4]。--init 命令会进入一堆设置选项，包括代码运行环境、是否使用 react/vue 框架、是否使用ts、代码风格设置等，可以根据个人需求来快速初始化出不同的配置，并会提示安装相应的依赖包。这使得我们可以以非常低的成本用上社区中的优秀实践。
# 下载，安装为开发时依赖
npm install eslint --save-dev
# 初始化
npx eslint --init