在代码开发过程中,我们需要使用Eslint和Prettier来帮助我们检测代码质量和代码格式。其中涉及到如何在VsCode中进行相关配置、Eslint和Prettier规则冲突怎么办、如何在提交的时候进行代码检查。
VsCode配置Eslint和Prettier
安装Eslint插件
要在Vscode中通过Eslint检测语法,在我们开发的时候在语法不正确的地方进行波浪线提示,首先需要安装ESLint插件,如下图所示:
安装完插件后我们需要安装eslint npm包,插件需要通过这个eslint npm包来对我们的代码进行检测
npm i eslint
安装完npm包后我们需要初始化我们的eslintrc文件,在命令行执行以下命令:
npx eslint --init
然后根据提示和自己的项目依次进行选择,选择完成后生成一个.eslintrc.cjs文件
.eslintrc.cjs文件内容大致如下,我这边是Vue的项目,所以会引入Vue的Plugin:
module.exports = {
"env": {
"browser": true, // 支持浏览器环境的检测
"es2021": true, // 支持es2021语法的检测
"node": true // 支持node环境的检测
},
"extends": [
"eslint:recommended", // 使用eslint推荐的配置进行检测
"plugin:vue/vue3-essential" // 支持vue3相关语法的检测
],
"overrides": [
],
"parserOptions": {
"ecmaVersion": "latest", // 解析文件的时候使用最新的ecmaVersion
"sourceType": "module" // 文件是ES6模块规范
},
"plugins": [
"vue"
],
"rules": { // 配置自己项目特有的一些检测规则
}
}
通过以上配置Eslint插件已经可以对我们的配置进行检测了,比如我们写了一行const abc = 1;
,会有如下报错:
告诉我们abc定义了但是没有使用,这是配置在eslint:recommended插件里的规则。如果发现检测没有生效,看下下一节,可能是VsCode设置里的相关开关没打开,开关打开后还没生效可以重启下VsCode试试。
Vscode User Setting和Workspace Setting
在VsCode中除了安装插件,我们还需要对如何使用插件进行一些配置。
如果是Mac电脑我们通过同时按下Command + Shift + P会出现如下窗口:
然后我们看到第一行是Open User Settings,我们通过点击这个可以进入用户设置页面。 进去后我们看到的页面如下:
有两个Tab,分别是User和Workspace,这两个都是对VsCode进行配置的,其中User是对用户进行配置,可以理解为全局配置,在User里的配置项会对所有VsCode打开的文件有效。Workspace的配置只对当前工作目录有效,如果你改了Workspace里的配置,那么VsCode会在当前打开的目录下新建一个.vscode目录用来保存做的修改,Workspace里配置的优先级大于User里配置的优先级。
eslint.enable
如果我们发现我们配置了Eslint,但是检测没有生效,我们可以在设置中搜索eslint.enable,看下这个开关是否有打开,这个开关如果没打开的话,即使我们配置了Eslint,检查也不会生效。
这里我们切到workspace,然后把这个开关关掉。
会发现.vscode目录下出现了一个settings.json,里面的内容如下,即表示当前的这个项目不开启Eslint检查。
editor.codeActionsOnSave
在.eslintrc的rules里我们可以配置自己的规则,比如我们想要在项目里统一使用单引号的格式(默认是双引号),我们可以进行如下配置:
"rules": {
quotes: ["error", "single"]
}
可是配置完发现文件都标红了,因为文件默认都是用的双引号,一个个改成单引号又很麻烦,有没有什么简单的方法呢?
editor.codeActionsOnSave
我们可以通过在设置中配置editor.codeActionsOnSave在我们进行保存的时候自动格式化代码。
我们在设置中搜索codeActionsOnSave然后再点击Edit in settings.json,这个时候发现打开了.vscode目录下的settings.json文件,我们在这个文件里添加如下代码:
"editor.codeActionsOnSave": {
"source.fixAll": true,
"source.fixAll.eslint": true
},
目前文件完整的代码如下:
// settings.json
{
"editor.codeActionsOnSave": {
"source.fixAll": true,
"source.fixAll.eslint": false
},
"eslint.enable": true,
}
这个配置表示在我们保存的时候自动执行fix操作,且使用的是eslint进行fix操作。做完这个配置后我们在刚才标满红波浪线的文件夹中点击保存,发现双引号都被自动替换为单引号了,红波浪线全部消失了。
做完以上配置那么我们的项目已经可以用VsCode进行代码检测了,点击保存的时候也会帮你自动格式化一部分代码。
Prettier
上面通过Eslint已经可以检测代码了也可以做自动格式化了,为什么还需要Prettier呢?因为他们的侧重点其实是不同的,Eslint主要用于检测代码质量,帮你发现代码中的错误,而Prettier主要是检测代码格式,也就是检测你的代码美不美观,比如下面这行代码:
代码没什么问题,可是const abc = "1";
中间有很多空格,看起来很不美观,这使用点击保存,Eslint是不会帮你调整格式的,这个工作就需要交给Perttier来做。
安装Prettier插件
安装没什么难度,搜索Prettier直接进行安装就可以了
与Eslint安装完插件后还需要安装eslint npm包不同,Prettier不需要再额外安装npm包。
editor.formatOnSave 保存自动格式化
我们想要在保存的时候自动使用Prettier对我们的代码进行格式化,这时候我们需要配置editor.formatOnSave
我们把这个formatOnSave的勾选上,这个时候我们的settings.json新增了一行代码:
"editor.formatOnSave": true,
完成的代码变成了:
{
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll": true,
"source.fixAll.eslint": true
},
"eslint.enable": true
}
这个时候我们Save的时候会自动使用Prettier进行格式化,因为我们安装了Prettier后,VsCode会自动将Prettier设置为我们的默认格式化插件。
Prettier和Eslint冲突
有人说那不是会格式化两次吗,formatOnSave格式化了一次,codeActionsOnSave又格式化了一次,为什么需要两个配置项,简化成一个不行吗,这个其实社区也有给VsCode提过意见,VsCode给的答案大致意思是它们各司其职,所以还是要两个都保留。
放在Eslint和Prettier这里就是说:
"editor.formatOnSave": true,
这个配置项主要就是用来做样式的格式化,而"editor.codeActionsOnSave"
不仅局限于样式的格式化,还会做代码检查等其它工作。
所以我们可以两个同时使用,可是Prettier和Eslint的有些规则是重合的,如果同时使用的话会存在有冲突的可能。比如当我们同时配置了Eslint和Prettier,然后给Eslint加了使用单引号的规则,那么这个时候点击保存会出现下面的情况:
因为Prettier里的规则使用的双引号,两个同时存在的时候,最终格式化出来的结果会以Prettier里的规则为准,也就是说Eslint和Prettier都会对文件进行格式化,可是Prettier格式化的会覆盖掉Eslint格式化的。所以最终格式化的结果是双引号的。
这个时候Eslint的检测就会报错,所以显示了红色的波浪线,所以我们需要做一些配置,对Eslint和Prettier的规则做一下合并,大家都以最终的合并的规则为准,这样就不会有冲突了。
.prettierrc.js
我们可以在.prettierrc.js文件里配置我们项目的规则,这里的规则会覆盖Prettier的默认规则,我们可以让在这里修改有冲突的规则,让Eslint的规则和Prettier的规则一致。比如上面的单引号和双引号的问题,我们可以新建.prettierrc.js文件,然后在里面配置如下规则:
// .prettierrc.js
module.exports = {
singleQuote: true,
};
那么这时候Eslint和Prettier的规则都是需要使用单引号,就不会有冲突了。
eslint-plugin-prettier 和 eslint-config-prettier
如果说冲突的规则很多,或者说我们也不知道哪个规则冲突了,这样一个个手动去改有冲突的规则也太麻烦了,所以有两个插件可以帮我们做这个事情,它们是eslint-plugin-prettier和eslint-config-prettier。
其中eslint-config-prettier会把Eslint里和Prettier有冲突的规则关掉,eslint-plugin-prettier会将Prettier里的规则设置到Eslint里面,通过这两个插件的配合,就完成了Eslint和Prettier规则的合并,其中冲突的规则以Prettier里的规则为准。
首先需要安装这两个插件:
npm i eslint-plugin-prettier eslint-config-prettier -D
然后我们在Eslint的extends里添加如下配置"plugin:prettier/recommended"
,这一行一定要加在最后,因为后面的会覆盖前面的。
最终的配置如下:
// .eslintrc.cjs
module.exports = {
env: {
browser: true,
es2021: true,
node: true,
},
extends: [
"eslint:recommended",
"plugin:vue/vue3-essential",
"plugin:prettier/recommended",
],
overrides: [],
parserOptions: {
ecmaVersion: "latest",
sourceType: "module",
},
plugins: ["vue"],
rules: {
quotes: ["error", "single"],
},
};
保存后应该可以看到冲突的规则以Prettier为准了,Eslint相关的检测不会报错了,如果还没生效可以重启下VsCode试试。
.eslintignore和.prettierignore
有些文件我们可能不想做代码检测,比如node_modules里的,dist目录里的,这时候可以配置在这两个文件里面
代码提交检查
以上我们在Vscode里配置了Eslint和Prettier来检查和规范我们的代码,但这个只是针对编辑器里的错误提示,有的人可能没装这两个插件,有的人可能看到提示视而不见,所以我们需要在代码提交的时候对代码进行检查,来保证所有人提交的代码格式都是符合要求的。
husky
当我们提交git的时候,会触发一些钩子,我们可以在这些钩子里做一些检查,如果检查不通过那么不执行对应的提交操作,husky就是用来方便我们写钩子函数的,相关的文档可以看这个:husky连接
相关执行步骤如下: 首先安装husky
npm install husky -D
然后在package.json中添加prepare钩子,执行命令如下:
npm pkg set scripts.prepare="husky install"
npm run prepare
执行完之后会在package.json中添加如下命令:
"scripts": {
"prepare": "husky install",
},
prepare钩子会在我们执行完npm install后执行,这里因为我们不是第一次下载这个项目,所以手动执行npm run prepare
。
执行完之后会在根目录下生成一个.husky文件夹。
然后我们执行以下命令:
npx husky add .husky/pre-commit "npm run lint"
git add .husky/pre-commit
执行这个命令后会生成.husky/pre-commit文件,相关内容如下:
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npm run lint
表示在执行git commit命令的时候,会先执行npm run lint,这个命令通过了才会执行commit操作,否则中止commit操作。
然后我们执行了git add .husky/pre-commit
表示这个文件是要提交到远程仓库的。
我们需要在package.json里将lint命令添加上去:
// package.json
"scripts": {
"prepare": "husky install",
"lint": "eslint --fix ./src --ext .vue,.js,.ts"
},
通过以上配置我们在git commit提交的时候如果代码格式不正确首先eslint会自动给你fix一下,比如单引号、双引号这种如果可以fix的就自动给你fix了,而且Eslint已经合并了Prettier的配置,所以一些样式也会自动给你fix,如果有些错误是无法fix的,那么会报错然后退出,修改后才能继续commit。
lint-staged
lint-staged 一般结合 husky 来使用,它可以让 husky 的 hook
触发的命令只作用于 git
暂存区的文件,而不会影响到其他文件。避免我们下载了一个库,我们只改了一个文件,可是commit的时候却格式化了一大堆文件。可参考这个文档:lint-staged
具体配置步骤如下:
首先安装npm包
npm install --save-dev lint-staged
然后我们在package.json里增加如下配置:
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint --fix"
],
"*.vue": [
"eslint --fix"
],
"*.{html,vue,vss,sass,less}": [
"prettier --write"
],
"package.json": [
"prettier --write"
],
"*.md": [
"prettier --write"
]
},
这里面的规则表示当遇到对应的文件的时候用什么检测,比如这里当遇到*.{js,jsx,ts,tsx}
类型的文件的时候,使用eslint --fix
进行检测和修复,因为这是一个数组,如果需要多个检测规则,还可以继续添加,比如可以设置成这样:
"*.{js,jsx,ts,tsx}": [
"eslint --fix",
"prettier --write"
],
因为我们的Prettier规则已经集成到Eslint里了,所以这里写一个eslint --fix
就够了。
这时候我们在命令行执行
npx lint-staged
就可以对暂存区的文件进行检查,也就是执行了git add后的文件进行检查。
我们修改下pre-commit,将npm run lint修改为npx lint-staged就可以了,每次在执行git commit的时候,都会先调用npx lint-staged进行检查。
pre-commit文件如下
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npx lint-staged
到这里我们的代码检测工作就已经都完成了。
代码提交规范
代码质量得到保障之后,接下来就是要对提交的规范做一些保证。目前的规范最知名和流行的是Angular团队的规范。主要用到3个工具来保证提交的代码符合规范。
- 其中commitizen是一个命令行交互工具,用来帮助我们书写正确的Message格式。
- commitlint用来对message做校验。
- husky用来让我们设置在commit-msg这个git钩子里触发commitlint校验。
commitizen
commitizen有local安装和全局安装两种方式
commitizen local安装
首先安装commitizen
npm install --save-dev commitizen
然后安装cz-conventional-changelog,cz-conventional-changelog是一个commitizen的适配器,适配器的作用是按照某个指定的规范帮助我们生成commit message,cz-conventional-changelog预设的是Angular团队的规范。
npx commitizen init cz-conventional-changelog --save-dev --save-exact
执行完上述命令在我们的package.json里会新增如下代码:
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
}
commitizen.path就是我们执行commitizen指令的时候,要使用的适配器的路径。commitizen指令的名称是cz,所以这时候我们在命令行执行npx cz
,就相当于执行git commit
,不过npx cz
会以命令行的方式让我们填写commit的信息,如下所示:
commitizen 全局安装
commitizen也可以全局安装,步骤如下:
首先全局安装commitizen
npm install -g commitizen
然后在项目目录下执行:
commitizen init cz-conventional-changelog --save-dev --save-exact
这会在项目目录下安装cz-conventional-changelog然后在package.json里增加如下配置:
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
}
这个增加的配置和Local安装是一样的。
然后我们可以使用git cz
代替git commit
指令。
commitlint 和 husky
commitlint是用来校验我们提交的message格式的,需要搭配husky进行使用,使用步骤如下:
首先安装npm包:
# Install commitlint cli and conventional config
npm install --save-dev @commitlint/{config-conventional,cli}
# For Windows:
npm install --save-dev @commitlint/config-conventional @commitlint/cli
然后配置config:
# Configure commitlint to use conventional config
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
然后我们需要配置在git的commit-msg钩子执行相关的校验,首先安装husky(安装过就不用再安装了):
# Install Husky v6
npm install husky --save-dev
# or
yarn add husky --dev
# Activate hooks
npx husky install
# or
yarn husky install
然后添加hook:
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'
这时候如果我们提交的格式不正确就会报如下错误:
通过以上配置,我们提交的git commit message就不会太乱了。
参考资料: