2022 年 02 月 24 日
如果你是刚刚开始接触Eslint,在阅读本文前建议可以先学习上面两篇基础文章,在上面,我们已经完成了对一个vue项目的基本引入,现在我们需要集成更多的工具帮助我们的项目更加方便智能,我们一次加入以下工具吧。
prettier是一款代码风格格式化工具,我们在项目中已经用到了Eslint
了为什么还要使用这个工具呢?Eslint
属于代码质量工具,在对语法和一些规则验证的同时,可以对一些简单的例如单双引号,是否逗号结尾这些语法做检验,但是并没有办法对项目的风格比如代码的缩进,一行最多多少个字符,结尾需不需要再空一行等等的属于风格类型的问题进行修复和规定,所以我们需要prettier来完成对风格的规定。
在一个团队中,对于这种风格的规定显得有些难度,毕竟每个人的风格差异较大,要想做到每个人都遵守这一规定或者风格确实需要很大难度,所以如果你要使用他,那么建议先和团队商议下。
在使用前我们需要先弄清楚这个问题,很多人觉得有了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解决的的痛点,因为这些东西在开发阶段可以帮你发现很多低级的问题,将一些低级错误扼杀在摇篮中。
下载三个依赖包:
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错误
}
}
2022 年 02 月 24 日
Like
Download
Viewed