最近在项目部署了ESlint还有一些配套的工具，比如 prettier husky lint-staged，有些心得写出来分享下。

依据本篇可以实现在git commit之时，重新格式化代码，同时进行代码检查预防一些低级错误。最终期待项目中的开发人员提交到线上的代码符合代码规范、风格统一，看起来像是一个人写的。

实现过程

-> 待提交的代码
-> git add 添加到暂存区
-> 执行 git commit
-> husky注册在git pre-commit的钩子调起 lint-staged
-> lint-staged 取得所有被提交的文件依次执行写好的任务（ESLint 和 Prettier）
-> 如果有错误（没通过ESlint检查）则停止任务，等待下次commit，同时打印错误信息
-> 成功提交

嗯……这个任务链看起来挺长的，但不要怕，也只是需要装的模块有点多罢了。
可以看成两个部分，代码整理部分、pre-commit 函数部分。

husky 注册 git hook

安装

npm i --save-dev husky lint-staged

添加 hook 函数

// package.json
{
...
    "scripts": {
        ...
        "precommit": "lint-staged", // git commit 执行这个命令，这个命令在调起 lint-staged
    },
    "lint-staged": {   // lint-staged 配置
        "app/**/*.{js,jsx}": [
            "prettier --tab-width 4 --write",
            "eslint --fix",
            "git add"
        ]
    },
...
}

这里 lint-staged 的配置是：在 git 的待提交的文件中，在 app 目录下的所有 .js .jsx 都要执行三条命令。前两条一会儿说，后一条是将处理过的代码重新 add 到 git 中。

粘贴的时候记得删掉注释，我们知道JSON是没有注释的

prettier 格式化代码

prettier 是强大的代码格式化工具，目的是统一团队的代码格式。相对于 ESlint 代码检查能力较弱。

安装

npm i --save-dev --save-exact prettier 

然后……就完成了~ 🎉🎉🎉

这里解释下刚才写在 lint-staged 里的命令参数

prettier --tab-width 4 --write

--tab-width 4 ：使用4个空格作为缩进 （嗯，我更喜欢2个，不过……我们的代码规范是4个 😷）
如果想用tab作为缩进可以加上--use-tabs， 这时--tab-width代表tab数量。

--write：默认prettier是直接标准输出到终端的，这个配置代表直接改写文件。

关于prettier的还有一些配置参考这里

ESLint

ESLint 相对来说是比较复杂的部分，很多次我都被繁多的规则和海量的报错吓退过，但好在概念很容易理解，在翻看别的开源项目的时候，发现真正要自行配置的规则也不过尔尔。

而ESLint的作用主要是为了检查代码有没有错误，有没有不和代码规范的地方。虽然 ESLint 有 --fix 的选项，可以自动修复一些格式上的问题，但程度并不能和 Prettier 相当。

Prettier的概念更像是无论你怎么写，走到我这里，都会被格式成我这一种样子。而ESLint 只在发现问题的地方进行 fix，这是两者在逻辑上有区别。

配置 ESLint 主要是配置规则，规则从何而来，那当然是人写的。所以我们在很多项目里都能见到类似 .eslintrc.json等类似的文件，这就是 ESLint 的配置文件。建议是初始化后一点一点修改这个配置文件，不要照抄Airbnb等等类似的规范，不然上来可能就报非常多的错误，一看就头大。

安装：

npm install --save-dev eslint 

// 如果项目使用了 React 需要再安一个 babel-eslint
npm install --save-dev eslint babel-eslint

ESLint 也可以全局安装，全局安装后可以方便用 ESLint 直接执行。

ESLint 初始化

ESLint 初始化可以帮助开发者快速生成一个基本的配置框架。

在项目文件夹下执行

node_modules/.bin/eslint --init
// 如果全局安装了 可以直接 eslint --init

这里会给我们三种方式来初始化ESlint

image

分别是 1. 问问题 2. 使用大厂的 3. 检查现有的代码自动生成

�我们这里直接选第一个，回答一些问题来确定配置。

image

根据实际情况回答就好了，即使不小心答错也没关系，都在配置文件里随时可以修改。

image

部分同学可能有疑惑关于line endings ，其实看一下编辑器下面，如果是 LF 选择 Windows，CR 就选 Linux 就好了 。这个关于windows和linux对换行符的定义不同导致的，有兴趣的同学可以自己搜搜。

image

生成的.eslintrc.json 根据选择的回答不同，大体都长这样

{
    "env": { 
        "browser": true,
        "commonjs": true,
        "es6": true
    },
    "extends": "eslint:recommended",
    "parserOptions": {
        "ecmaFeatures": {
            "experimentalObjectRestSpread": true,
            "jsx": true
        },
        "sourceType": "module"
    },
    "plugins": [
        "react"
    ],
    "rules": {
        "indent": [
            "error",
            4
        ],
        "linebreak-style": [
            "error",
            "windows"
        ],
        "quotes": [
            "error",
            "single"
        ],
        "semi": [
            "error",
            "always"
        ]
    }
}

ESLint 配置解释：

env: Environments，指定代码的运行环境。不同的运行环境，全局变量不一样，指明运行环境这样ESLint就能识别特定的全局变量。同时也会开启对应环境的语法支持，例如：es6。

parser：ESLint 默认使用Espree作为其解析器，但它并不能很好的适应 React 环境，所以刚才安装了 babel-eslint 用来代替默认的解析器，在配置里这么写"parser": "babel-eslint"。

plugins：顾名思义就是插件，插件是单独的npm包，命名一般以eslint-plugin开头，写的时候用字符串数组的形式，可以省略eslint-plugin开头。plugins一般包含一个或多个规则配置，可以在extends中引入。

extends：ESLint 不需要自行定义大量的规则，因为很多规则已被分组作为一个规则配置。

例如：eslint:recommended就是 ESLint 的推荐规则配置，包含了ESLint的规则 里前面有✔︎的部分，recommended 规则只在ESLint升级大版本的才有可能改变。

相对的 eslint:all 是应用所有的规则，但并不推荐这么做。另外，all 规则是根据版本随时变化的。
extends 还可以以字符串数组的形式定义。

"extends": ["eslint:recommended", "plugin:react/recommended"],

plugin:react/recommended 即为 eslint-plugin-react 插件中的提供的推荐规则配置。

另外还有一点，extends定义的规则如果有重复的，后面的规则会覆盖前面的。

rules：这里可以对规则进行细致的定义了，覆盖之前前面说的extends中定义的规则。例如 indent就是对缩进的修改。"indent": ["error",4] 前面一项代表错误等级，第二项是具体配置，有些规则有第三项选项，例如 indent 就有 { "SwitchCase": 1 }，代表对switch语句采取什么样的缩进策略，如果不设默认是0。具体可以定义什么 rules，可以参考这里

错误等级有三级 0，1，2，分别代表off，warning，error。error错误会终止 lint-staged 执行。

globals：全局变量，如果你的项目用到其他一些自定义的全局变量，"__DEV__": false这样配置，true
和 false 代表可不可以被修改。

其他可用的配置参考这个

React Native 项目的配置例子

{
  "parser": "babel-eslint",
  "env": {
    "commonjs": true,
    "es6": true,
    "react-native/react-native": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
  ],
  "parserOptions": {
    "ecmaFeatures": {
      "experimentalObjectRestSpread": true,
      "jsx": true
    },
    "sourceType": "module"
  },
  "plugins": [
    "react",
    "react-native",
  ],
  "rules": {
    "no-unused-vars": 1,
    "react/prop-types": 1,
    "react/display-name": 0,
  }
}

~后面跟了一堆是全局变量，没有使用 react-native 的 config 是因为到目前还不适配 ESLint 4版本。~
eslint-plugin-react-native已经更新了，这样配置又简洁了一些。

调试配置

配置肯定是不能拿来就用的，推荐先就只使用 eslint:recommended 版本，如果你的项目 indent 比较特殊，再到 rules 定义 indent 就可以了。

然后先用命令行命令先对代码库里比较典型文件测试一下

node_modules/.bin/eslint app/app.js --fix

加上 --fix 会自动修复一些问题，规则列表里前面有小扳手的是可以自动修复的。

image

不用担心，一开始肯定特别多。根据报错信息最后的规则名称，搜索搞清楚到底是为什么错，看这个错误对于你的项目库是什么程度，再到rules里去自定义这条规则。

处理好这一步，就完成部署 commit 自动处理代码的流程了。如果代码没有通过 ESLint 检查，就会出现这种通知，停止commit。

Webstorm

Webstorm

Terminal

image

Webstorm 插件

从前面看出 Webstorm的通知是不太友好的，我们可以用Webstorm的配置，方便更快的找到错误的发生点（但不是必须的）。

内置了ESlint工具

Webstorm 内置了ESlint工具，启动之后可以在编辑的时候就能看到哪里出错需要修复。

image

选好 Node 环境路径和 ESLint 包路径，勾线Enable就好了，会自动寻找ESLint的配置。
ESlint 路径：~/Documents/{Your Project}/node_modules/eslint

还可以在快捷键设置里给 Fix ESLint Problem 添加一个快捷键，快速进行代码格式化的操作。

image

个人感觉在检查代码出错的时候比较好用，但在实际写代码的时候我个人还是倾向于不开这个来写，经常看到报错信息，令人心情不好。

External Tools

我更倾向于自己写一个 External Tools ，方便对当前文件执行命令，在提交之前或者提交报错之后跑一遍，有详细的报错清单，找起来也很方便（但没打开ESLint设置看起来更直观）。

image

下面三项填入

node_modules/.bin/eslint
--fix $FilePathRelativeToProjectRoot$
$ProjectFileDir$

External Tools 可以设置快捷键，也可以通过 Webstorm 的命令面板搜索打开 cmd + shift + a。

image

image