ESLint + lint-staged 禁用老項目中的es6

前言

ESLint作為插件化的javascript代碼檢測工具，為我們的平時的開發保駕護航，好處就不多說了詳情查看官網。

問題

有這么一個五年前開發的老項目，機緣巧合到了我們這邊來維護。
項目是zepto擼起來的，單個文件巨大，只有gulp+公司內部古老的打包工具做了下簡單的打包。
但是問題很嚴重的是，現在es6寫習慣了，在老項目時總會有些地方會忽略掉直接用了es6的語法。
這種未經babel轉譯的代碼，然而在當前的現狀是大部分瀏覽器是可以運行的，
只有以藍綠廠為代表的部分國產手機未支持。測試的時候沒有進行全機型的覆蓋。導致上線后出問題。在這樣的背景下進行了討論，怎么處理這種老項目。

解決方案

解決其實也很簡單，無外乎下面三種

項目遷移

時間充足，迭代頻繁的情況下，首選遷移，不然zepto寫的文件太大太難維護了。基於現狀就pass調這條了。

babel

既然是未轉移的存在問題，轉就完了。

語法檢查

在提交之前，檢測es6語法，確保不存在之后再允許提交。
權衡之下，選擇了語法檢查，順帶復習了下eslint的用法。

安裝

//可以全局安裝
npm i -g eslint
//或者項目本地安裝
npm i -D eslint

安裝之后，進行初始化(當然可以復用已有的.eslintrc.js)：

eslint --init
//非全局安裝  
./node_modules/.bin/eslint --init
//選擇初始化類型 這里就看具體用途了
 How would you like to configure ESLint? (Use arrow keys)
  Use a popular style guide  //已有的流行規范，大家比較推崇的幾種
❯ Answer questions about your style // 回答問題來定制
  Inspect your JavaScript file(s) // 檢查已有js文件來生成 

這里我直接選擇了3，以為會比較友好的直接生成。
后面依次如下：

Which file(s), path(s), or glob(s) should be examined? ./js //待檢測的目錄
? What format do you want your config file to be in? JavaScript //配置文件即eslintrc.js的格式，當然是js嘍
? Which version of ECMAScript do you use? ES5 //當前使用的ES5
? Where will your code run? Browser //瀏覽器
? Do you use CommonJS? Yes //CommonJS規范
? Do you use JSX? No //是否用了jsx，顯然否

結束之后，生成了我們的配置文件：

//太長，只關注我們關心的部分吧
    //環境部分就是自己選擇的
    "env": {
        "browser": true,
        "commonjs": true
    },
    // 擴展配置 eslint:recommended 是核心規則
    "extends": "eslint:recommended",
    // 支持的ECMAScript 規范，默認也是5
    "parserOptions": {
        "ecmaVersion": 5
    },
    // 檢查規則，這里不詳細表述
    "rules": {
        // ***
    }

配置文件生成完成，那么直接干吧。直接執行看看：

// 檢查 文件夾下面的文件
./node_modules/.bin/eslint ./js

然后報了1020個錯誤。。。畢竟是老項目，符合規范也不現實。但是我們的目的好像不像這么大費周章，只想禁用es6罷了。eslint提供了這個選項：直接false掉好了。rules其實我們不需要，因為是老項目，也不想去做這個限制。所以配置文件被我改成了這樣。

    "env": {
        "es6":false
    },
    "parserOptions": {
        "ecmaVersion": 5
    },
    "rules": {
    }

這樣跑起來看還行，只把文件中的es6部分找出來了

但是這樣又有個問題，這個龐大的老項目有文件數目太多。每次都要去檢查js文件夾下的所有文件是有點浪費的。畢竟我們有這個這樣一個前提，這次未改動的認為是符合要求的(畢竟有問題也早被修復了)，應該只關注這次改動部分。這樣想的人多了，就有大牛造出下面的工具了。

lint-staged

在commit之前的檢測會更有意義一些，這樣錯誤代碼就不會提交到倉庫。去檢測所有文件很慢且有的結果是無關緊要的，你更改關心的是本次改動的內容。這就是lint-staged的用處。
安裝及使用：

//切記lint-staged 和 husky要全部安裝
npm install --D lint-staged husky

husky 可以阻止壞的commit, push and more。方便我們操作git hooks。
可以這樣使用：

{
  //自己手動hook  
  "scripts": {
   "precommit": "npm test"
  },
  //使用husky
 "husky": {
   "hooks": {
     "pre-commit": "npm test"
   }
 }
}

這里就提一下不要忘記安裝這個工具，不然你會發現lint-staged配置完成之后沒有起作用(我不想說我是怎么知道的。。。)，更多請移步github主頁
用法也很簡單，在我們的package中增加下配置就好

"scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "*.js": [
      "eslint",
      "git add"
    ]
  }

這樣，就是只檢測本次commit中的js文件了。

那么結合lint-staged，我們可以配下我們的package.json

"scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "*.js": [
      "eslint",
      "git add"
    ]
  }

結束

到這里，老項目禁止es6就完成了。簡單測試下，覆蓋還可以，起碼常用的方法可以檢測到。正好用到eslint+lint-staged，就大概看了下，鞏固下原來不熟悉的地方，給自己也做個記錄。希望能對有需要的同學有所幫助。