前端工程规范-4：Git提交前代码规范检查（Husky + Lint-staged）

Git提交前代码规范检查

在前端项目开发中，规范git提交信息，也是经常使用的手段，如何确保团队成员都遵循ESint规则，且不会将不符合规范的代码推送到Git仓库？

答案是：使用带有git hooks功能的husky。git hooks是git内置的功能，它会在执行Git命令之前（或之后）进行一些其它操作。例如ESLint规则校验。husky依靠git hooks来触发EsLint规则校验，并确保团队成员提交和推送代码到git之前的代码无任何问题。

git hooks是什么?

git hooks是git在触发事件（例如：commit、push、receive）之前或之后执行的一组脚本，git hooks是git内置的功能，当在项目中使用 git init初始化git时就会自动添加git hooks，我们可以在/.git/hooks文件夹下找到每个事件的示例文件。

husky是什么？

需要注意的是，git hooks不受版本控制，即不会提交到git仓库中，我们添加到/.git/hooks文件夹中的文件只会在本地。

那么，当团队成员克隆仓库时不会自动将我们自定义的git hooks下载到本地，我们又如何确保每个团队成员都执行hooks？解决这个问题的办法就是使用husky。

husky使git hooks更易于管理，因为我们不必手动编写代码，我们只需要在husky提供的配置文件中添加想要执行的命令，例如提交之前运行ESLint，除此之外的一切都由husky处理。

需要下载的插件

依赖	描述
husky	操作 git hooks的工具，更方便的管理 git hooks 脚本
lint-staged	在提交之前进行 eslint 校验

1、husky（操作 git 钩子的工具）

安装husky

# "husky": "^9.1.6"
pnpm add --save-dev husky

husky init

pnpm exec husky init

init 命令简化了项目中的 husky 设置。它会在 .husky/ 中创建 pre-commit 脚本：

并更新 package.json 中的 prepare 脚本：

// package.json
{
  "scripts": {
    // ...其他代码
    "prepare": "husky"
  }
}

随后可根据你的工作流进行修改。

2、设置git hooks

husky安装完成，并配置好脚本后，我们就可以进行 git hooks 的设置。

git hooks让我们能够在git操作的特定命令发生时自动执行自定义的脚本，用来完成一些额外的事情。

而我们在git提交信息的规范中，一般常用的两个阶段是：pre-commit 和 commit-msg

除此以外，git hooks还有多个阶段，可以在需要的时候启用，比如以下这些：

• pre-receive：从本地版本完成一个推送后
• prepare-commit-msg：信息准备完成后但编辑尚未启动
• pre-push：push 之前执行
• post-update：在工作区更新完成后执行
• pre-rebase：在rebase操作之前执行

pre-commit

上面介绍中，提到husky工具会在根目录下生成 .husky 目录，保存有husky的基本配置。要想配置 git hooks，还得在这个目录下进行操作，可以采取下面两种方式。

1. 我们可以在刚刚生产的 .husky 目录下的pre-commit文件中添加以下代码，注意无后缀名，默认生产的pre-commit有pnpm test内容，将其删除改成以下内容：

pnpm run lint:eslint

2. 使用脚本命令生成pre-commit文件及其内容：

# V9
echo "pnpm run lint:eslint" > .husky/pre-commit

该脚本执行后，将在 .husky 目录下自动生成 pre-commit 文件（如果有则覆盖），并且写入对应的脚本命令：pnpm run lint:eslint，内容与上面的第一种方式一样。

完成以上操作后，当我们执行 git commit 命令时，就会自动执行eslint命令。除了eslint，我们也可以配置其他诸如 stylelint、prettier 等。

3. 如果执行失败，如下图：

应该重新执行pnpm exec husky init，这个错误通常是因为 .husky/pre-commit 脚本没有正确的执行权限或者文件格式不正确导致。

4. lint-staged

使用 husky 后，ESLint会在项目中的每个文件上都运行，这是个非常糟糕的主意。因为在未更改的代码上运行ESLint可能会导致出乎预料的错误。

对于大型项目，在每个文件上运行ESLint可能会消耗大量的时间。同样，在旧项目中消耗时间解决ESLint抛出的问题而不是研发新功能，是没意义的事。

那么，我们如何只在我们更改的代码上运行 ESLint?

答案是lint-staged。它的作用是只在当前提交中对已更改的文件运行 pre-commit hooks。并且还能对代码进行更多的设置，比如使用 prettier 格式化代码

安装

pnpm add lint-staged -D

修改pre-commit文件内容

pnpm run lint:lint-staged

在package.json文件中添加scripts脚本

"scripts": {
    //其他代码省略
    "lint:lint-staged": "lint-staged"
}

新增 lint-staged.config.cjs 文件

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": ["eslint --fix", "prettier --write", "stylelint --fix"],
  "*.{scss,less,styl,html}": ["stylelint --fix", "prettier --write"],
  "*.md": ["prettier --write"]
};

如果仅仅只是简单配置一下lint-staged，也可以直接在package.json文件中进行配置

.cjs 文件其实就是js文件，只是更加明显的说明这是一个模块文件，并且模块声明遵循的是CommonJS的标准。因此同理，也有 .mjs 的文件，表明这个文件是遵循ESM标准（ECMAScript Modules）的模块文件。

简单图示

1. .JS (JavaScript):

2. CJS (CommonJS):

3. MJS (ECMAScript Modules)：

测试

完成了上面的所有步骤，执行命令测试

注意必须先git add .，否则命令会提示→ No staged files found.

git add . 之后，我们使用git commit提交，触发pre-commit钩子，看看会出现什么情况

在git commit的时候，之前我们在.eslintrc.cjs中定义为error的项，直接帮我们定义错误，由于前面已经做过了格式化处理，所以这里只是显示了一些错误警告，图中提示代码中有2个未使用的变量，修改后：

按步骤执行命令，图示:

1. git add . : 提交修改；
2. git commit -m "🔧 build(husky): husky+git hooks初步构建完成"：提交本次修改信息
3. pnpm run lint:lint-staged：由于我们配置了husky ， pre-commit 会自动抓取git hooks的commit命令，从而触发执行 pnpm run lint:lint-staged 命令，并且 lint-staged 会根据 lint-staged.config.cjs 文件进行文件扫描吗，暂存提交的文件通过各项扫描后就会提交到本地仓库

🌈🥚后续篇章讲解

也许你会发现，上图的 git commit -m "🔧 build(husky): husky+git hooks初步构建完成" —— 提交的内容信息比较规范。那么下一篇内容着重讲解 git 的提交规范。