前言
新进公司，前端基建为零，各自为战，但是也会有多人分模块来写的时候。为了以后代码的可持续发展，我得赶紧把代码规范那套用起来。我在文章《npx husky add .husky/pre-commit "npm test" 不起作用解决方案》 中解决了precommit钩子的问题，但是该钩子跑的eslint --fix是把所有的全量代码一起去fix的，在项目越来越大的时候就耗时了，所以，正确的做法应该是用lint-staged去fix本次commit的代码。
流程
- eslint 配置，执行
npx eslint --init，根据你的项目特点自己选择配置，最后会在项目根目录生成一个.eslintrc.js - 安装 husky lin-staged,网上很多教程过时了，2023年最新应该如下
pnpm install husky lint-staged -D
husky的操作步骤可按照这篇文章《npx husky add .husky/pre-commit "npm test" 不起作用解决方案》 做
- lint-staged 配置步骤
- 把 .husky/pre-commit文件里面的命令改成npm run precommit
- 然后在package.json新增命令precommit
"scripts": {
"precommit": "lint-staged"
},
- 在根目录新建lint-staged.config.js,这里的意思是commit的时候会修复暂存区中的.js , .vue结尾的文件
module.exports = {
"*.{js,vue}": "eslint --fix"
}
最后git commit提交时发现走precommit -> lint-staged -> "*.{js,vue}": "eslint --fix"
这样子做主要是因为之前虽然有eslint, 但是别人报错照样可以不改就commit提交，我拉代码发现别人提交的代码报错，很难受啊。
加上这些钩子检测以后，你改动的代码，只要push的时候执行eslint校验不通过就不能commit上去影响别人。如下：
Git commit 提交规范
上面只是说到了代码规范校验，但是符合规范的代码也会出bug的，比如一些老代码经过迭代后出错，有时候我们需要去看代码是怎么变更的来排查原因，这时候就要看一下git log了, 此时拥有清晰 commit 信息非常有助于排查。所以为了让开发者提交清晰完整的commit信息帮助排查，也要有一个 commit 提交规范。大家可以围观一下 vite-plugin-vue的commit变更记录
目前最为流行的提交信息规范来自于 Angular 团队。
规范中，主要就是要求提交内容要进行分类并填写内容，更为严格的规定是要求标注开发模块。
type：commit 的类型,有以下类型
- feat：新功能、新特性；
- fix: 修改 bug；
- perf：更改代码，以提高性能；
- refactor：代码重构（重构，在不影响代码内部行为、功能下的代码修改）；
- docs：文档修改；
- style：代码格式修改, 注意不是 css 修改（例如分号修改代码换行等）；
- test：测试用例新增、修改；
- build：影响项目构建或依赖项修改；
- revert：恢复上一次提交；
- ci：持续集成相关文件修改；
- chore：其他修改（不在上述类型中的修改）；
我们在提交commit的时候要标注type，上面那么多怎么记得住，放心，我们有工具帮您,首先安装依赖
pnpm i -D commitizen cz-conventional-changelog
然后在package.json中指定scripts与config。
"scripts": {
"commit": "git-cz"
},
"config": {
"commitizen": {
"path": "node_modules/cz-conventional-changelog"
}
}
最后我们先执行 git add . 添加你要提交的代码，然后可以不再用git commit -m 'xxxx'，改为 npm run commit 就会出现commit类型让你选择，按照指示步骤一步步来完成commit规范提交
这样子就可以写出一份标准的commit信息了。
但是有人不执行npm run commit ,直接git commit -m '我瞎几把写，让你看不懂'怎么办？
这时候就要有一个commit规范检查的动作，没错，和上面precmmit钩子类似，我们在commit-msg钩子执行commitlint来检查，不合规范的commit不让提交。
安装依赖：
pnpm i -D @commitlint/cli @commitlint/config-conventional
在项目根目录创建 commitlint.config.js
module.exports = {
extends: [
'@commitlint/config-conventional'
],
}
然后执行 npx husky add .husky/commit-msg "", 会发现 .husky目录多了一个commit-msg的文件，把内容改成如下：
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npx --no -- commitlint --edit "$1"
如此无论你通过执行npm run commit 还是 git commit -m 'xxx'最后都会走commitlint进行校验了。
当你提交代码没有按照规范填写 commit message 时，比如执行git commit -m 'update', 就会出现报错并且阻止你提交代码
总结
无规矩不成方圆。一个好的规范可以让项目可维护性大大提升。
