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配置完成之後沒有起作用(我不想說我是怎麼知道的。。。)，更多請移步 ofollow,noindex">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，就大概看了下，鞏固下原來不熟悉的地方，給自己也做個記錄。希望能對有需要的同學有所幫助。