前言
嗨，前端小伙伴们！今天我要和你们聊一聊前端团队的规范问题。在一个团队合作的开发环境中，我们经常会遇到代码格式不一致、提交信息混乱等问题，这不仅让我们的工作效率下降，也影响了代码的可读性和可维护性。
但别担心，解决这些问题的方法就在我们眼前！我将为大家介绍几个前端规范工具，包括 husky、lint-staged 和 commitlint。这些工具可以帮助我们自动化代码规范检查、格式化和提交信息验证，让团队开发更加顺畅和高效。
本文将会分享规范工具的简介、相关配置和搭建步骤。如果你想提升团队的协作效率，减少不必要的错误和冲突，那么就继续往下看看吧！
huksy
简介
简单来说，husky是一个Git钩子（hook）工具，它能够在Git版本控制的不同阶段触发自定义的脚本。这意味着我们可以在代码提交、推送等操作前后执行特定的命令或脚本。
使用husky，我们可以轻松地在团队项目中定义一致的代码规范和行为。例如，在每次提交代码之前，我们可以运行代码格式化工具来确保代码风格的一致性；或者在提交信息中添加校验，以确保提交信息的格式正确且符合规范。
安装及使用
安装 husky
npm install husky -D
初始化 husky
npx husky-init
这将在你的项目中初始化 husky，它会创建一个 .husky 文件夹，并在其中添加一些初始配置文件。
与此同时，会在 package.json 的 scripts 添加一条命令：
"scripts": {
"prepare": "husky install"
},
prepare 脚本是 npm 的特殊脚本之一，它在安装包之前执行。
husky install 是 husky 提供的一个命令，它的作用是安装 husky 的 Git 钩子。通过在 prepare 脚本中添加 husky install，在每次执行 npm install 或 yarn install 时，会自动安装 husky 的 Git 钩子。
这样做的好处是，无需手动执行 husky install 命令来安装 Git 钩子，它会在每次安装依赖时自动进行。
因此，当你执行 npx husky-init 初始化 husky 后，无需再执行 npm install 或 yarn 命令。prepare 脚本会在安装依赖时自动安装 husky 的 Git 钩子。
配置 husky 钩子
在你的项目根目录中的 .husky 文件夹下，你会找到一个名为 pre-commit.sh 的文件。
在 pre-commit 文件中，你可以定义想要在提交代码之前执行的脚本或命令。例如，你可以添加以下内容来在每次提交前运行 lint 检查：
package.json:
{
"scripts": {
"lint": "eslint --ext .js,.vue"
}
}
.husky/pre-commit.sh:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
echo "husky pre-commit" && npm run lint
这样在你提交代码之前，会先输出 husky pre-commit，并执行 lint 命令。当 lint 检查有语法错误时，会阻止代码提交并抛出错误，开发者可以根据错误进行修改，再重新提交。
常见钩子
以下是一些常见的 Husky 钩子以及它们的作用：
-
pre-commit：在提交代码之前执行的钩子。可以用于运行代码格式化、代码质量检查、单元测试等操作，以确保提交的代码符合规范。 -
commit-msg：在提交信息（Commit Message）被创建之后、实际执行提交之前执行的钩子。可以用于对提交信息进行验证、校验和规范，以确保提交信息的格式正确且符合规范。 -
pre-push：在推送代码之前执行的钩子。可以用于运行集成测试、端到端测试等操作，以确保即将推送的代码通过了所有的测试。 -
prepare-commit-msg：在提交信息被编辑之后、实际执行提交之前执行的钩子。可以用于自动化地修改或添加提交信息，如添加一个统一的前缀或后缀。 -
post-merge：在代码合并（merge）之后执行的钩子。可以用于运行安装依赖、构建项目或其他必要的后续操作。 -
post-checkout：在切换分支（checkout）之后执行的钩子。可以用于执行特定分支下的必要任务，如安装依赖、清理缓存等。 -
post-rewrite：在使用 Git 命令改写提交历史（如使用 git commit --amend）之后执行的钩子。可以用于对改写后的提交进行必要的操作和验证。
当你想新增钩子时可以使用命令：
npx husky add .husky/commit-msg "npm test"
相关文档
lint-staged
简介
lint-staged 的主要功能是在 Git 暂存区中检查被修改的文件，只对这些文件进行 lint 操作，从而提高 lint 检查的效率。通常，我们并不需要对整个项目进行 lint 检查，而是希望只针对即将提交的代码进行检查，以避免不必要的耗时。
通过将 lint-staged 配置为 husky 的 pre-commit 钩子的一部分，可以在每次提交代码之前自动触发 lint-staged，对即将提交的文件进行 lint 检查。如果有任何 lint 错误或不符合规范的代码，lint-staged 将阻止提交，给出相应的错误信息，帮助开发者及时发现和解决问题。
安装及使用
安装 lint-staged
npm i lint-staged -D
配置 lint-staged
package.json 新增配置:
{
"lint-staged": {
"src/**/*.{js,vue}": [
"npm run lint"
]
}
}
在上述示例中，我们定义了 lint-staged 规则，分别对应匹配 .js、.vue 后缀的文件。实际路径根据自己的项目进行配置。
使用 lint-staged
.husky/pre-commit.sh:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
echo "husky pre-commit" && npx lint-staged
在 husky 的配置中，根据你选择的钩子修改 .husky 文件夹中相应的文件，以加载并触发 lint-staged。
commitlint
简介
commitlint 是一个用于规范化提交消息的工具，它能够帮助团队在项目中统一和规范提交信息的格式和内容。通过使用 commitlint，你可以确保提交消息遵循预定义的规则，提高代码提交的可读性和一致性。
commitlint 的工作原理是通过对提交消息进行校验来确保其符合指定的格式和规范。它依赖于一个配置文件，其中包含了规则和校验器，用于定义提交消息的格式、类型、作用域等。
使用 commitlint，你可以制定一套规则，例如使用特定的提交类型（如 feat、fix、docs、chore 等），指定提交消息的格式（如标题和正文的长度限制、大小写要求等），并设置自定义的规则以满足团队的需求。
安装及使用
安装 commitlint
npm install @commitlint/cli @commitlint/config-conventional -D
在上述命令中，我们安装了 @commitlint/cli，它是 commitlint 的核心工具，用于执行提交消息的规范校验。同时，我们还安装了 @commitlint/config-conventional，它是一个常用的规则配置，遵循了约定式提交规范（Conventional Commits）。
配置 commitlint
commitlint.config.js:
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2, 'always', [
'feat', // 新增功能
'update', // 更新功能
'ui', // 样式改动
'fix', // 修复功能bug
'merge', // 合并分支
'refactor', // 重构功能
'perf', // 性能优化
'revert', // 回退提交
'style', // 不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等)
'build', // 修改项目构建工具(例如 glup，webpack，rollup 的配置等)的提交
'docs', // 文档新增、改动
'test', // 增加测试、修改测试
'chore' // 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
]],
'scope-empty': [0],
// 'scope-empty': [2, 'never'], 作用域不为空
'scope-case': [0],
'subject-full-stop': [0],
'subject-case': [0]
}
}
上述配置文件使用了 @commitlint/config-conventional 的默认配置，该配置约定了常用的提交类型（如 feat、fix、docs、chore 等），并定义了提交消息的格式要求。
你可以根据需要进行自定义配置，例如修改提交消息的格式、添加额外的规则等。
使用 commitlint
commit-msg.sh:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
echo "husky commit-msg" && npx --no-install commitlint --edit $1
在 commit-msg 钩子内执行 npx --no-install commitlint --edit $1 的作用是调用 commitlint 来对提交消息进行校验并编辑。
具体作用如下：
--no-install参数告诉npx命令不要自动安装 commitlint，而是使用当前项目中已安装的 commitlint。commitlint是执行实际的 commitlint 命令，用于校验提交消息的规范性。--edit参数告诉 commitlint 打开文本编辑器，以便你可以在编辑器中查看和编辑提交消息。$1是 commit-msg 钩子的参数，将提交消息作为参数传递给 commitlint 进行校验。
综合起来，npx --no-install commitlint --edit $1 的目的是在 commit-msg 钩子中调用 commitlint，通过打开文本编辑器编辑提交消息，从而实现对提交消息的规范校验。这样，你可以在编辑器中查看和修改提交消息，确保其符合预定义的规范要求。
提交规范
type(scope?): subject
body?
footer?
type 和 subject 是必填项，type 为提交的类型，subject 为提交的主题内容。type 的枚举值必须包含在 commitlint 配置文件中 type-enum。
测试提交消息校验
现在，你可以进行测试来验证 husky 和 commitlint 的配置是否正常工作。
尝试使用不符合规范的提交消息进行提交，例如：
git commit -m "add new feature"
如果提交消息不符合 commitlint 的规则，将会收到相应的错误提示信息:
尝试使用符合规范的提交消息进行提交，例如：
git commit -m "feat: add new feature"
如果提交消息符合 commitlint 的规则，将会成功提交代码。
相关文档
依赖包版本
package.json:
"devDependencies": {
"@commitlint/cli": "^17.6.5",
"@commitlint/config-conventional": "^17.6.5",
"husky": "^8.0.0",
"lint-staged": "^13.2.2"
}
对于 node 版本要求尽量升级到稳定版本，我在使用这套配置时，node 版本在 v14.18.3。
总结
本文安装和配置了 lint-staged，并将其与 husky 配合使用。在每次提交前，lint-staged 会自动运行指定的 lint 命令，并对修改过的文件进行检查。还配置了 commitlint，每次进行代码提交时，husky 会自动触发 commitlint 进行提交消息的规范校验，帮助你保持提交消息的一致性和可读性。这样，团队成员可以更好地理解每个提交的意图和变更，提高协作和代码管理的效率。
以上这套配置适用基础常用场景，在团队内稳定运行了一段时间，可以放心食用。有个性化的要求，可以按照团队习惯配置。
