ESLint + lint-staged 禁用老專案中的es6

瀟湘待雨發表於2019-02-27
EsLint

前言

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部分找出來了
ESLint + lint-staged 禁用老專案中的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，就大概看了下，鞏固下原來不熟悉的地方，給自己也做個記錄。希望能對有需要的同學有所幫助。

相關文章