Husky + lint-staged深度解析

# Husky 与 lint-staged：前端代码质量的守护者

1. 他是什么

想象一下，你正在准备一场重要的晚宴。在客人到来之前，你会检查餐桌是否摆正、餐具是否清洁、食物是否新鲜。Husky 和 lint-staged 就是前端项目中的这种“餐前检查员”。

Husky是一个工具，它允许你在 Git 操作的关键时刻（比如提交代码前）自动运行特定的检查脚本。就像门卫在客人进入宴会厅前检查他们的着装是否得体。

lint-staged则是 Husky 的得力助手，它专门负责检查那些“即将被提交的代码文件”。不是检查整个项目，而是只检查那些有变动的文件，就像只检查新摆上桌的餐具，而不是整个厨房的所有器皿。

这两个工具通常配合使用，在代码提交到仓库前自动执行代码质量检查，确保进入版本库的代码符合团队约定的规范。

2. 他能做什么

2.1 自动化代码质量检查

在开发者执行git commit命令时，Husky 会自动触发预设的钩子（hook），运行 lint-staged。lint-staged 则会对暂存区（staged）的文件运行指定的检查工具，比如：

• ESLint：检查 JavaScript/TypeScript 代码的语法和风格问题
• Prettier：自动格式化代码，保持统一的代码风格
• Stylelint：检查 CSS/SCSS 等样式文件的规范
• 测试用例：运行相关的单元测试

2.2 防止低质量代码进入仓库

如果检查发现代码有问题，提交过程会被中断。就像安检门发现违禁品时会发出警报并阻止通过。开发者必须修复所有问题后才能成功提交代码。

2.3 统一团队代码风格

无论团队中有多少开发者，每个人的代码提交前都会经过同样的质量检查。这就像工厂的质检流水线，确保每个出厂产品都符合标准。

2.4 提高代码审查效率

当基础代码规范问题在提交前就被自动解决后，代码审查者可以更专注于逻辑、架构等更重要的问题，而不是纠结于缩进、分号等格式问题。

3. 怎么使用

3.1 安装

# 安装 huskynpminstallhusky --save-dev# 初始化 huskynpx husky init# 安装 lint-stagednpminstalllint-staged --save-dev

3.2 配置 package.json

{"scripts":{"prepare":"husky install"},"lint-staged":{"*.{js,jsx,ts,tsx}":["eslint --fix","prettier --write"],"*.{css,scss}":["stylelint --fix","prettier --write"]}}

3.3 创建 Git 钩子

# 创建 pre-commit 钩子npx huskyadd.husky/pre-commit"npx lint-staged"

3.4 工作流程

1. 开发者修改代码后执行git add .将文件加入暂存区
2. 执行git commit -m "提交信息"
3. Husky 自动触发 pre-commit 钩子
4. lint-staged 对暂存区的文件运行配置的检查命令
5. 如果所有检查通过，提交成功；如果有问题，提交被阻止

4. 最佳实践

4.1 渐进式引入

对于已有项目，不要一次性启用所有严格的检查规则。可以从最基本的规则开始，逐步增加。就像健身，从轻量级开始，逐渐增加强度。

4.2 只检查暂存文件

lint-staged 的核心优势就是只检查即将提交的文件，而不是整个项目。这大大提高了检查速度，特别是对于大型项目。

4.3 合理的错误处理

配置检查命令时，使用--fix参数让工具自动修复可自动修复的问题。对于无法自动修复的问题，提供清晰的错误信息，帮助开发者快速定位问题。

4.4 与 IDE 集成配合

虽然 Husky + lint-staged 在提交时进行检查，但最好在开发过程中就使用 ESLint、Prettier 等工具的编辑器插件。这样可以在编写代码时就发现问题，而不是等到提交时。

4.5 团队统一配置

将 Husky 和 lint-staged 的配置纳入版本控制，确保团队所有成员使用相同的检查规则。可以通过共享的配置文件或继承共同的规则集来实现。

5. 和同类技术对比

5.1 与纯 Git 钩子对比

原生 Git 钩子：Git 本身支持钩子功能，但需要手动编写脚本，配置相对复杂，且难以在团队中同步配置。

Husky：提供了更简单的配置方式，更好的跨平台支持，并且配置可以轻松纳入版本控制，便于团队共享。

5.2 与持续集成（CI）检查对比

CI 检查：在代码推送到远程仓库后，在 CI 服务器上运行检查。问题是发现问题时，代码已经进入仓库，需要额外的修复提交。

Husky + lint-staged：在代码进入本地仓库前就进行检查和修复，确保提交到远程仓库的代码已经是符合规范的。

两者不是替代关系，而是互补关系。通常建议本地提交前检查 + CI 检查双重保障。

5.3 与 pre-commit 框架对比

pre-commit（Python 生态）：Python 社区流行的类似工具，功能强大，但主要针对 Python 项目。

Husky：专为 Node.js 和前端项目设计，与 npm/yarn 工作流集成更好，配置更符合前端开发者的习惯。

5.4 与其他 Node.js 钩子工具对比

simple-git-hooks：更轻量级的替代方案，但功能相对较少。

lefthook：性能更好，配置更灵活，支持并行执行任务，但学习曲线稍陡。

Husky：目前最流行、社区最活跃、文档最完善的选择，适合大多数项目。

总结对比

Husky 与 lint-staged 的组合在前端开发中已经成为事实上的标准配置。它们像是一道质量防线，在代码进入版本库前自动执行检查，既保证了代码质量，又减少了人工检查的负担。对于团队协作项目，这种自动化检查机制尤为重要，它能有效统一代码风格，提高代码的可维护性。