Pre-commit钩子在前端项目中的实战应用与踩坑经验分享

先看效果，再看代码

最近在团队协作的时候，发现大家提交的代码质量参差不齐。有人直接把console.log留在代码里，有人没跑eslint就提交了代码，搞得每次code review都得花不少时间去处理这些小问题。折腾了半天后，我决定试试pre-commit钩子，亲测有效。

简单来说，pre-commit就是在你执行git commit之前自动运行一些脚本。比如我们可以用它来检查代码规范、运行单元测试等。核心配置其实很简单：

npx husky-init && npm install

运行完这行命令后，你会发现项目根目录多了个.husky文件夹，里面有一个pre-commit文件。默认会运行npm test，但我们一般需要自定义一些检查规则。

这个场景最好用：代码规范检查

我个人最常用的就是配合eslint和prettier来做代码规范检查。具体实现如下：

# 安装相关依赖
npm install eslint prettier lint-staged --save-dev

# 初始化eslint配置
npx eslint --init

然后修改package.json，添加lint-staged配置：

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write",
      "git add"
    ]
  }
}

最后修改.husky/pre-commit文件：

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

npx lint-staged

这样每次提交代码时，都会自动修复代码格式问题。如果修复不了，就会阻止提交。建议直接用这种方式，省心省力。

踩坑提醒：这三点一定注意

虽然配置看起来简单，但实际使用中还是有不少坑点需要注意：

• 性能问题：别一股脑把所有检查都塞进去。比如我们团队最初把单元测试也放pre-commit里，结果每次提交都要等30秒以上，大家都快疯了。后来只保留了代码规范检查。
• 特殊情况处理：有时候确实需要跳过检查，可以在commit时加上–no-verify参数。比如：git commit -m "紧急修复" --no-verify。但要小心使用，容易被滥用。
• 环境一致性：确保团队每个人的node版本和依赖一致，不然会出现某些人能提交、某些人报错的情况。建议配上.nvmrc和engines字段。

进阶玩法：多任务并行处理

当我们需要执行多个检查任务时，串行执行会很慢。这时候可以用npm-run-all来并行处理：

npm install npm-run-all --save-dev

然后修改package.json：

{
  "scripts": {
    "check:types": "tsc --noEmit",
    "check:lint": "eslint .",
    "check:format": "prettier --check .",
    "precommit": "npm-run-all --parallel check:*"
  }
}

这样三个检查任务会同时运行，速度提升明显。不过要注意控制并发数量，太多任务同时跑可能会占用大量资源。

还有更多可能性

除了代码检查，pre-commit还能做很多事情。比如：

• 检查是否有未加密的敏感信息（如API密钥）
• 验证changelog是否更新
• 检查依赖版本冲突
• 运行安全扫描工具

当然，具体实现要看项目需求。我个人觉得最重要的是找到合适的平衡点，既不能太宽松，也不能让开发流程变得太繁琐。

以上是我个人对pre-commit的一些实战经验分享，有更优的实现方式欢迎评论区交流。这个技巧的拓展用法还有很多，后续会继续分享这类博客。