项目中使用了Husky格式化代码和验证Commit信息

大家好，我是前端西瓜哥。今天我们学习使用husky工具在commit时做一些样式校验，包括commit信息格式化和文件格式化。githook和huskygithook允许我们在git执行某些操作之前和之后执行一些脚本。例如，pre-commit可以在我们真正提交commit之前执行一段代码。如果这段代码报错（exit1），则提交将被取消；如果正常执行，就会真正提交commit。或者commit-msg，也可以获取真正commit前的commit信息，做一些检查工作。利用githook的能力，我们可以在commit之前做一些样式检查或者格式化，比如ESLint、Prettier、commit格式等。githook是项目.git/hooks目录下的一个sh脚本。这就有个尴尬的问题：.git下的文件不会被git提交。哈士奇是解决这个问题的方法。其实在git2.9之后，我们可以配置git的core.hookspath，将hook目录指定为对应项目下的目录，理论上是不能用husky的。但是husky还是有一层封装，可以更好的操作hook，比如通过命令行快速生成hook，并设置为可执行。Husky4及更早版本使用.huskyrc进行配置。当时设计有一些问题，就是没有配置的hook也会触发hook执行。于是在husky4中进行了破坏性的修改，使用方法改为直接在.husky目录下添加一个hook脚本。husky安装激活不涵盖husky4及之前版本的使用，因为已经过时了。首先是安装：yarnadd-Dhusky#或者使用npmnpminstallhusky--save-dev然后执行husky命令行工具启用githook：npxhuskyinstall这个命令会创建一个.husky目录。.husky└──_├──.gitignore└──husky.sh同时该命令还将git所在项目本地环境的core.hookspath设置为.husky。所以，这个.husky目录是我们放置githook脚本的地方。我们执行如下命令，可以看到当前git项目的本地配置为：core.hookspath=.husky。gitconfig--local--list其他同事拉项目的时候，可能会忘记执行上面的命令开启githook。但是有一个命令他们肯定会执行，就是执行npminstall或者yarn安装依赖。所以我们需要使用npmscript的生命周期脚本，加上一个prepare。准备将在安装后执行。//package.json{"scripts":{//..."prepare":"huskyinstall"}}这将确保在新同事拉取项目并安装依赖项后启用husky。createhooknpxhuskyadd.husky/pre-commit"npmtest"这个命令会在.husky下为你创建一个pre-commit脚本，填写npmtest内容，方便我们在commit前通过测试用例。此脚本自动设置为可执行文件。如果您手动创建它，则需要使用chmodu+xpre-commit命令手动将文件设置为可执行文件。否则钩子脚本不会被执行。创建的脚本内容为：#!/usr/bin/envsh。"$(dirname--"$0")/_/husky.sh"npmtest会在真正commit之前执行npmtest，报错commit会停止。实战：使用commitlint校验commit信息格式我们希望在提交commit的时候能够校验commit信息，如果不正确则不允许提交。这可以防止开发人员提交混乱、难以理解或不一致的信息。在这种情况下，需要commit-msg钩子。我们首先创建一个没有内容的commit-msg。npxhuskyadd.husky/commit-msg""在commit-msg脚本中，我们可以通过$1获取commit信息。$1指向.git/COMMIT_EDITMSG文件，里面保存着上次提交的提交信息。我们可以拿到commit信息，然后可以对其做一些验证工作，比如检查是否符合feat:xxx的格式。这里有个问题，就是我们需要声明一些规范，自己实现代码。好吧，我们去找轮子，找到轮子了，就是commitlint。commitlint是一个可以验证commit的命令行工具，并且提供了官方的验证规则，也支持自己配置规则。首先安装commitlint：yarnadd-D@commitlint/cli@commitlint/config-conventional然后创建一个commitlint.config.js配置文件并添加内容，使用@commitlint/config-conventional。module.exports={extends:["@commitlint/config-conventional"],};@commitlint/config-conventional是一个经典的提交规范，我们需要使用诸如feat:addutil.js或fix:fix文本格式错误，具体见文档：https://www.conventionalcommits.org/en/v1.0.0/。然后我们在commit-msghook上添加：npx--no--commitlint--edit$1npx--no:表示只使用本地项目node_modules下的脚本，找不到时尝试下载。下载需要时间，因此要取消，您需要确保已下载命令行工具。commitment--edit：执行commit命令行工具，使用--edit选项从文件中提取commit内容进行验证。验证规则由上面提到的commitlint.config.js配置文件指定。配置好后，我们来测试一下，先提交非标准commit：在开头添加commit类别类型，然后提交，成功：实战：使用lint-staged格式化要存入的文件暂存区lint-staged是一个命令行工具，可以使用linter工具对git的暂存区（stagingarea）中的文件进行格式化，修复一些样式问题，重新添加到暂存区。一个经典的组合是在提交前用husky的pre-commithook格式化文件。预提交在实际提交之前触发，使用lint-staged，可以进行一些样式更正。使用lint-staged强制提交文件格式化适用场景：部分团队成员使用的编辑器没有或者没有安装格式化插件，代码保存后无法自动格式化，容易提交错误的代码风格;项目开发了一段，是时候引入代码风格规范了，希望能稍微指正一下。如果一次性全部格式化，可能会有很多样式需要手动修复；让我们开始配置吧。首先我们安装lint-staged:yarnadd-Dlint-staged然后添加一个pre-commithook，内容是npxlint-staged:npxhuskyadd.husky/pre-commit"npxlint-staged"因为有so提交的文件类型很多，比如js、md、less、mdx等。所以我们还需要配置它，对不同类型的文件使用不同的linters。lint-commit的配置可以放在package.json中，也可以放在专门的配置文件中。我选择后者，在项目根目录下创建.lintstagegedrc.js文件，添加如下内容：module.exports={"src/**/*.{js,jsx,ts,tsx}":"eslint--使固定”，};这里的意思是在src目录下指定js、jsx、ts、tsx后缀的文件，使用eslint进行格式化。我只用eslint格式化js和ts，其他忽略。你可以考虑使用prettier来格式化它们。这里有一个Github可以参考，地址是：https://github.com/F-star/xigua-ui。最后，husky是一个非常有用的工具。可以在本地提交时使用githook，用eslint等linter工具格式化文件，配合commitlint校验提交信息格式。它是工程统一代码风格的绝佳工具。