JavaScript代码检查及与gulp、git的结合使用

在团队开发过程当中，咱们可能会要浪费一些时间在代码检查上，譬如拼写的检查、代码规范的检查。做为码农，咱们固然不能把本身的时间浪费这种无心义的事情上，因此本篇我将介绍一些自动化代码检查的东西和项目实际上的应用。

JSHint

安装及使用

JSHint是一个用于JavaScript代码静态检查的一些开源项目。他是运行与node环境，能够对咱们指定的JavaScript文件进行一些静态的语法分析，譬如：变量定义、拼写检查、代码风格的检查等，并且检查项是灵活可配置的，能够针对不一样项目的要求配置相应的检查项。JSHint使用方式有多种，他能够经过命令行、node_module、集成到IDE这些方式来执行。在IDE中主要是经过插件的形式来使用，你们在本身顺手的IDE上搜JSHint的插件来使用，接下来我主要讲一下在命令行中使用和以node_module结合gulp使用。

咱们能够经过npm安装JSHint。这里须要注意的一些问题，若是咱们全局安装JSHint他是包含了CLI和JavaScript module的，若是是本地安装则只包含JavaScript module。关于node中CLI和JavaScript module分别是怎么用的我后续再填坑，有兴趣的能够本身去了解先。

由于我这里要测试命令行中使用，因此咱们全局安装。而后就能够经过jshint filename来对制定的文件进行检查了。

rem 全局安装
npm i jshint -g

rem 本地安装
npm i jshint

配置

前面咱们已经知道如何对咱们指定的文件进行检查了，可是他检查的规则是什么呢？JSHint会去解析一个.jshintrc文件来肯定如何检查，这个文件是个json格式的配置文件，咱们能够配置一些制定项来定制咱们的检查计划。里面具体的配置选项能够上官网上查找。

{
    "undef": true
}

这里须要注意的是JSHint查找这个.jshintrc文件规则，会有多种状况：咱们能够在咱们命令后加上--config filename来执行读取对应配置文件进行检查。另外，咱们能够在项目中package.json文件的jshintConfig来配置咱们的.jshintrc文件路径。若是上面两种都没有配置的话，则是会按JShint默认的规则来查找配置文件：JSHint会在当前目录查找是否有.jshintrc文件，若是没有找到则向文件夹上一层查找，一直到查到.jshintrc文件或者根目录为止。若是没有指定.jshintrc文件，JSHint是不会对文件就行检查的。

除了上面这种将检查项配置在.jshintrc文件的方式外，咱们还能够直接以注释的形式将咱们的检查配置写在咱们的文件中。以下，若是咱们的文件中有这样的注释，咱们对该文件进行检查就会对未定义的变量进行检查。咱们在代码文件中增长jshint配置并不会终止查找.jshintrc文件读取配置的流程，只是若是代码文件中和.jshintrc有相同的配置时代码文件中的配置会更高。

/* jshint undef: true */

your code

若是咱们在项目中有些文件来自第三方，这些文件不要求尊求咱们的规范，咱们就须要将这些文件排除在咱们的检查列表以外，这时咱们就须要另一个配置文件.jshintignore。这个文件主要用于配置哪些文件不用于JSHint的检查，里面能够放具体的文件名或者文件夹名（该目录下都不被检查）。

node_module
app/test.js

gulp-jshint

在项目中咱们确定不会用命令挨个检查文件是否符合规范，因此咱们一般会配合gulp这类自动化工具来作这些重复的事情。因为gulp是基于“流”的形式来处理的，因此咱们没法直接使用JSHint，咱们须要安转一个gulp-jshint，而后就能够在咱们的gulp任务中加入JSHint的检查了。下面咱们罗列一个简单的使用JSHint检查app路径下全部JS文件的示例代码。

var gulp = require('gulp');
var JSHint = require('gulp-jshint');

gulp.task('checkCode', function(){
    return gulp.src('./app/**/*.js')
    .pipe(JSHint())
    .pipe(JSHint.reporter('default'));
});

JSHint检查的结果是经过命令行输出的，咱们可使用.pipe(JSHint.reporter('default'))来使用默认的样式输出检查结果，为了加强可读性，咱们一般还会使用jshint-stylish来对结果进行美化。

另外提下在某些状况下咱们要检查的js代码可能位于其余类型文件内（如HTML、JSX等），咱们能够经过配置来实现。还有就是自定义一个reporter而不是使用JSHint.reporter。这些均可以经过查找文档来了解具体的操做步骤。

git-hooks

以上咱们就已经实现了使用gulp自动对项目文件进行规范检查，可是咱们不想手动的去执行这个gulp任务，应该手动的话确定就有人会偷懒了。因此咱们考虑能够把checkcode任务集成到编译任务，由于前面都已经用到了gulp了，说明咱们的项目确定是会须要构建才能调试的，因此咱们能够把checkCode任务集成进去。可是这样作有个缺点，咱们的构建任务一般会是一个高频任务，可是checkCode任务确定会是一个耗时的任务，并且项目稳定以后checkCode检查出的问题应该是不多的，因此这样作咱们的时间浪费是不值得的，因此咱们就得考虑把checkCode集成到一个低频的操做中去。这时就是咱们的git-hooks登场了。

一般咱们都会使用svn/git这类工具对咱们的代码进行管理，除了咱们经常使用的那些pull/push功能，咱们还能够利用他们提供的hooks来在特定的操做中加入咱们本身的操做，好比咱们这里将要用到的pre-commithook就能在代码commit以前执行咱们预设的脚本。由于如今比较流行git，因此咱们接下的方案将是基于git来作的。

咱们经过git init或者git clone建立一个git项目时，会在项目顶层目录中生成一个.git文件夹（隐藏的），里面就包含了咱们的一些git的配置信息，咱们要了解的hooks就位于hooks目录下。文件夹内放置了不少hook的模板，不过这些.sample后缀的文件是不能识别的，想让他们执行只要去掉后缀便可。这里的提供的hooks只是客户端的hook，在server端也有一些hook，能够去这里查找所有hook的信息和用法。示例中的hook是用shell写的，可是他是支持Ruby或者Python来写的。

下面我参考之前同事的pre-commit的脚本，具体内容再也不叙述。

#!/bin/sh

#执行gulp任务，并将结果输出到临时文件
gulp checkCode | tee check.log

#检查gulp的check任务是否执行失败
if grep "warning" check.log || grep "error" check.log
then
echo -e "\033[31m Code check fail! Please try again! \033[0m"
exit 1
else
echo -e "\033[32m Code check success! \033[0m"
fi

#删除临时文件
rm check.log

至此，一套结合git-hooks、gulp和JSHint的代码检查方案就完成了。这种方案不同会在你的项目中运用，可是了解其中运用的一些东西能帮助你拓宽下视野，对之后或许有帮助。最后，因本人水平有限，若是上文中出现一些错误，请直接指出，勿喷。