🚑 Eslint 周边

[原创] 最后编辑于：2019-11-18 23:31:36@code#ESLint #前端 #最佳实践

!本篇文章过于久远，其中观点和内容可能已经不准确，请见谅!~

想分享的是让你知道 ESLint 的简单背景和用法，以及知道 ESLint 怎么在项目中发挥作用的。

1. ESlint 是个什么

顾名思义 ECMAScript Linter 就是一个 ES 规范的检查器，负责检查代码语法/风格/错误。

在天地初开之时，JS 依靠语法宽松、动态运行的特点更容易低门槛实现业务获得青睐，但也是因此很多语法和逻辑错误无法在静态检查阶段被发现，于是 JSLint 语法检查器出世，能够满足基本的代码静态检查需求，但是扩展性差几乎不可配置，后来在此基础上又 fork 出了 JSHint，很长时间内这两个工具和相关生态支持了最开始的代码检查需求，毕竟当事的 ES 版本稳定不变了很长一段时间。随着时代的发展，更加好用容易配置的 eslint 采用 ast 等功能在 es5 的时代大放异彩，比如 babel-eslint，一个插件就支持了更高级的语法。

最开始的需求是在代码上线之前检查出代码中的语法错误问题、编码问题还有一些代码风格问题。后面有编辑器的支持就可以在编码的过程中实时的提示语法问题。再后来可以在团队协作时提前强制检查错误和风格。到现在无论是个人还是团队作为必选功能集成在项目中。

ESlint 得以流行的很重要原因是灵活的可配置项，包括 plugins 扩展、继承、解析器、和细致可配置的规则等强大功能。

2. 简单使用

在工作文件夹下执行：

yarn add eslint --dev

初始化一个最简单的配置文件：

npx eslint --init

此处就会问是要 check syntax, find problems, and enforce code style 的三个功能，这个也是整个 ESLint 的全部目的。

再新建一个示例文件：

// demo.js
function add(a, b) {
  return a + b;
}
console.log(add(1, 1));

运行检查：

eslint demo.js

/workspace/demo.js
/Users/ubug/codes/kitu-demos/eslint/demo.js
  2:1   error  Expected indentation of 4 spaces but found 2  indent
  2:15  error  Extra semicolon                               semi
  5:1   error  Unexpected console statement                  no-console
  5:23  error  Extra semicolon                               semi
✖ 4 problems (4 errors, 0 warnings)
  3 errors and 0 warnings potentially fixable with the `--fix` option.

语法没问题，但是有 4 个错误，3个可以自动修复。分别是 indent、semi、no-console 三个错误，按照说明来看其中 indent、semi 是样式问题，而 no-console 是严格的代码问题。

3. ESlint 常见方案

团队协作工作中，代码规范越来越举足轻重，保持同样的代码风格，降低基本错误的出现等都是协作的基础，非常的依赖类似 ESlint 这样的工具完成这些个目标，所以在团队中使用 ESlint 的方案还是很重要的，不过团队的使用定制和个人的定制深度不同，团队的配置更倾向于严格，个人的更习惯稍稍宽松，加上自己的偏好。

npx eslint --init 在简单的个人项目中足够使用了，但是对于想深入定制的需求，规则和插件生态非常丰富的今天，这样的定制很耗费精力，好在业内已经完成了比较成熟的预设方案，比如比较早的 Airbnb、Google 定制的一套规范，包括 ESlint 推荐的 Standard、Recommanded 等。除此之外还有其他很多框架、公司也都有定制的规范，用法基本大同小异，推荐个人根据喜好做一个方案可以方便很多自己的小项目。

常见的是使用较强检查的 airbnb 或者 standard 进行语法检查，搭配 Prettier 限制一些团队特有的习惯限制，然后配合 Husky 或者 pre-commit 加上 lint-staged 实现提交前强制检查。

standard 例子：

yarn add --dev eslint-config-standard eslint-plugin-standard

module.exports = {
  "extends": ["standard"],
  "plugins": ["standard"],
}

4. Prettier

上面说的 Airbnb、Standard、Recommanded 等是比较完整的语法检查，代码规范，格式化，但是 Prettier 是比较特殊的一个，它只负责代码的格式化。

一方面 Prettier 有独立的包，可以独立执行代码的格式化，不依赖 ESLint。另一方面可以以插件的形式在 ESlint 中存在，代替 ESlint 中的格式化的功能。

所以 Prettier 是一个只负责代码格式化的工具，语法配置相关的规则不会涉及，所以也可以和 Airbnb 一起使用。

ESLint 繁多的规则，初始化的时候也会提示 To check syntax, find problems, and enforce code style，所以功能分为语法检查(a=;)、问题发现(不允许使用 console，但是检测到了 console) 和代码格式化(空格缩进数) 三个功能。“代码格式化” 就是 Prettier 要覆盖和拓展的。

禁用prettier冲突的规则：

yarn add --dev eslint-config-prettier

module.exports = {
  "extends": ["prettier"]
}

用 eslint 接管 prettier 的运行：

yarn add --dev eslint-plugin-prettier

module.exports = {
  "extends": ["prettier"],
  "plugins": ["prettier"],
}

5. typescript

TypeScript 和 ECMAScript 相比可以算是不同的语言了，解析是不同的，刚开始 Typescript 使用自己的 tslint 来实现这个功能，但是随着发展和定制化要求越来越高，目前官方已经放弃了 tslint，转而实现相关的 ESlint 生态，这其实是更好的选择。

yarn add --dev @typescript-eslint

module.exports = {
    "parser": "@typescript-eslint/parser",
    "plugins": [
        "@typescript-eslint"
    ],
};

6. 编辑器插件

如果你在项目根目录下面创建了 .eslintrc，然后安装 eslint 的插件，编辑器会提供语法、错误和格式化的提示，从这个用处来说也不用安装依赖了？

安装依赖与编辑器插件的区别：

安装编辑器插件，能根据项目配置文件，实现编辑器实时的代码检查、风格格式化等功能，但是去除插件或者更换编辑器这些功能就丢失了，毕竟是插件提供的功能。
安装依赖，根据 npm 脚本设置，可以用 githook 或者手动运行的方式在命令行运行，不依托于编辑器，但是并不能提供编辑器界面上的提示。

7. 配置

ESLint 配置文件生效优先级为 .eslintrc.js > .eslintrc.yaml > .eslintrc.yml > .eslintrc.json > .eslintrc > package.json

具体用法不聊，一篇官方文档即可完整说明全部的配置： Configuring ESLint，或者中文网站。

一个常见的配置文件如下：

{
  "extends": "eslint:recommended",
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "env": {
      "browser": true,
      "node": true
  },
  "plugins": [
    "import",
    "node",
    "promise",
    "standard"
  ],
  "globals": {
    "document": "readonly",
    "navigator": "readonly",
    "window": "readonly"
  },
  "rules": {
    "semi": 2
  },
}