在團隊協作中，為避免低級 Bug、產出風格統一的代碼，會預先制定編碼規範。使用 Lint 工具和代碼風格檢測工具，則可以輔助編碼規範執行，有效控制代碼質量。 在以前的項目中，我們選擇 JSHint 和 JSCS 結合使用，WebStorm 等開發環境已經支持這些工具，使用起來很順手。然而，最近使用 ...
原文地址：https://csspod.com/getting-started-with-eslint/?utm_source=tuicool&utm_medium=referral
在團隊協作中，為避免低級 Bug、產出風格統一的代碼，會預先制定編碼規範。使用 Lint 工具和代碼風格檢測工具，則可以輔助編碼規範執行，有效控制代碼質量。
在以前的項目中，我們選擇 JSHint 和 JSCS 結合使用，WebStorm 等開發環境已經支持這些工具，使用起來很順手。然而，最近使用 React JSX 語法時，卻遇到了問題：JSHint 不支持 JSX 語法。雖然有 JSXHint 這樣的 JSHint 衍生工具，但個人並不喜歡這樣的實現方式：不是以插件的形式實現，而是重新重新包裝了一個工具。Nicholas C. Zakas 也不喜歡，所以有了 ESLint。
原來選擇 JSHint 的時候，也對比過 ESLint，基於 ESLint 在速度上比 JSHint 要慢一些，最終使用了 JSHint。現在需要 JSX 支持了，才發現 ESLint 的設計理念更符合實際需求。
ESLint 簡介
ESLint 由 JavaScript 紅寶書 作者 Nicholas C. Zakas 編寫， 2013 年發佈第一個版本。 NCZ 的初衷不是重覆造一個輪子，而是在實際需求得不到 JSHint 團隊響應 的情況下做出的選擇：以可擴展、每條規則獨立、不內置編碼風格為理念編寫一個 lint 工具。
ESLint 主要有以下特點：
- 預設規則包含所有 JSLint、JSHint 中存在的規則，易遷移；
- 規則可配置性高：可設置「警告」、「錯誤」兩個 error 等級，或者直接禁用；
- 包含代碼風格檢測的規則（可以丟掉 JSCS 了）；
- 支持插件擴展、自定義規則。
ESLint 已經宣佈支持 JSX，不過目前為 alpha 版本，正式版發佈之前可以先使用 eslint-plugin-react 替代。
Update 2016.04.22： ESLint 從 0.12.0 開始已經支持 JSX。 2016.04.14，JSCS 宣佈合併至 ESLint。 2016.04.19，ESLint 宣佈加入 jQuery 基金會。 無疑，無論現狀，亦或前景，ESLint 都會是首選的 JavaScript 代碼質量控制工具。
使用 ESLint
ESLint 詳盡使用參見官方文檔，下麵羅列的是由 JSHint 遷移到 ESLint 的一些要點。
配置
可以通過以下三種方式配置 ESLint:
- 使用
.eslintrc文件（支持 JSON 和 YAML 兩種語法）； - 在
package.json中添加eslintConfig配置塊； - 直接在代碼文件中定義。
.eslintrc 文件示例：
{ "env": { "browser": true, }, "parserOptions": { "ecmaVersion": 6, "ecmaFeatures": { "jsx": true } }, "globals": { "angular": true, }, "rules": { "camelcase": 2, "curly": 2, "brace-style": [2, "1tbs"], "quotes": [2, "single"], "semi": [2, "always"], "space-in-brackets": [2, "never"], "space-infix-ops": 2, } }
.eslintrc 放在項目根目錄，則會應用到整個項目；如果子目錄中也包含 .eslintrc 文件，則子目錄會忽略根目錄的配置文件，應用該目錄中的配置文件。這樣可以方便地對不同環境的代碼應用不同的規則。
package.json 示例：
{ "name": "mypackage", "version": "0.0.1", "eslintConfig": { "env": { "browser": true, "node": true } } }
文件內配置
代碼文件內配置的規則會覆蓋配置文件里的規則。
禁用 ESLint：
/* eslint-disable */ var obj = { key: 'value', }; // I don't care about IE8 /* eslint-enable */
禁用一條規則：
/*eslint-disable no-alert */ alert('doing awful things'); /* eslint-enable no-alert */
調整規則：
/* eslint no-comma-dangle:1 */ // Make this just a warning, not an error var obj = { key: 'value', }
工作流集成
ESLint 可以集成到主流的編輯器和構建工具中，以便我們在編寫的代碼的同時進行 lint。
編輯器集成
以 WebStorm 為例，只要全局安裝 ESLint 或者在項目中依賴中添加 ESLint ，然後在設置里開啟 ESLint 即可。其他編輯可以從官方文檔中獲得獲得具體信息。
構建系統集成
在 Gulp 中使用：
var gulp = require('gulp'); var eslint = require('gulp-eslint'); gulp.task('lint', function() { return gulp.src('client/app/**/*.js') .pipe(eslint()) .pipe(eslint.format()); });
其他構建工具參考官方文檔。
代碼風格檢測
在團隊協作中，統一的代碼風格更具可讀性、可維護性。ESLint 內置了一系列有關代碼風格的規則，可以根據團隊的編碼規範設置。
自定義規則
顯然，ESLint 內置的規則不可能包羅所有需求。可以通過插件實現自定義規則，這是 ESLint 最有賣點的功能。在 NPM 上以 eslintplugin 為關鍵詞，可以搜索到很多插件，包括 eslint-plugin-react。如果有自行開發插件的需求，可以閱讀 ESLint 插件開發文檔。
以 eslint-plugin-react 為例，安裝以後，需要在 ESLint 配置中開啟插件，其中 eslint-plugin- 首碼可以省略：
{ "plugins": [ "react" ] }
接下來開啟 ESLint JSX 支持（ESLint 內置選項）：
{ "ecmaFeatures": { "jsx": true } }
然後就可以配置插件提供的規則了：
{ "rules": { "react/display-name": 1, "react/jsx-boolean-value": 1 } }
自定義規則都是以插件名稱為命名空間的。
結語
至此，ESLint 使用入門就介紹完了。但是，我們不應該僅僅是使用 ESLint 這個工具，更應該學習 ESLint 背後的設計理念：不求大而全，但求搭好扎實的基礎架構，提供良好的、可擴展的 API。小到插件，大到應用程式開發，這一原則都適用。
由此，很容易讓我聯想到 WordPress —— 不用修變源代碼，通過 hook、filter 機制實現前臺、後臺所有功能的定製、擴展，其成功離不開這一特性。
Coding 之外，《羅輯思維》所倡導的「U 盤化生存」（自帶信息，不裝系統，隨時插拔，自由協作）不也是這樣一種理念嗎？不是我不明白，這世界變化快。經驗固然有用，但在日新月異的技術潮流中，學習、適應能力更為重要。
