如何快速写出风格统一的代码(ESLint+Prettier+Ed
当大家在公司工作时,不可能永远是一个人维护一个项目,当多个人参与一个项目,每个人写的代码风格不一样,甚至是使用的编辑器不一样,都会导致最终产生的代码千差万别,后期维护项目的时候,如果进行了自动格式化代码,则会导致浪费大量的时间用来解决冲突,加大项目的维护难度。
那么如何能够快速的写出风格统一的代码成为了当务之急。
在工程化项目里,最理想的方法当然是通过借用可灵活配置的工具,实现自动化解决,这里介绍的解决方案是EditorConfig+Prettier+ESLint 的组合。
- EditorConfig: 跨编辑器和IDE编写代码,保持一致的简单编码风格;
- Prettier: 专注于代码格式化的工具,美化代码;
- ESLint:作代码质量检测、编码风格约束等;
EditorConfig
如果使用的是Vscode,先安装插件 EditorConfig for vs code
然后在项目根目录下新建.editorconfig文件
打开文件时,EditorConfig插件会在打开的文件的目录中以及每个父目录中查找名为.editorconfig的文件。如果到达根文件路径或找到root = true的EditorConfig文件,将停止对.editorconfig文件的搜索。
离文件最近的配置规则生效,优先级更高;一般在根目录设置一个配置文件即可。
在文件开头的root = true表示配置文件以此为准
[*]表示匹配所有的文件
一、常用属性配置
- 1、root<boolean> : 是否是顶级配置文件,设置为true的时候才会停止搜索.editorconfig文件
- 2、charset<"latin" | "utf-8" | "utf-8-bom" | "utf-16be" | "utf-16le"> : 文件编码格式
- 3、indent_style<"tab" | "space"> : 缩进方式
- 4、indent_size<number> : 缩进大小
- 5、end_of_line<"lf" | "cr" | "crlf"> : 换行符类型
- 6、insert_final_newline<boolean> : 是否让文件以空行结束
- 7、trim_trailing_whitespace<boolean> : 是否删除行尾空格
- 8、max_line_length<number> : 最大行宽。
EditorConfig包含的内容比较少,主要是配置我们的编辑器,编写代码时的简单规则,不足以满足项目更多需求。
Prettier
Prettier只关注格式化,并不具有lint检查语法等能力。它通过解析代码并匹配自己的一套规则,来强制执行一致的代码展示格式。
它在美化代码方面有很大的优势,配合ESLint可以对ESLint格式化基础上做一个很好的补充。
还是以VSCode为例,首先安装Prettier插件。
VSCode内置的代码格式化工具可以指定为由Prettier接管,此时右下角会显示为Prettier。可以自行配置格式化触发机制:换行时格式化、保存文件时格式化、还是自行快捷键触发;
默认情况下我都是使用默认的手动触发。
当在编辑器里格式化未生效时,可以在.settings.json里检查对应文件格式指定的格式化程序并调整就可以:
"[jsonc]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[vue]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[css]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[less]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
这样在VSCode编辑器里,触发文件格式化时就能根据配置自动美化格式代码。
可以在VSCode 首选项-设置-扩展或.settings.json中更改通用配置;
当然还可以在具体项目根目录设置.prettierrc单独配置;
比如以下一些配置:
{
// 设置强制单引号
"singleQuote": true,
// 为多行数组的非末尾行添加逗号 es5的对象,数组等
"trailingComma": "es5",
// 每行最大宽度 100
"printWidth": 100,
// 设置语句末尾不加分号
"semi": false,
// jsx中使用单引号
"jsxSingleQuote": true,
}
EsLint
ESLint 是一个在 JavaScript 代码中通过规则模式匹配作代码识别和报告的插件化的检测工具,它的目的是保证代码规范的一致性和及时发现代码问题、提前避免错误发生。
ESLint 的关注点是代码质量,检查代码风格并且会提示不符合风格规范的代码。除此之外 ESLint 也具有一部分代码格式化的功能。
使用方法:
1.安装:ESLint 可以安装在当前项目中或全局环境下,但因项目间存在的差异性,我们一般会将它安装在当前项目中。安装
yarn add --save-dev eslint
2.安装插件和解析器
假如项目中使用了TypeScript和React,则安装:
yarn add --save-dev typescript @typescript-eslint/parser
yarn add --save-dev eslint-plugin-react @typescript-eslint/eslint-plugin
其他的插件和解析器请根据实际项目需要安装。
3.创建配置文件
我们在项目的根目录下创建一个 .eslintrc.js,内容如下:
module.exports = {
parser: '@typescript-eslint/parser',
plugins: ['react','@typescript-eslint'],
rules: {
// 禁止使用 var
'no-var': "error",
// 优先使用 interface 而不是 type
'@typescript-eslint/consistent-type-definitions': [
"error",
"interface"
]
}
}
如果是用脚手架工具创建的项目,创建的时候勾选了eslint,则上面的3步操作,都会自动完成。
如何保存代码的时候自动格式化代码
vscode 中写完代码 Ctrl + s 保存即可格式化代码 或者 (Shift+Alt+f)
找到settings.json,settings.json里所有的配置都是在一个对象中,给这个对象添加属性
"editor.fontSize": 14,
"editor.formatOnType": true,
"editor.formatOnSave": true
editor.fontSize可以修改编辑器的字号,默认是14号,修改之后保存即可。
Prettier和EsLint的区别
prettier主要功能是用来做代码风格格式化的,eslint主要是做语法验证的,这2个一开始我也不懂,而且有部分像是否加分号,字符串使用单引号还是双引号这些他们都可以配置
我是这么理解的eslint是给你指出问题的,它告诉你你的代码有哪里不规范然后让你自己改(它可以帮你改一小部分),而prettier是你给它指定规则,然后它帮你完成格式化,它只有一个功能就是根据你的规则格式化代码,
因为eslint有一部分代码它也可以帮你格式化,并且使用了prettier-eslint后它的权重比prettier高,所以你给prettier设置的规则不生效,就要考虑是不是eslint影响了它
beautify和prettier
beautify和prettier都是能够格式化代码的插件
.jsbeautifyrc文件添加配置代码,也是在settings.json中添加vscode对beautify的使用,但是因为我们选用的Prettier,自然就舍弃Beautify了
Vscode编辑器里卸载掉Beautify插件
LF和CRLF引起的Git冲突
CRLF 是 carriage return line feed 的缩写,中文意思是回车换行。
LF 是 line feed 的缩写,中文意思也是换行。
它们都是文本换行的方式。
CRLF: "\r\n", windows系统环境下的换行方式
LF: "\n", Linux系统环境下的换行方式
他们之间的不同经常会导致不同会导致使用不同系统的同事之间的代码冲突问题。
在你使用git拉取代码的时候,git会自动将代码当中与你当前系统不同的换行方式转化成你当前系统的换行方式,从而造成这种冲突。
前面有说使用EditorConfig,在配置里添加end_of_line = lf
可以让项目里的文件改为统一的LF。
在git提交代码的时候,git status查看有对应文件的修改,但是git diff的时候查看不到修改内容的时候,很有可能是当前文件的换行方式发生了变化,虽然在绝大多数情况下这并不会引起冲突,但在团队协作的过程中,每次提交修改的代码应尽量减少修改不必要的文件,这是一个良好的习惯。