各位好，我是前端西瓜哥。今天我们了解 husky 工具，在开发过程中执行一些规范的检查任务，涵盖代码格式的调整以及文档格式的整理。

git hook 和 husky

git钩子能够在git执行特定操作前后，运行相应脚本文件。

诸如预备性操作，可以在正式操作实施前运行特定指令，倘若该指令运行失败（状态码为1），则后续操作将不会进行；倘若该指令运行成功，则将执行预定操作。

或者 -msg，也能在正式 前取得 消息资料，来执行部分核实步骤。

借助 git hook 的功能，我们能够在操作执行前实施一些代码规范校验或自动美化处理，例如执行代码风格检查、进行格式标准化等任务。

git钩子是shell脚本，存放在项目.git/hooks文件夹里。有个挺麻烦的地方：.git目录下的文件是不会被git上传的。husky就是应对这个情况的一个方法。

当前 git 版本在 2.9 之后，能够借助对 git 的核心配置项进行设定，将钩子目录指向特定项目中的文件夹位置，这样一来，在实践层面便无需借助 husky 来达成同样效果

尽管 Husky 进行了某种程度的包装，确实能更便捷地运用 hook，例如借助指令就能迅速建立 hook，还可以将其设定为可直接运行的模式。

Husky 4 及更早版本采用点号完成设置。那个时期方案存在不足，即便未设定钩子也会引发相应动作。因此 Husky 4 进行了根本性调整。现在需要在 .husky 文件夹中直接放置钩子程序。

husky 安装和启用

不介绍 husky 4 以及更早版本的操作方法，它们已经不再适用了。

首先是安装：

yarn add -D husky
# 或用 npm
npm install husky --save-dev

然后执行 husky 命令行工具，启用 git hook：

npx husky install

该命令会创建一个 .husky 目录。

.husky
└── _
    ├── .gitignore
    └── husky.sh

此外，该指令会将 git 相关项目的本地核心配置调整为 .husky。因此，这个 .husky 文件夹就是用来存放 git 钩子程序代码的位置。

我们运行相关指令，能够查到当前 git 项目的本地设定包括：core设置等于husky。

git config --local --list

其他团队成员在获取项目资料时，或许会忽略先运行那个命令来激活 git 的钩子功能。不过，有一个操作是所有人必然会做的sublime text js 格式化，那就是通过 npm 或者 yarn 来安装项目所需的组件。

因此要借助 npm 的运行阶段指令，加入一个 。 在那个时刻会启动。

// package.json
{
  "scripts": {
   // ...
    "prepare": "husky install"
  }
}

这样就能保证新同事拉项目并安装依赖后，husky 被启用。

创建 hook

npx husky add .husky/pre-commit "npm test"

这个指令会在 .husky 目录里生成一个以 pre- 开头的脚本文件，里面包含执行 npm test 的命令，目的是在正式操作之前先运行测试用例进行验证。

这个脚本会自动设置为可执行。

若文件系人工建立，须手动运用chmod u+x pre-指令，将其设定为可执行状态。不然，钩子脚本将无法运行。

创建的脚本内容为：

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npm test

它会在真正开始前运行 npm test，一旦出现错误就会立刻停止。

实战：使用 校验 信息格式

我们期望在递交之际，可以核对内容，倘若不妥便不可接纳，此举旨在避免程序员递交些混乱、晦涩或纷杂的资料。

这种情形下要借助 -msg 钩子，咱们先弄个空白的 -msg。

npx husky add .husky/commit-msg ""

在 -msg 脚本里，我们能用 $1 获取提交内容。$1 指向 .git/ 目录，里面存有最近一次提交的详情。

能够获取信息，我们便可在其中执行核对操作，例如确认其格式是否为 feat: xxx。然而存在一个难点，即我们必须自行制定相关准则，同时也要独立完成代码编写工作。

那么，我们接下来要寻找那个工具，一旦找到它，它就是我们要找的那个东西。它是一个在命令行上运行的程序，可以用来检查某些内容，并且它内置了官方提供的检查标准，同时也能够让使用者自己设定检查的规则。

先安装 ：

yarn add -D @commitlint/cli @commitlint/config-conventional

然后创建 ..js 配置文件sublime text js 格式化，并添加内容，使用 @

/- 规则

module.exports = {
  extends: [配置文件的标准格式为"commitlint/config-conventional"],
};

/- 是一种广为人知的约定，我们必须遵循诸如 feat: 新增 util.js 或修正: 纠正错误文字这样的模式，详细说明可查阅：

https://www..org/en/v1.0.0/

然后我们在 -msg 钩子上加上：

npx --no -- commitlint --edit $1

配置后，我们测试下，先提交不规范的 ：

image-

加上开头的 类别 type，再提交，成功了：

image-

实战：使用 lint- 格式化要暂存区的文件

lint 是一款控制台程序，针对 git 的（缓存区）里的文件实施工具的排版，纠正部分格式上的瑕疵，然后将其重新置入（缓存区）。

一个常见的组合是，借助 husky 的 pre- 钩子先整理文件格式，然后才允许提交，pre- 钩子在真正操作开始前就启动，再结合 lint- 功能，可以完成一些代码风格的调整。

使用 lint- 强制提交的文件做格式化适用的场景：

部分团队成员所用的编辑器缺少或未配置格式化功能，导致代码在保存时无法自动调整格式，从而容易提交存在风格问题的代码；该项目经过一段时期才确立代码风格标准，计划逐步进行修正。若一次性全面格式化，可能产生大量需要手动调整的风格问题。

下面我们开始配置。

首先我们安装 lint-：

yarn add -D lint-staged

然后新增 pre- 钩子，内容为 npx lint-：

npx husky add .husky/pre-commit "npx lint-staged"

提交的文件包含多种格式，例如 js、md、less、mdx 等，因此必须进行设置，以便针对不同格式的文件应用不同的处理方式。

lint的设置可以存储在 .json 文件中，也可以存放在独立的配置文档里。我决定采用后一种方式，在工程的主文件夹里建立一个 .js 文件，并在里面写入以下信息：

module.exports = {
  "src/**/*.{js,jsx,ts,tsx}": "eslint --fix",
};

这里说明需要针对 src 目录中的 js、jsx、ts、tsx 结尾的文件进行操作，并应用 进行规范整理。我仅利用 来调整 js 和 ts 文件，其余类型则不作处理，你可以选择借助 来规范剩余文件。

关于 的配置，可以看我的这篇文章《 配置入门》。

这里有一个 可以参考，地址为：

https://.com/F-star/xigua-ui

结尾

Husky 是一个相当实用的程序，借助 git hook 在本地使用时，可以和若干格式化工具配合使用，对文件进行规范化处理，同时借助 lint 工具检查信息格式，是确保项目代码风格统一的重要手段。

如有侵权请联系删除！