Eslint配套集成指南【03】
如果你是刚刚开始接触Eslint，在阅读本文前建议可以先学习上面两篇基础文章，在上面，我们已经完成了对一个vue项目的基本引入，现在我们需要集成更多的工具帮助我们的项目更加方便智能，我们一次加入以下工具吧。
本文所需插件及其工具包
- 【prettier】: 代码风格统一工具
- 处理eslint不能兼顾的代码风格，对于formatter ruls进行接管统一所有代码风格
- 【husky】： Git hooks 工具
- 对git执行的一些命令，通过对应的hooks钩子触发，执行自定义的脚本程序
- 【lint-staged】: 检测文件插件
- 只检测git add . 中暂存区的文件，对过滤出的文件执行脚本
- 【commitlint】: 代码提交检测
- 检测git commit 内容是否符合定义的规范
- 【commitizen】：代码提交内容标准化
- 提示定义输入标准的git commit 内容
prettier
prettier是一款代码风格格式化工具，我们在项目中已经用到了Eslint了为什么还要使用这个工具呢？Eslint属于代码质量工具，在对语法和一些规则验证的同时，可以对一些简单的例如单双引号，是否逗号结尾这些语法做检验，但是并没有办法对项目的风格比如代码的缩进，一行最多多少个字符，结尾需不需要再空一行等等的属于风格类型的问题进行修复和规定，所以我们需要prettier来完成对风格的规定。
在一个团队中，对于这种风格的规定显得有些难度，毕竟每个人的风格差异较大，要想做到每个人都遵守这一规定或者风格确实需要很大难度，所以如果你要使用他，那么建议先和团队商议下。
必备工具及插件
- 编辑器： Vscode studio
- 插件1： Eslint
- 插件2：prettier- code formatter
- 插件3：Prettier Eslint
eslint和prittier是什么关系？
在使用前我们需要先弄清楚这个问题，很多人觉得有了Eslint后不需要再使用Pritter了，实际上不管是谁，他们都是各种Linters通过定义和内置的Rules去检测代码，那么规则又分为两类：
- Formatting rules
这类规则就属于格式化类的规则，比如
max-len、keyword-spacing、semi等等这些规则，出现这种问题的时候，Eslint会提示你去修改这些规则，而Preiiter则不会管那么多，他会先把你的代码格式化成AST，再按照它的规则进行输出属于它风格的代码。 也就是说，当我们使用preiiter的时候，就不会去违反这些规则了，我们就不需要再去关心这些Formatting rules问题了，Prittier会帮我们去处理掉这些问题。 - Code-quality rules 这类规则就属于质量类的规则，比如不能用val，不能重复定义变量，定义不使用等等问题，Prettier对这类规则束手无策，这也正是Eslint的Linters解决的的痛点，因为这些东西在开发阶段可以帮你发现很多低级的问题，将一些低级错误扼杀在摇篮中。
在vue项目中Eslint集成prettier
下载三个依赖包：
npm i prettier eslint-config-prettier eslint-plugin-prettier -D
分别是prettier、eslint-config-prettier、eslint-pluginn-pettier，一个是基础包，其他两个则分别是需要配置在，Eslint的extends和plugin中的，在下载完这三个包之后，我们对上个文章的基础配置做点调整
module.exports = {
"root": true,
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": [ "airbnb-base", "plugin:vue/essential", "eslint-config-prettier" ],
"parserOptions": {
"ecmaVersion": "latest",
"sourceType": "module",
"ecmaFeatures": {}
},
"plugins": ["vue", "import", "eslint-plugin-prettier"],
"rules": {
'prettier/prettier': 2
} // 自定义规则和配置覆盖规则
}同时加入了一个插件eslint-plugin-import用来解决一些引入路径问题，因为在项目中我们会经常用到**@别名等代表src这种情况，Eslint**不能检测到。
正常情况，我们需要在extends和plugins都加入prettier，在7.0版本之后我们就可以省略掉plugins，在extends引入即可，可以省略掉plugins。
但是我发现貌似省略掉eslint-xxx会带来一个问题（Definition for rule 'prettier/prettier' was not found prettier/prettier）这个问题的原因我还没有找到，但是在上面使用全称可以解决掉这个问题，于是配置还是稍作修改，不胜率前缀就没问题了。
注意点
冲突问题： 一般情况，Eslint是拥有自己的formatter rules的，这里大概率会和prettier冲突，prettier拥有大部分的格式化是默认的内置的（他认为应该更少的开放用户自己的配置权限，更多的是用他们定义的风格，所以prettier的配置规则总共也才20多个很少），包括如果我们用了如上airbnb-base这种开源的别人的规则就更大概率存在冲突点，所以eslint-config-prettier就是解决这一问题的，我们在决定使用prettier的时候就说明我们需要prettier全权处理格式问题，我们在extends时要把prettier放在最后,因为后面的配置会覆盖掉前面的，也就是最终保留的规则依然是prettier最大，这里的顺序需要注意，在最后才能保证规则覆盖掉了，同时需要注意，这个时候就别在rules里面再去添加formatter rules了，因为自定义的配置权限最高，如果配置了又会对上面覆盖之后的格式产生冲突（这一点也踩了坑，我以为用了eslint-config-plugin覆盖就可以高枕无忧了，显然并不是这样）
当使用prettier的时候别忘了在rules里面加入这一条规则让其生效'prettier/prettier': 2
后续在rules里面就不要在配置Eslint关于格式化相关的规则了，只配置代码质量方面的规则即可。
想要自动保存就格式化上文有讲过，只需要在项目根目录创建**.vscode文件在里面创建settings.json**文件写入如下
{
"eslint.validate": ["html", "vue", "javascript", "jsx"],
"eslint.alwaysShowStatus": true, // 总是在 VSCode 显示 ESLint 的状态
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true, // 自动修复eslint的错误
"source.fixAll": true, // 修复prettier错误
}
}