现代前端工程化实践：Git、Husky、Commitlint与PNPM的协同作战

引言

Git Husky 与 Commitlint 是两个在 Git 工作流程中非常实用的工具，它们可以帮助团队维护代码质量和提交规范。Husky 是一个 Git 钩子管理器，允许你在仓库级别方便地配置钩子脚本；而 Commitlint 则是用来规范 Git 提交信息的工具，确保每次提交都遵循一定的格式标准。下面是一个关于如何使用这两个工具的简明教程，以及如何进行基本配置。

使用 Husky 和 Commitlit 的版本

"husky": "^9.0.11",
"@commitlint/cli": "^19.3.0",
"@commitlint/config-conventional": "^19.2.2",

安装 Husky 和 Commitlint

首先，你需要在项目中安装 Husky 和 Commitlint，以及 Commitlint 的一个预设规则库（如 @commitlint/config-conventional）来定义提交信息的格式规范。

npm install --save-dev husky @commitlint/cli @commitlint/config-conventional

配置 Husky

接下来，配置 Husky 以便在 git commit 命令执行前自动运行 Commitlint 检查。

init 命令简化了项目中的 husky 设置。它会在 .husky/ 中创建 pre-commit 脚本，并更新 package.json 中的 prepare 脚本。随后可根据你的工作流进行修改。

pnpm exec husky init

执行后的效果如下：

package.json 文件中 script 新增一行脚本：

配置 Commitlint

Commitlint 需要一个配置文件来定义提交信息的规则。通常这个文件名为 commitlint.config.js 或 .commitlintrc.json，位于项目根目录。这里我们使用 JavaScript 配置文件作为示例：

// .commitlint.config.js

export default {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'bug',      // 此项特别针对bug号，用于向测试反馈bug列表的bug修改情况
        'feat',     // 新功能（feature）
        'fix',      // 修补bug
        'docs',     // 文档（documentation）
        'style',    // 格式（不影响代码运行的变动）
        'refactor', // 重构（即不是新增功能，也不是修改bug的代码变动）
        'test',     // 增加测试
        'chore',    // 构建过程或辅助工具的变动
        'revert',   // feat(pencil): add ‘graphiteWidth’ option (撤销之前的commit)
        'merge'     // 合并分支， 例如： merge（前端页面）： feature-xxxx修改线程地址
      ]
    ]
  }
}

在这个配置中，我们继承了 @commitlint/config-conventional 的默认规则，并可以自定义一些规则来满足特定项目需求。

添加 commit-msg 钩子，提交时自动检测提交信息

在 .husky 目录下新建文件且没有后缀，名字是： commit-msg

pnpm dlx commitlint --edit $1

# $1 表示传递的第一个参数

实践提交

现在，当你尝试执行 git commit 时，Husky 会触发 Commitlint 对你的提交信息进行检查。如果格式不正确，它会给出错误信息并要求你修改。

• 正确的提交信息应该是这样的：

git commit -m "fix: 修复页面的样式问题"

其中，“fix”是提交类型的简短描述，冒号后紧跟空格和对本次提交的详细描述。

• 错误的提交信息如下：

git commit -m "新增 husky commitlit"

不出意外的话，将会报如下错误，并且提交中断

> husky-vue3-template@0.0.0 format G:\wokespace\github\husky-vue3-template
> eslint . --ext .vue,.js,.jsx,.cjs,.mjs,.ts,.tsx,.cts,.mts --fix --ignore-path .gitignore

.../packages/pnpm/store/v3/tmp/dlx-4288  | Progress: resolved 1, reused 0, downloaded 0, added 0
.../packages/pnpm/store/v3/tmp/dlx-4288  | Progress: resolved 114, reused 95, downloaded 0, added 0
.../packages/pnpm/store/v3/tmp/dlx-4288  | Progress: resolved 124, reused 124, downloaded 0, added 0
.../packages/pnpm/store/v3/tmp/dlx-4288  | +125 +++++++++++++
.../packages/pnpm/store/v3/tmp/dlx-4288  | Progress: resolved 125, reused 125, downloaded 0, added 29
.../packages/pnpm/store/v3/tmp/dlx-4288  | Progress: resolved 125, reused 125, downloaded 0, added 30
.../packages/pnpm/store/v3/tmp/dlx-4288  | Progress: resolved 125, reused 125, downloaded 0, added 115
.../packages/pnpm/store/v3/tmp/dlx-4288  | Progress: resolved 125, reused 125, downloaded 0, added 116
.../packages/pnpm/store/v3/tmp/dlx-4288  | Progress: resolved 125, reused 125, downloaded 0, added 125, done
⧗   input: 新增 husky commitlit
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

 .......

总结

通过结合 Husky 和 Commitlint，你可以有效地提高代码仓库的管理效率，确保每个提交都遵循一致的格式和高质量标准。这不仅有利于团队成员之间的沟通，也有助于自动化工具更好地理解和处理提交历史。希望这篇教程能帮助你顺利地在项目中应用这两个强大的工具。

关于工作流工具的内容已经说完了，但是我还想说点别的，主要想说一下我们应该学习哪些技术才能让它更加保值。

在我看来，越偏向于业务的技术越不容易过时，为什么呢？需求在变，技术一直在变，业务也一直在迭代。前端技术的发展非常快，也涌现出很多的框架（例如 HTML4 到 HTML5 的升级，或者从jQuery 到前端三大框架的转变），但是总归就是两个字：效率。

作为开发者，我们需要保持好奇心和学习热情，不断探索新的技术，只有这样，我们才能在这个快速发展的时代中立于不败之地。介绍一款程序员都应该知道的软件JNPF快速开发平台，很多人都尝试用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。

JNPF可以实现应用从创建、配置、开发、测试到发布、运维、升级等完整生命周期的管理。减少了传统应用程序的代码编写量，通过图形化、可视化的界面，以拖放组件的方式，即可快速生成应用程序的产品，大幅降低了开发企业管理类软件的难度。

当然，我更建议大家成为一个全栈，不要把自己的定位局限于前端。