唯品秀前端博客

前面Vue3+Vite2配置Eslint代码风格校验并自动补缺修复已经介绍了如何使用Eslint 和 Stylelint 来规范代码格式。但是有些开发人员会忽视这些错误和警告,直接将代码提交到代码仓库。这就会导致其他其他开发人员pull代码时可能会出现大段代码标红。下面介绍如何使用Husky + Commintlint + Lint-staged打造规范的Git检查工作流,确保我们的代码只有符合规范才能提交到代码仓库

一、Husky

git hook,也就是常说的Git钩子。husky官方文档,Git能在特定的重要动作发生时触发自定义脚本,使用husky可以挂载Git钩子,当我们本地进行git commit或git push等操作前,能够执行其它一些操作,比如进行ESLint检查,如果不通过,就不允许commit或push。其中,提交工作流钩子主要包括了以下四种,我们需要关注pre-commit和commit-msg钩子

  • pre-commit:该钩子在键入提交信息前运行。 它用于检查即将提交的快照。如果该钩子以非零值退出,Git 将放弃此次提交,你可以利用该钩子,来检查代码风格是否一致。
  • prepare-commit-msg:该钩子在启动提交信息编辑器之前,默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。
  • commit-msg:该钩子接收一个参数,此参数存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出,Git 将放弃提交,因此,可以用来在提交通过前验证项目状态或提交信息。
  • post-commit:该钩子一般用于通知之类的事情。

安装

我这里安装的Husky是^8.0.0版本,新版本与旧版本的配置会有所不同

1
2
npx husky-init
npm install

运行完会生成.husky文件夹,并在package.josn里添加如下命令(注意:该配置不是必须的

1
2
3
4
5
/*
每次npm install的时候会初始化husky(也就是.husky/_目录),保证了新人进入项目,husky是能够正常运行的,但它会缺失自定义配置的文件pre-commit等
所以实际一般我们会把.husky文件夹传到git仓库,这样大家拉到的配置都是一样的
*/

"prepare": "husky install"

生成pre-commit文件

1
2
3
4
# mac
npx husky add .husky/pre-commit 'npx lint-staged'
# win
npx husky add .husky/pre-commit // windows系统直接写入可能失败,需要手动添加下面命令到该文件

在.husky文件夹下默认就有了一个pre-commit文件,这个文件是用来定义git commit之前应该执行什么命令,注意,该文件不是普通文本文件,必须通过上面命令生成,而不要手动去添加,win系统手动将下面代码复制到pre-commit文件中

1
2
3
4
#!/usr/bin/env sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

二、lint-staged

默认情况下上面的命令会对所有的代码进行校验,这无疑是非常浪费时间的。这时候我们需要借助lint-staged(^13.0.3)来对暂存的 git 文件运行校验

安装

1
npm install lint-staged -D

配置

在package.json里添加如下命令代码

1
2
3
4
5
6
7
8
"lint-staged": {
  "src/**/*.{js,vue,jsx,ts,tsx}": [
    "npm run lint"
  ],
  "src/**/*.{scss,css,vue,less,html}": [
    "npm run lint"
  ]
}

也可以通过在根目录下创建.lintstagedrc文件,并在package.json > scripts下添加命令"lint-staged": "lint-staged",该方式自行研究,个人认为直接写在package.json下更直观

Commitlint

在多人协作的背景下,git 仓库和 workflow 的作用很重要。而对于 commit 提交的信息说明存在一定规范,现使用 commitlint + husky 规范 git commit -m "" 中的描述信息,白话文,当我们运行 git commmit -m 'xxx' 时,用来检查 xxx 是否满足固定格式的工具

安装

commitlint: 安装,制定提交规范(采用默认)

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

// 当前我安装版本
"@commitlint/cli": "^17.0.3",
"@commitlint/config-conventional": "^17.0.3",

生成配置文件commitlint.config.js,当然也可以是 .commitlintrc.js

1
echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js

husky: 还要为 git 配置 husky ,对 git 的 commit 操作进行校验。husky继承了Git下所有的钩子,在触发钩子的时候,husky可以阻止不合法的commit,push等等

生成commit-msg文件

1
2
3
4
# mac
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'
# win
npx husky add .husky/commit-msg // windows系统直接写入可能失败,需要手动添加下面命令到该文件

在.husky文件夹下默认就有了一个commit-msg文件,文件内容如下(注意,该文件不是普通文本文件,必须通过上面命令生成,而不要手动去添加,win系统手动将下面代码复制到commit-msg文件中):

1
2
3
4
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install commitlint --edit "$1"

当我们在当前项目中执行 git commit -m '测试提交' 时将触发commit-msg事件钩子并通知husky,从而执行 commitlint -E HUSKY_GIT_PARAMS命令,也就是我们刚开始安装的./node_modules/.bin/commitlint,它将读取commitlint.config.js配置规则并对我们刚刚提交的测试提交这串文字进行校验,若校验不通过,则在终端输出错误,commit终止。

Commitlint 提交规范

commitlint 推荐我们使用 config-conventional 配置去写 commit,提交格式(注意冒号后面有空格)

1
git commit -m <type>[optional scope]: <description>

常用的 type 类型

类型 描述
build 编译相关的修改,例如发布版本、对项目构建或者依赖的改动
chore 其他修改, 比如改变构建流程、或者增加依赖库、工具等
ci 持续集成修改
docs 文档修改
feat 新特性、新功能
fix 修改bug
perf 优化相关,比如提升性能、体验
refactor 代码重构
revert 回滚到上一个版本
style 代码风格相关, 注意不是 css 修改
test 测试用例修改

示例

1
2
git commit -m 'fix(account): 修复xxx的bug'
git commit -m 'refactor: 重构整个项目'

初始化@commitlint/cli的配置文件

在项目根目录创建名为commitlint.config.js或.commitlintrc.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
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'body-leading-blank': [2, 'always'],
    'footer-leading-blank': [1, 'always'],
    'header-max-length': [2, 'always', 108],
    'subject-empty': [2, 'never'],
    'type-empty': [2, 'never'],
    'type-enum': [
      2,
      'always',
      [
        'feat', // 新增功能
        'fix', // 修复问题 or bug
        'style', // 代码风格相关(不影响运行结果)
        'perf', // 优化 or 性能提升
        'chore', // 依赖更新 or 脚手架配置更新等
        'refactor', // 重构
        'docs', // 文档 or 注释
        'test', // 测试相关
        'build', // 打包构建
        'ci', // 持续集成
        'revert', // 撤销修改(回滚)
        'wip', // 开发中
        'workflow', // 工作流更新
        'types', // 类型定义文件更新
        'release', // 发布
      ],
    ],
  },
};
// 这些配置是什么意思?请自行查阅commitlint文档

参考资料

  1. husky 源码分析——这个库到底做了什么?
本站所有文章、图片、资源等如无特殊说明或标注,均为来自互联网或者站长原创,版权归原作者所有;仅作为个人学习、研究以及欣赏!如若本站内容侵犯了原著者的合法权益,可联系我们进行处理,邮箱:343049466@qq.com
赞(0) 打赏

上一篇:

下一篇:

相关推荐

1 条评论关于"2022前端规范ESLint之Git工作流规范 Husky + lint-staged + commitlint(下篇)"

表情

最新评论

  1. Panda
    Windows 10 Chrome 102.0.0.0

    虽然不是非常懂,但了解了 :cy:

  2. 暂无留言哦~~
谢谢你请我吃鸡腿*^_^*

支付宝扫一扫打赏

微信扫一扫打赏