本文已参与「新人创作礼」活动，一起开启掘金创作之路。

我们在上篇 Vue3 + TypeScript + vite 实现前端代码规范化 文章中通过使用 ESLint 、Prettier 、 StyleLint 实现了对代码语法和风格的统一，但上一篇所做到的格式化，都是通过运行命令的形式来检测和修复，当我们提交代码的时候，如果忘记进行检测了，是不是就会把风格不统一的代码给提交到远程仓库了，这显然是不合理的。

本文将介绍如何在提交代码的阶段，进行一些拦截验证，只有当代码符合了规则才准许提交并推送到远程仓库。

Husky

首先先来介绍一下，什么是 Husky 。

它可以向我们的项目中添加 Git hooks 。同时配合 lint-staged 可以方便的在代码提交前进行你想要的检测。

安装

这里需要注意下，本文所安装的 Husky 是 7 以上的版本，在 6 之后的版本，使用方式已经和之前的不一样了，对于 6 以下版本的使用方式，这里不做过多的介绍，有兴趣的可自行去百度。

首先，我们需要安装 Husky

pnpm i husky -D

接着在 package.json 中添加 prepare 脚本

"prepare": "husky install"

prepare 脚本会在 pnpm install 之后自动执行。也就是说当我们执行 pnpm install 安装完项目依赖后会执行 husky install 命令，该命令会创建 .husky/ 目录并指定该目录为 git hooks 所在的目录。

当然，首次创建可以直接执行 pnpm i 重新跑下依赖安装，或者也可以执行 npx husky install ，这两个方法都可以创建 .husky 目录。

配置

接着需要添加 git hooks ，运行一下命令创建 git hooks

npx husky add .husky/pre-commit "npm run lint:eslint"
npx husky add .husky/pre-commit "npm run lint:format"
npx husky add .husky/pre-commit "npm run lint:style"

这样，当我们在执行 git commit 的时候，就会先去执行 npm run lint:eslint 、 npm run lint:format 、npm run lint:style 这三个命令了。

这里，就会出现一个问题，就是以上三个命令，是针对所有文件进行处理，这导致了有些没有更改过的文件也会去执行代码格式化，增加了一些不必要的负担，所以，我们需要进行优化，这里采用了 lint-staged 来检测暂存区的文件。

lint-staged

安装

首先需要安装 lint-staged

pnpm i lint-staged -D

配置

在 package.json 中添加运行命令

"lint:lint-staged": "lint-staged -c ./.husky/lintstagedrc.js"

更改 .husky/pre-commit 文件的脚本

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

lint:lint-staged

接着，在 .husky 目录下创建 lintstagedrc.js 文件，并添加以下代码

module.exports = {
  '*.{js,jsx,ts,tsx}': ['eslint --fix', 'prettier --write'],
  '{!(package)*.json,*.code-snippets,.!(browserslist)*rc}': ['prettier --write--parser json'],
  'package.json': ['prettier --write'],
  '*.vue': ['prettier --write', 'stylelint --fix'],
  '*.{scss,less,styl,css,html}': ['stylelint --fix', 'prettier --write'],
  '*.md': ['prettier --write'],
  '*.hbs': ['prettier --write']
}

这样我们在 git commit 的时候，就可以看到只会修复暂存区的文件了

Git commit 验证

这里我们继续介绍下，如何验证 git commit 的信息规范

为了保证提交信息的可读性及统一性，我们需要对提交信息进行验证，只有符合规范的提交信息，才能提交到远程仓库来。

安装

首先我们需要安装以下依赖

pnpm i @commitlint/cli @commitlint/config-conventional -D

配置

执行 npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

该命令会在 .husky 目录下生成一个 commit-msg 文件。

接着在根目录下创建 commitlint.config.js 文件，并添加以下代码

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'init', // 初始化
        'feat', // 新功能(feature)
        'fix', // 修补bug
        'docs', // 文档(documentation)
        'style', // 格式、样式(不影响代码运行的变动)
        'refactor', // 重构(即不是新增功能，也不是修改BUG的代码)
        'perf', // 优化相关，比如提升性能、体验
        'test', // 添加测试
        'build', // 编译相关的修改，对项目构建或者依赖的改动
        'ci', // 持续集成修改
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回滚到上一个版本
        'workflow', // 工作流改进
        'mod', // 不确定分类的修改
        'wip', // 开发中
        'types', // 类型修改
        'release' // 版本发布
      ]
    ],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never']
  }
}

rules 可以根据团队情况自行配置

配置完成之后，我们在 git commit 的时候，如果提交信息没有以上类型开头的话，是会报错的

错误提交信息

git commit -m "test"

正确提交信息

git commit -m "feat: test"

总结

一个良好的提交规范及代码规范，是保证整个项目可维护性的一个前提。

通过以上的配置，我们就可以很好的约束和统一规范了。

如果想要查看相应代码，可查看 vue-element-plus-admin