背景

众所周知，在前端工程中使用eslint来对代码进行检查有利于提高开发效率和提高代码的可维护性。但是实时上，我们还需要使用一个“工具链”才能配置实现完整的前端代码规范，包括husky、lint-staged、commitlint，本文将对这一系列工具的使用和配置进行介绍。

使用已有npm包配置eslint

eslint，其中es意为ecmascript标准，eslint的作用是对代码进行实时检查给出提示或者自动修复错误。eslint使用的配置文件的文件名为.eslintrc（或者.eslintrc.js和.eslintrc.json），配置文件的主要作用是配置一系列的语法规则。

第一步，对于基于typesctipt和react的工程而言，需要执行如下安装：

npm install eslint typescript eslint-plugin-react eslint-plugin-react-hooks @typescript-eslint/parser @typescript-eslint/eslint-plugin -D

第二步，配置规则。由于规则众多，直接配置规则是较为复杂的，但是好在我们现在已经有了很多开源的代码规范，这里我们使用腾讯的alloyteam团队开源的eslint-config-alloy。

npm install eslint-config-alloy -D

第三步，编写配置文件，.eslintrc配置如下

{
    "extends": [
        'alloy',
        'alloy/react',
        'alloy/typescript',
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "project": "./tsconfig.json"
    }
}

其中使用extends关键字来使用已有的规则即可，如果你的项目不是基于typescipt和react的，应当参考eslint-config-alloy的文档进行修改。此外，tsconfig.json的地址要替换为真实的文件地址。

第四步，为VSCode编辑器安装eslint插件。这一步可以直接在编辑器的插件市场中搜索eslint插件，插件将自动读取目录下的配置文件。安装后打开代码文件观察插件是否生效，若不生效，可以按照如下方法对编辑器进行配置。

在目录下新建目录.vscode，目录下新建配置文件settings.json，文件中新增如下配置

{
    "eslint.validate": [
        "typescript",
        "typescriptreact"
    ]
}

第五步，编辑目录下的package.json文件，增加配置

"scripts": {
	"eslint": "eslint --ext .ts,.tsx ./src/ts",
	"eslint:fix": "eslint --ext .ts,.tsx ./src/ts --fix",
}

此时运行npm run eslint将对工程目录下的/src/ts下的所有扩展名为ts和tsx的文件进行检测，运行npm run eslint:fix将使用eslint的自动修复功能对所有的错误尽可能进行修复。

husky

配置完eslint，我们可以通过运行命令行的方式来对代码进行检测，也可以通过编辑器插件实时看到代码中的问题。然而，我们不能仅仅依靠所有人的自觉性来对代码质量做出保证，更好的办法是在进行代码的提交时自动对代码进行检测，若存在问题就阻止提交，这样就能防止有问题的代码进入仓库。或者说我们需要一个”勾子（hooks）“，在git执行commit操作的时候自动运行，而husky这个包就是一种git hooks的实现。

首先执行npm install husky -D，进行安装，接下来在package.json中增加如下配置：

"husky": {
    "hooks": {
        "pre-commit": "npm run eslint",
    }
}

其中的pre-commit就是在commit之前执行的git hooks。这样配置之后，将在git执行commit操作之前调用eslint执行全局的代码检查，若存在问题，将阻止提交。

lint-staged

对于新的工程，在每次提交之前检查所有代码是合适的，然而大多数情况并非如此。对于已经存在的项目，面对项目中已经存在的众多问题，没有人愿意为过去的问题负责，在提交时执行全局的代码检查显然是不合适的。因此，我们选择使用lint-staged包，从而只对处于staged状态的文件进行代码检查。简单来说，每一次提交时只对修改过的文件使用执行eslint代码检查。

首先执行安装npm install lint-staged -D。

接下来修改package.json文件，增加如下配置，并且修改针对你husky的配置。

"lint-staged": {
    "src/**/*.{ts,tsx}": [
      "eslint"
    ]
},
"husky": {
    "hooks": {
        "pre-commit": "lint-staged",
    }
}

其中src/**/*.{ts,tsx}将会匹配src文件夹下极其子文件下的所有ts和tsx文件，比如src/index.ts、src/page/page1.tsx和src/utils/net/net.ts。当这些文件被修改后，在提交前eslint只会对这些文件执行eslint命令。实际使用中，这一部分需要按照实际情况做出修改。

commitlint

commitlint的作用是对git提交时的message进行格式规范，杜绝比如”test“、“增加log”、“fix a bug”这样的message。

首先安装npm包npm install commitlint @commitlint/config-conventional -D。其中@commitlint/config-conventional是一种格式规范。该规范规定了message的格式为<type>[optional scope]: <description>，其中type表示修改的类型，必须为下面的值中的一个，description为对修改的描述，内容应当尽可能详细，scope为可选项，表示修改涉及的内容。

其中的type只能为如下的几种情况：

message可以为例如“feat(春节红包分会场): 增加任务列表二各个按钮的曝光的数据上报，以及增加点击的数据上报”。在实际使用过程中，需要注意括号和冒号均为英文的冒号和括号，并且不要遗漏冒号之后的一个空格。

接下来，为了让commitlint在git执行提交时对输入的message进行检测，我同样需要使用git hooks。在package.json文件中增加如下配置：

"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
},
"commitlint": {
  "extends": [
    "@commitlint/config-conventional"
  ]
},

这两项配置，其一是使用了commit-msg这个”勾子“，来执行commitlint的命令，其二将@commitlint/config-conventional作为commitlint检测时遵循的规范。

What's more?

总结一下，目前文件package.json中的配置有：

"scripts": {
	"eslint": "eslint --ext .ts,.tsx ./src/ts",
	"eslint:fix": "eslint --ext .ts,.tsx ./src/ts --fix",
}
"lint-staged": {
  "src/**/*.{ts,tsx}": [
    "eslint"
  ]
},
"husky": {
  "hooks": {
    "pre-commit": "lint-staged",
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
},
"commitlint": {
  "extends": [
    "@commitlint/config-conventional"
  ]
}