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，就大概看了下，鞏固下原來不熟悉的地方，給本身也作個記錄。但願能對有須要的同窗有所幫助。