如何打造一套规范的前端代码工作流
XPoet 前端鼓励师

本文教你如何使用 eslintprettiereditorConfig 来规范前端代码。

ESLint

ESLint 是一款插件化的 JavaScript 代码静态检查工具,其核心是通过对代码解析得到的 AST(Abstract Syntax Tree,抽象语法树)进行模式匹配,来分析代码达到检查代码质量和风格问题的能力。

安装

安装并初始化 eslint:

1
2
3
4
5
6
7
8
9
// 全局安装
npm install -g eslint

// cd 到项目根目录下
// 强制初始化 package.json
npm init -force

// 初始化 ESLint
eslint --init

使用方式

写注释

下面这行注释表示在当前文件中禁用 console 关键字

1
/* eslint no-console: "error" */

写文件

ESLint 支持 eslint.jseslintrc.yamleslintrc.json 类型的配置文件。

如 eslint.js 配置文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
module.exports = {
env: {
// 环境
browser: true,
es2021: true,
},
extends: [
// 拓展
eslint:recommended ,
plugin:@typescript-eslint/recommended ,
],
parser: @typescript-eslint/parser , // 解析器,本解析器支持Ts
parserOptions: {
// 解析器配置选项
ecmaVersion: 12, // 指定es版本
sourceType: module , // 代码支持es6,使用module
},
plugins: [
// 插件
@typescript-eslint ,
],
rules: {
// 规则
},
};

配置项

  • parser - 解析器
  • parserOptions - 解析器选项
  • env 和 globals - 环境和全局变量
  • rules - 规则
  • off 或 0,关闭规则
    • warn 或 1,开启规则
    • error 或 2,开启规则,并会出错阻止代码运行
  • plugins - 插件
  • extends - 拓展

配置优先级

规则是使用离要检测的文件最近的 .eslintrc 文件作为最高优先级。

  1. 行内配置
  2. 命令行选项
  3. 项目级配置
  4. IDE 环境配置

Prettier

Prettier 是一个代码格式化的工具。

安装使用

1
2
3
4
npm install --save-dev --save-exact prettier

// 格式化所有文件,npx命令是使用当前项目下的prettier
npx prettier --write .

配置文件

Prettier 支持 .prettierrc 为名称,以 .yaml.yml.json.js 为后缀的的配置文件,当然你也可以使用 package.json 文件中的 Prettier 属性来配置。

1
2
3
4
5
6
7
8
9
10
module.exports = {
printWidth: 80, //一行的字符数,如果超过会进行换行,默认为80
tabWidth: 2, //一个tab代表几个空格数,默认为4
useTabs: false, //是否使用tab进行缩进,默认为false,表示用空格进行缩减
singleQuote: false, //字符串是否使用单引号,默认为false,使用双引号
semi: true, //行位是否使用分号,默认为true
trailingComma: 'none', //是否使用尾逗号,有三个可选值"<none|es5|all>"
bracketSpacing: true, //对象大括号直接是否有空格,默认为true,效果:{ foo: bar }
parser: 'babylon', //代码的解析引擎,默认为babylon,与babel相同。
};

EditorConfig

EditorConfig 有助于维护跨多个编辑器和 IDE 从事同一项目的多个开发人员的一致编码风格,团队必备神器。

.editorconfig 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# EditorConfig is awesome: https://EditorConfig.org

# top-most EditorConfig file 表示是最顶层的配置文件,发现设为true时,才会停止查找.editorconfig文件
root = true

# Unix-style newlines with a newline ending every file 对于所有的文件 始终在文件末尾插入一个新行
[*]
end_of_line = lf
insert_final_newline = true

# Matches multiple files with brace expansion notation
# Set default charset 对于所有的js,py文件,设置文件字符集为utf-8
[*.{js,py}]
charset = utf-8

# 4 space indentation 控制py文件类型的缩进大小
[*.py]
indent_style = space
indent_size = 4

# Tab indentation (no size specified) 设置某中文件的缩进风格为tab Makefile未指明
[Makefile]
indent_style = tab

# Indentation override for all JS under lib directory 设置在lib目录下所有JS的缩进为
[lib/**.js]
indent_style = space
indent_size = 2

# Matches the exact files either package.json or .travis.yml 设置确切文件 package.json/.travis/.yml的缩进类型
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2

通配符

1
2
3
4
5
6
7
*                匹配除/之外的任意字符串
** 匹配任意字符串
? 匹配任意单个字符
[name] 匹配name中的任意一个单一字符
[!name] 匹配不存在name中的任意一个单一字符
{s1,s2,s3} 匹配给定的字符串中的任意一个(用逗号分隔)
{num1..num2} 匹配num1到num2之间的任意一个整数, 这里的num1和num2可以为正整数也可以为负整数

属性

1
2
3
4
5
6
7
8
indent_style    设置缩进风格(tab 是硬缩进,space 为软缩进)
indent_size 用一个整数定义的列数来设置缩进的宽度,如果 indent_style 为 tab,则此属性默认为tab_width
tab_width 用一个整数来设置 tab 缩进的列数。默认是 indent_size
end_of_line 设置换行符,值为 lf、cr 和 crlf
charset 设置编码,值为 latin1、utf-8、utf-8-bom、utf-16be 和 utf-16le,不建议使用utf-8-bom
trim_trailing_whitespace 设为 true 表示会去除换行行首的任意空白字符。
insert_final_newline 设为 true 表示使文件以一个空白行结尾
root 表示是最顶层的配置文件,发现设为true时,才会停止查找 .editorconfig 文件

VSCode 集成

我使用的是 VSCode ,来给它添加魔法,加 EditorConfigEslintPrettierGit 扩展。

下面是 Prettier 的扩展,我已安装好了,大家在扩展中自行搜索安装就好了。

image

配置全局工作区 setting.json 文件,在文件中加入以下配置:

1
2
3
4
5
6
// 设置全部语言在保存时自动格式化
"editor.formatOnSave": ture,
// 设置特定语言在保存时自动格式化
"[javascript]": {
"editor.formatOnSave": true
}

prettier 配置

1
2
3
4
5
6
7
8
{
// 设置全部语言的默认格式化程序为prettier
"editor.defaultFormatter": "esbenp.prettier-vscode",
// 设置特定语言的默认格式化程序为prettier
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
}

ESLint 配置

1
2
3
4
5
6
7
{
// 保存时自动修复
"editor.codeActionsOnSave": {
// For ESLint
"source.fixAll.eslint": true,
}
}

husky/lint-staged

在提交 git 之前,我们需要校验我们的代码是否符合规范,如果不符合,则不允许提交代码。

安装

1
2
3
4
npm install -D husky

// lint-staged 可以让husky只检验git工作区的文件,不会导致你一下出现成百上千个错误
npm install -D lint-staged

然后修改 package.json 增加配置:

1
2
3
4
5
6
7
8
9
10
11
"scripts": {
"precommit": "eslint src/**/*.js"
}
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"src/**/*.{js,vue}": ["prettier --write", "eslint --cache --fix", "git add"]
}

git commit 之前会进入 工作区文件的扫描,执行 prettier 脚本,修改 eslint 问题,然后重要提交到工作区。

Commitizen

一个格式化 commit message 的工具,为什么需要这个工具,下面是 angular.js 开源项目的 commit message,很清楚明了是不是,几乎所有大项目和大公司都在使用这种 commit 规范。

好处:

  • 提供更多的历史信息,方便快速浏览
  • 可以过滤某些 commit,便于筛选代码 review
  • 可以追踪 commit 生成更新日志
  • 可以关联 issues

安装

1
npm install -g commitizen

安装符合 AngularJS 规范的提交说明,初始化 cz-conventional-changelog 适配器:

1
commitizen init cz-conventional-changelog --save --save-exact

然后使用 git cz 命令 代替 git comit 来提交 git 说明:

image

定制化项目提交说明

上面的提交说明都是英文的,如果想自定义,可以试试 cz-customizable,先安装:

1
npm install cz-customizable --save-dev

修改 package.json 文件:

1
2
3
4
5
"config": {
"commitizen": {
"path": "node_modules/cz-customizable"
}
}

在项目根目录下创建 .cz.config.js 文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
use strict ;

module.exports = {

types: [
{value: 特性 , name: 特性: 一个新的特性 },
{value: 修复 , name: 修复: 修复一个Bug },
{value: 文档 , name: 文档: 变更的只有文档 },
{value: 格式 , name: 格式: 空格, 分号等格式修复 },
{value: 重构 , name: 重构: 代码重构,注意和特性、修复区分开 },
{value: 性能 , name: 性能: 提升性能 },
{value: 测试 , name: 测试: 添加一个测试 },
{value: 工具 , name: 工具: 开发工具变动(构建、脚手架工具等) },
{value: 回滚 , name: 回滚: 代码回退 }
],

scopes: [
{name: 模块1 },
{name: 模块2 },
{name: 模块3 },
{name: 模块4 }
],

// it needs to match the value for field type. Eg.: fix
/*
scopeOverrides: {
fix: [
{name: merge },
{name: style },
{name: e2eTest },
{name: unitTest }
]
},
*/
// override the messages, defaults are as follows
messages: {
type: 选择一种你的提交类型: ,
scope: 选择一个scope (可选): ,
// used if allowCustomScopes is true
customScope: Denote the SCOPE of this change: ,
subject: 短说明: ,
body: 长说明,使用"|"换行(可选):,
breaking: 非兼容性说明 (可选): ,
footer: 关联关闭的issue,例如:#31, #34(可选): ,
confirmCommit: 确定提交说明?
},

allowCustomScopes: true,
allowBreakingChanges: [ 特性 , 修复 ],

// limit subject length
subjectLimit: 100

};

然后运行 git cz

image

Commitizen 校验

检验提交的说明是否符合规范,不符合则不可以提交

1
2
3
4
npm install --save-dev @commitlint/cli

// 安装符合 Angular 风格的校验规则
npm install --save-dev @commitlint/config-conventional

在根目录下创建 commitlint.config.js 并配置检验:

1
2
3
module.exports = {
extends: [ @commitlint/config-conventional ]
};

然后在 package.json 中配置 husky ,之前我们已经安装过了,直接添加配置:

1
2
3
4
5
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}

给 commit 加表情

如这样子的,是不是更加生动形象了,有意思了。

image

安装:

1
npm i -g gitmoji-cli

使用:你可以在这个 gitmoji 网站找到更多的表情来丰富你的提交记录,只需要在提交记录中加上类型 :bug: 的代码就可以显示表情了。

image

参考资料

  • Post title:如何打造一套规范的前端代码工作流
  • Post author:XPoet
  • Create time:2021-03-17 17:12:55
  • Post link:https://xpoet.cn/2021/03/如何打造一套规范的前端代码工作流/
  • Copyright Notice:All articles in this blog are licensed under BY-NC-SA unless stating additionally.
 Comments