基于 git hooks 的前端代码质量控制解决方案

原文看这里：https://github.com/kuitos/kui...
所有文章看这里 https://github.com/kuitos/kui...

国际惯例先说下故事背景

一般状况下，若是咱们是一个对代码质量有要求或者存在code review这一流程的团队，咱们必然会有一套团队内部达成共识的code style从而提升项目的可维护性及代码的可读性。而确保提交到代码仓库的代码是符合规范的手段一般是，代码提交前由工具帮忙指出，如早期的jslint、jshint以及如今的eslint。提交后code review阶段由其余同窗确保代码没有其余规范及质量问题。

目前这种方式的症结点

1. 整个流程全靠团队成员自觉遵照。也就是说，即便咱们在coding以前已经有一份code style放在那，并且eslint(jslint、jshint)工具已经配置好，依然有可能存在漏看了(或者根本没看。。)工具的提示信息、忘记了部分规范要求而直接把代码提交的状况。

2. code review阶段reviewer常常要指出一些纯代码风格上的问题价值过低。由于上一条中出现的状况，reviewer还得花一些时间去指出纯代码风格上的问题，这种事情价值过低并且每每会让reviewer感到有心无力若是ta恰好仍是个强迫症患者的话?。

3. 总之纯靠人肉去确保代码规范是一件价值很低并且很靠不住的事情。

解决思路

既然人肉靠不住那咱们只能让整个流程自动化让工具替咱们完成代码规范检查的事情。我能想到的大概有这几种方式。

1. 配置代码质量工具每次代码提交以前跑一下，而后针对工具给出的信息调整。

2. 配置代码质量工具reviewer每次review以前跑一下，检查有没有基本的规范问题。

3. 依靠CI(持续集成工具)对每次提交的代码作code check，每次接收push以前跑一下code check，若是没有经过直接拒绝接收push。

一、2两种方式都是经过工具方式下降了人肉检查代码规范的工做量，不过本质仍是人肉。。
3方式再也不人肉了可是依赖外部系统去作会存在风险及成本，好比哪天CI工具由bamboo切到了jenkins 而后又切到travis。。

直到有一天在下在fork了github上的一个项目并对其作了必定改造而后自信满满地准备提交代码的时候(json-mock-server)，git一直在报错代码始终push不上去，报错信息也看不出什么东西，不行只能请教了对git比较内行的同事@arzyu，猜想是git hooks上配置了什么钩子脚本(后来证明是单元测试没覆盖到位)，尝试把项目路径下的.git文件夹删除以后，终于能正常提交了?

这件事给了我一个新的思路，就是咱们能不能基于git的hook功能来作这这种自动化的事情呢？恰好在下又会一点点shell?

因此理想的方式是

咱们在git hooks里配置各类预处理脚本，好比代码检查或者跑单元测试之类的事情，若是咱们的代码没有经过代码检查或者测试用例覆盖率不够，咱们的push甚至commit会直接被拒绝。

好东西啊这不就是我这种极端分子想要的么哈哈！

怎么作

首先介绍一下git hooks是什么吧

钩子(hooks)是一些在"$GIT-DIR/hooks"目录的脚本, 在被特定的事件(certain points)触发后被调用。当"git init"命令被调用后, 一些很是有用的示例钩子文件(hooks)被拷到新仓库的hooks目录中; 可是在默认状况下这些钩子(hooks)是不生效的。 把这些钩子文件(hooks)的".sample"文件名后缀去掉就可使它们生效了。

也就是在咱们的git仓库下会有一个.git配置文件夹，它里面包含git操做相关的一系列 预处理／后处理 脚本。如 pre-commit、post-push之类的。

在一番google研究以后发现这事情操做起来并无想象中那么简单，好比咱们在什么时机将本身的脚本插入到hooks里，让使用者手动调命令这种主动式的方式一直不是我推崇的(要把调用者想象成懒癌晚期)，而后处理脚本怎么写写哪里也没想到合适方式，一度放弃。

后来忽然想起，以前那个开源项目是怎么作的？它是怎么把预处理脚本偷偷摸摸插入到hooks里的？？因而突发奇想去研究别人的项目。

结果发现做者本身写了一个插件husky，专门用来处理这种git提交时的自动化处理。

大体用法像这样：

// 根目录package.json
"scripts": {
    "codecheck": "NODE_ENV=test eslint src/**/*.js",
    "test": "BABEL_JEST_STAGE=0 jest --verbose --watch",
    "precommit": "npm run codecheck && npm test"
}

配置了precommit以后每次代码提交以前git都会自动去跑代码检查及单元测试任务，都跑经过以后才能提交成功。更多用法请看项目主页husky

插件实现的机制大体是，在你install该插件时，它会自动往git hooks里埋入不少相应的钩子脚本(git hook能识别的)，这些钩子函数会去读区package.json中的配置信息，当用户作某些git操做触发相应钩子时会天然去调用配置好的任务，从而实现咱们的自动化需求，包括代码检查跟单元测试验证以及更多的自动化任务。

拓展思考

基于npm对install动做的钩子接口，咱们能够提供一个插件，当使用者install该插件时插件会帮助用户作一系列初始化构建工做。开发时各业务模块独立仓库开发，上线或测试时提供构建插件一行install命令把全部业务模块组合起来变成一个完整的项目。具体打包、发布的方式后面会写一篇关于前端工程化的blog来介绍。