一文帶你了解 ESLint

在平時開發(fā)中，我們總是希望盡可能寫出最佳代碼，但有時總會出錯，然后需要花數(shù)小時定位 bug，最后發(fā)現(xiàn)只是拼寫錯誤，這很令人沮喪。好在一些工具可以幫助我們在輸入過程中檢查代碼的正確性。這些工具無法表明代碼能否實現(xiàn)預(yù)期效果，但可以幫助我們避免語法錯誤。

如果之前使用過 C#這種靜態(tài)語言，那么你應(yīng)該很熟悉 IDE 給出的這種警告信息。 Douglas Crockford 開發(fā)的 JSLint（最初發(fā)布于 2002 年）使得 JavaScript 代碼檢查變得流行起來。后來出現(xiàn)了 JSHint，如今 ESLint 成為了 React 領(lǐng)域的事實標(biāo)準(zhǔn)。 ESLint 是 2013 年發(fā)布的開源項目，由于其配置化程度高且擴(kuò)展性良好，逐漸流行起來。

在 JavaScript 生態(tài)系統(tǒng)中，各種庫和技術(shù)都變化迅速，因此關(guān)鍵是要找到一個可以方便地使用插件來擴(kuò)展的工具，并且可以按需啟用或禁用規(guī)則。最重要的是，如今我們普遍使用 Babel 這樣的轉(zhuǎn)譯器，以及尚未歸入 JavaScript 標(biāo)準(zhǔn)版本的試驗特性，因此需要讓 linter 知道源代碼文件遵循了哪些規(guī)則。

linter 不僅能幫助我們更少犯錯，或者至少更早發(fā)現(xiàn)錯誤，它還能強(qiáng)制推行一些常見的編程風(fēng)格指南。這一點(diǎn)非常重要，尤其是開發(fā)者眾多的大型團(tuán)隊中的每個人都有自己偏愛的編程風(fēng)格。如果以不同風(fēng)格編寫代碼庫中的不同文件，甚至不同函數(shù)，那么這些代碼將難以閱讀。

安裝

首先，執(zhí)行以下命令來安裝 ESLint：

npm install --global eslint 

可執(zhí)行程序安裝完成后，就可以用以下命令來運(yùn)行它：

eslint test.js 

輸出結(jié)果會告訴我們文件中是否有錯。 安裝后首次運(yùn)行不會看到任何報錯，因為它各方面都需要配置，一開始并不包含任何默認(rèn)規(guī)則。

配置

現(xiàn)在我們開始配置 ESLint?？梢允褂梦挥陧椖扛夸浀?.eslintrc 文件來配置 ESLint。

使用 rules 屬性來添加規(guī)則。舉例來說，創(chuàng)建 .eslintrc 文件并禁用分號：

{ 
   "rules": { 
     "semi": [2, "never"] 
   } 
} 

上述配置文件的含義是："semi" 是規(guī)則名，[2, "never"] 是規(guī)則的值。一開始看到這種配置會覺得不夠直觀。 ESLint 規(guī)則具有決定問題嚴(yán)重程度的三個等級。

• off（或者 0）：禁用規(guī)則
• warn（或者 1）：規(guī)則會產(chǎn)生警告
• error（或者 2）：規(guī)則會拋出錯誤

將規(guī)則的值設(shè)為 2，因為我們希望當(dāng)代碼不符合規(guī)則時，ESLint 會拋出錯誤。

第二個參數(shù)將 ESLint 配置為不允許代碼中使用分號（相反值為 always）。 ESLint 及其插件都有詳細(xì)的文檔，你可以找到任意一條規(guī)則的描述及其通過或失敗的示例。 現(xiàn)在新建一個文件并寫入以下代碼。

var foo = 'bar'; 

注意：此處使用了 var 關(guān)鍵詞，因為 ESLint 還不知道我們要用 ES2015 語法來編碼。

執(zhí)行 eslint test.js 后，就會看到以下提示： Extra semicolon (semi)

linter 搭建完畢，它幫助我們遵循了第一條規(guī)則?？梢允謩訂⒂没蚪妹織l規(guī)則，也可以一步啟用推薦配置，只需要在 .eslintrc 中添加以下代 碼即可。

{ 
  "extends": "eslint:recommended" 
}

extends 屬性表明我們將沿用 ESLint 的推薦配置，另外我們也可以手動修改 .eslintrc 的 rules 屬性來覆蓋每條規(guī)則，正如前文所做的那樣。 啟用推薦規(guī)則后，再次運(yùn)行 ESLint，此時不會看到與分號相關(guān)的任何報錯（推薦配置中不包括這個部分），但 linter 會提示聲明過的 foo 變量從未使用。

no-unused-vars 規(guī)則對于保持代碼簡潔非常有用。 一開始提過，我們希望用 ES2015 語法編寫代碼，但是以下代碼會報錯：

const foo = 'bar' 

報錯信息如下所示：

Parsing error: The keyword 'const' is reserved

因此，要想啟用 ES2015 語法，需要添加配置選項：

"parserOptions": { 
  "ecmaVersion": 6, 
}

添加完畢后，就只剩下變量未使用的報錯提示了，這是正常的。最后使用以下配置來啟用 JSX 語法：

"parserOptions": { 
  "ecmaVersion": 6, 
  "ecmaFeatures": { 
    "jsx": true 
  } 
},

如果你之前開發(fā)過 React 應(yīng)用卻從未使用 linter，現(xiàn)在要想學(xué)習(xí)規(guī)則并開始習(xí)慣，那么最好運(yùn)行 ESLint 來檢查源代碼并修復(fù)所有問題。

用 ESLint 幫助我們編寫更好的代碼的方式有很多種。一種是前文的做法：在命令行中運(yùn)行 ESLint，并得到一系列錯誤提示。這種做法可行，但一直手動執(zhí)行不夠方便。更好的做法是在編輯器中加入檢查流程，這樣輸入代碼時就能立刻得到反饋。VS Code、Sublime Text、Atom 以及其他流行的編輯器都提供了 ESLint 插件來實現(xiàn)這個目的。

在真實的開發(fā)場景中，手動運(yùn)行 ESLint 或者讓編輯器實時提供反饋非常有用，但是還不夠，因為我們會遺漏某些錯誤或警告，甚至是直接無視。為了避免代碼庫中出現(xiàn)未檢查的代碼，我們可以將 ESLint 作為開發(fā)流程中的一環(huán)。舉例來說，可以在測試時執(zhí)行檢查，如果代碼不符合檢查規(guī)則，那么整個測試步驟就算失敗。 另一個方案是在發(fā)起 pull request 前進(jìn)行代碼檢查，這樣在同事開始審查前還有機(jī)會整理代碼。

React 插件

前文提過，ESLint 流行起來的主要原因是其可以用插件進(jìn)行擴(kuò)展，對我們最重要一個插件是 eslint-plugin-react。

ESLint 不需要任何插件就能解析 JSX（啟用配置開關(guān)即可），但我們想要更多功能。要想使用該插件，需要先進(jìn)行安裝：

npm install --global eslint-plugin-react 

安裝完成后，在配置文件中添加以下代碼，以便 ESLint 可以使用它：

"plugins": [ 
  "react" 
]

與 ESLint 一樣，沒有配置規(guī)則的情況下它什么都不會做，我們可以啟用推薦配置來激活基礎(chǔ)規(guī)則集。

在 .eslintrc 文件中更新 "extends" 屬性，如下所示：

"extends": [ 
  "eslint:recommended", 
  "plugin:react/recommended" 
],

如果出現(xiàn)編寫錯誤，比如 React 組件的同一個屬性寫了兩次，那么就會出現(xiàn)錯誤提示：

<Foo bar bar /> 

以上代碼會返回如下所示的錯誤提示：

No duplicate props allowed (react/jsx-no-duplicate-props) 

大量規(guī)則可以用于項目。我們來了解其中一部分。例如按照元素的樹結(jié)構(gòu)縮進(jìn) JSX 代碼有助于提升可讀性。 如果代碼庫及組件的縮進(jìn)風(fēng)格不一致，則會出現(xiàn)問題。 我們來查看一個示例，了解一下 ESLint 如何幫助團(tuán)隊的每個成員遵循風(fēng)格指南，而又無須死記硬背。

注意：這種情況下的不正確縮進(jìn)實際上不算錯誤，代碼還是能夠正常運(yùn)行的；這只是一致性問題。

首先，激活以下規(guī)則：

"rules": { 
  "react/jsx-indent": [2, 2] 
} 

第一個 2 表示如果代碼不符合規(guī)則，則 ESLint 應(yīng)該給出錯誤提示，第二個 2 則表示每個 JSX 元素應(yīng)該縮進(jìn)兩個空格。因為 ESLint 不會做任何決定，所以啟用哪條規(guī)則完全取決于你自己。甚至可以通過設(shè)置第二參數(shù)為 0 來選擇無縮進(jìn)風(fēng)格。

編寫以下代碼：

<div> 
<div /> 
</div> 

ESLint 會給出以下報錯信息：

Expected indentation of 2 space characters but found 0 
(react/jsx-indent) 

換行書寫屬性值時也有類似的規(guī)則來約束縮進(jìn)。屬性過多或過長時，較好的做法是換行書寫。要想推行屬性根據(jù)元素名縮進(jìn)兩個空格的格式，啟用以下規(guī)則即可：

"react/jsx-indent-props": [2, 2]

至此，如果屬性沒有縮進(jìn)兩個空格，那么 ESLint 就會報錯。

問題在于，如何界定一行代碼過長？多少個屬性算多？每個開發(fā)人員都有不同的看法。ESLint 的 jsx-max-props-per-line 規(guī)則有助于維護(hù)一致性，這樣每個組件的編寫方式就相同了。

ESLint 的 React 插件提供的規(guī)則不僅有助于寫出更優(yōu)雅的 JSX 代碼，也有助于寫出更好的 React 組件。舉例來說，可以強(qiáng)制要求屬性類型按照字母表順序排列、使用未聲明的屬性時給出錯誤提示，或者要求盡量編寫無狀態(tài)的函數(shù)組件，而不要使用類等。

Airbnb 的配置

我們已經(jīng)了解了 ESLint 如何通過靜態(tài)分析來發(fā)現(xiàn)錯誤，以及如何促使我們在整個代碼庫中遵循一致的風(fēng)格指南。我們也見識到了 ESLint 的靈活之處，以及如何通過配置與插件來擴(kuò)展它。

ESLint 的 extends 屬性非常強(qiáng)大，因此你可以從第三方配置入手，再添加自己特有的規(guī)則。 React 領(lǐng)域最流行的配置之一莫過于 Airbnb 的那一套。Airbnb 的開發(fā)者按照 React 的最佳實踐創(chuàng)建了一套規(guī)則集，你可以直接在代碼庫中使用，無須自己手動判斷啟用哪條規(guī)則。

在使用 eslint --init 后，會出現(xiàn)很多用戶配置項，經(jīng)過一系列一問一答的環(huán)節(jié)后，你會發(fā)現(xiàn)在你文件夾的根目錄生成了一個 .eslintrc.js 文件。其中便可以選擇繼承 Airbnb。

讀者若想了解跟多ESLint，請查看官方文檔：ESLint - 插件化的 JavaScript 代碼檢測工具

到此這篇關(guān)于JavaScript ESLint插件保姆級使用教程的文章就介紹到這了,更多相關(guān)JS ESLint插件內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論