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的代碼檢查方案就完成了。這種方案不同會在你的項目中運用，可是瞭解其中運用的一些東西能幫助你拓寬下視野，對之後或許有幫助。最後，因本人水平有限，若是上文中出現一些錯誤，請直接指出，勿噴。