当前位置: 首页 > 工具软件 > Husky > 使用案例 >

husky 检查commit

督建柏
2023-12-01

1 . Package.json 安装以下插件

"@commitlint/cli": "^17.4.4",
"@commitlint/config-conventional": "^17.4.4", 
"core-js": "^3.6.4", 
"custom-event-polyfill": "^1.0.7", 
"fetch-polyfill": "^0.8.2", 
"husky": "^8.0.3", 
"lint-staged": "^13.1.2", 
"prettier": "^1.14.3", 
  • @commitlint/cli 和 @commitlint/config-conventional:这是一组工具,用于管理git提交信息,确保遵守一致的提交风格和规则。
  • core-js:这是一个JavaScript函数库,提供了ECMAScript 5、6和7的最新实现,用于支持现代浏览器和旧浏览器的兼容性。
  • custom-event-polyfill:这是一个用于兼容不支持浏览器内置CustomEvent构造函数的polyfill,可以在不支持CustomEvent的浏览器上使用自定义事件。
  • fetch-polyfill:这是一个polyfill,用于兼容不支持Fetch API的浏览器,用于在浏览器端进行网络请求。
  • husky:这是一个用于 git hook 的工具,可以在每次提交之前运行指定的脚本或命令,以确保代码符合特定的规范。
  • lint-staged:这是一个用于在提交之前对指定文件进行代码检查的工具,可以有效地检查和修正代码,以确保质量。
  • prettier:这是一个用于格式化代码的工具,可以确保代码的一致性和可读性,确保代码遵循良好的编码规范。

在scripts里新增脚本

 "prepare": "husky install"

在scripts同级下新增

 "lint-staged": {
    "*.{js,vue}": [
      "prettier --write",
      "eslint --fix"
    ]
  },
  • lint-staged 配置文件指定了哪些文件需要进行处理,以及针对这些文件的处理方式。
  • 在这个例子中,它指定了*.{js,vue}文件需要被处理,处理方式是先使用prettier进行格式化,然后再使用eslint来修复可能出现的错误。

2. 在根目录创建commitlint.config.js文件

module.exports = {
  extends: ['@commitlint/config-conventional'],
  headerCorrespondence: ['type', 'scope', 'subject'],
  rules: {
    'type-enum':  [ 2, 'always',
     	 ['feat', 'fix', 'perf', 'chore', 'doc', 'style', 'refactor', 'test']
    ],
    'scope-enum': [ 2,  'always',
     	 ['ci', 'build', 'common', 'view', 'model']
    ],
    'type-case': [0],
    'type-empty': [0],
    'scope-empty': [2, 'never'],
    'scope-case': [0],
    'subject-full-stop': [0],
    'subject-case': [0, 'never'],
    'header-max-length': [0, 'always', 72]
  }
};
  • extends: [‘@commitlint/config-conventional’]
    * 扩展规范,使用的规范是conventional规范
  • headerCorrespondence: [‘type’, ‘scope’, ‘subject’]
    * 设置提交头的对应关系,表示提交头分别由类型、范围和主题组成
  • rules: {
    * 设置规则
  • ‘type-enum’: [ 2, ‘always’, [‘feat’, ‘fix’, ‘perf’, ‘chore’, ‘doc’, ‘style’, ‘refactor’, ‘test’] ],
    * 设置类型枚举,表示只能使用feat, fix, perf, chore, doc, style, refactor, test这八种类型
  • ‘scope-enum’: [ 2, ‘always’, [‘ci’, ‘build’, ‘common’] ],
    * 设置范围枚举,表示只能使用ci, build, common这几种范围
  • ‘type-case’: [0]
    * 设置类型的大小写,0表示不强制限制大小写
  • ‘type-empty’: [0]
    * 设置类型是否可以为空,0表示可以为空
  • ‘scope-empty’: [2, ‘never’],
    * 设置范围是否可以为空,2表示不可以为空
  • ‘scope-case’: [0],
    * 设置范围的大小写,0表示不强制限制大小写
  • ‘subject-full-stop’: [0],
    * 设置主题是否以句号结尾,0表示不必以句号结尾
  • ‘subject-case’: [0, ‘never’],
    * 设置主题的大小写,0表示不强制限制大小写
  • ‘header-max-length’: [0, ‘always’, 72]
    * 设置提交头的最大长度,0表示不强制限制长度,72表示最大长度为72

3. 在根目录新建.husky文件夹

文件目录为:

  • .husky
    • _
      • husky.sh
    • commit-msg
    • pre-commit

husky.sh

#!/usr/bin/env sh
if [ -z "$husky_skip_init" ]; then
  debug () {
    if [ "$HUSKY_DEBUG" = "1" ]; then
      echo "husky (debug) - $1"
    fi
  }

  readonly hook_name="$(basename -- "$0")"
  debug "starting $hook_name..."

  if [ "$HUSKY" = "0" ]; then
    debug "HUSKY env variable is set to 0, skipping hook"
    exit 0
  fi

  if [ -f ~/.huskyrc ]; then
    debug "sourcing ~/.huskyrc"
    . ~/.huskyrc
  fi

  readonly husky_skip_init=1
  export husky_skip_init
  sh -e "$0" "$@"
  exitCode="$?"

  if [ $exitCode != 0 ]; then
    echo "husky - $hook_name hook exited with code $exitCode (error)"
  fi

  if [ $exitCode = 127 ]; then
    echo "husky - command not found in PATH=$PATH"
  fi

  exit $exitCode
fi
  • #!/usr/bin/env sh:
    * 这一行是一个Shebang,它指定脚本文件的解释器。这里指定的解释器是/usr/bin/env,这是一个特殊的可执行文件,它会从环境变量中查找指定的解释器,并将其作为参数传递给/usr/bin/env。
  • if [ -z “$husky_skip_init” ]:
    * 这一行检查环境变量husky_skip_init是否为空,如果为空,则执行if内的代码,否则跳过if语句。
  • debug():
    * 这一行定义一个调试函数,该函数将根据HUSKY_DEBUG环境变量的值来决定是否打印调试信息。
  • readonly hook_name=“$(basename – “$0”)”:
    * 这一行获取脚本的名称并将其存储在hook_name变量中。
  • debug “starting $hook_name…”:
    * 这一行使用调试函数打印脚本开始运行的信息。
  • if [ “$HUSKY” = “0” ]; then:
    * 这一行检查HUSKY环境变量是否为0,如果是,则跳过Hook,否则继续执行。
  • if [ -f ~/.huskyrc ]; then:
    * 这一行检查~/.huskyrc文件是否存在,如果存在,则导入该文件。
  • readonly husky_skip_init=1:
    * 这一行将husky_skip_init环境变量设置为1,以便在稍后重新运行脚本时可以跳过if语句。
  • sh -e “ 0 " " 0" " 0""@”:
    * 这一行使用sh命令重新运行脚本,并将接收到的参数传递给命令。
  • exitCode=“$?”:
    * 这一行将上一条命令的退出码存储在变量exitCode中。
  • if [ $exitCode != 0 ]; then:
    * 这一行检查exitCode变量是否不等于0,如果不等于0,则打印错误信息。
  • if [ $exitCode = 127 ]; then:
    * 这一行检查exitCode变量是否等于127,如果等于127,则打印PATH变量的值。
  • exit $exitCode:
    * 最后,这一行退出脚本,并使用exitCode变量的值作为退出码。

commit-msg

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

npx --no-install commitlint -e "$1"
  • #!/usr/bin/env sh
    * 这一行是将脚本运行交给操作系统的内置shell,这里是sh。
  • . “$(dirname “$0”)/_/husky.sh”
    * 这一行是将husky.sh文件的内容加入到当前的脚本中,husky.sh文件中有一些环境变量设置。
  • npx --no-install commitlint -e “$1”
    * 这一行是使用npx运行commitlint,并使用参数“-e”指定要检查的文件或文件夹。“$1”表示传入

pre-commit

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

npx --no-install lint-staged
  • npx --no-install lint-staged
    * 这行语句使用NPM中的npx工具来运行lint-staged工具,不需要全局安装。

项目根目录跑一下

chmod ug+x .husky/*

chmod是一个用于修改文件权限的命令
u代表所有者的权限
g代表组的权限
o代表其他人的权限
+x表示添加可执行权限

commit 模板

feat(common): 提交具体信息
 类似资料: