ESLint v4.0.0 升級指南

前言

今日早讀文章由 愛回收網@ 吃土小 2 叉翻譯授權分享。

正文從這開始～

ESLint v4.0.0 是 ESLint 的第 4 個主版本。當然，我們希望大多數變更隻影響極少數用戶。本文旨在幫助您了解具體有哪些更改。

以下列表大致按每個更改可能影響的用戶數量進行排序，排序越靠前影響的用戶數越多。

ESLint 使用者請注意

eslint:recommended 新增規則

indent 規則將更嚴格

現在配置文件中未識別的屬性會報告嚴重錯誤

忽略文件將從 .eslintignore 文件所在目錄開始解析

默認情況下 padded-blocks 規則將更嚴格

默認情況下 space-before-function-paren 規則將更嚴格

默認情況下 no-multi-spaces 規則將更嚴格

現在必須包含命名空間，才能引用限定在命名空間下的插件

ESLint 插件開發者和自定義規則開發者請注意

現在 RuleTester 將驗證測試用例對象的屬性

AST 節點不再具有注釋屬性

在 AST 遍歷期間不會觸發 LineComment 和 BlockComments 事件

現在 Shebang 可以通過注釋 API 返回

集成開發者請注意

linter.verify() API 不再支持 global 屬性

現在更多報告消息具有完整的位置範圍

部分暴露的 API 將使用 ES2015 中的類

eslint:recommended 新增規則

eslint:recommended 中新增了兩條規則：

no-compare-neg-zero 不允許與 -0 進行比較

no-useless-escape 不允許在字元串和正則表達式中使用無意義的換行符

注: 如果要與 ESLint 3.x 的 eslint:recommended 保持一致，您可以在配置文件中禁用上述規則：

{

"extends":"eslint:recommended",

"rules":{

"no-compare-neg-zero":"off",

"no-useless-escape":"off"

}

}

indent 規則將更嚴格

過去的 indent 規則在檢查縮進方面是相當寬容的：過去的縮進校驗規則會忽略許多代碼模式。而這會讓用戶產生困擾，因為他們偶爾會有不正確的代碼縮進，並且他們本期望 ESLint 能夠發現這些問題（譯者補充：然而並沒有發現）。

在 ESLint v4.0.0 中，indent 規則被重寫。新版規則將報告出舊版規則無法發現的縮進錯誤。另外，MemberExpression 節點、函數聲明參數以及函數調用參數將默認進行縮進檢查（過去為了向後兼容，這些默認都被忽略了）。

為了方便升級到 ESLint 4.0.0，我們引入了 indent-legacy 規則作為 ESLint 3.x 中 indent 規則的快照。如果你在升級過程中遇到了 indent 規則的相關問題，那麼您可以藉助於 indent-legacy 規則來維持與 3.x 一致。然而，indent-legacy 規則已被棄用並且在將來不再維護，所以您最終還是應該使用 indent 規則。

註： 推薦在升級過程中不要更改 indent 配置，並修正新的縮進錯誤。然而如果要與 ESLint 3.x 的 indent 規則保持一致，您可以這樣配置：

{

rules:{

indent:"off",

"indent-legacy":"error"// 用之前的 `indent` 配置替換此處

}

}

現在配置文件中未識別的屬性會報告嚴重錯誤

在創建配置文件時，用戶有時候會犯拼寫錯誤或者弄錯配置文件的結構。在以前，ESLint 並不會驗證配置文件中的屬性，因此很難調試配置文件中的拼寫錯誤。而從 ESLint v4.0.0 起，當配置文件中存在未識別的屬性或者屬性類型有錯誤時，ESLint 會拋出一個錯誤。

註： 升級後如果發現配置文件驗證出錯，請檢查配置文件中是否存在拼寫錯誤。如果使用了未識別的屬性，那麼應該將之從配置文件中移除，從而使 ESLint 恢復正常。

忽略文件將從 .eslintignore 文件所在目錄開始解析

過去由於一個 bug，.eslintignore 文件的路徑名模板是從進程的當前工作目錄解析，而不是 .eslintignore 文件的位置。從 ESLint 4.0 開始，.eslintignore 文件的路徑名模板將從 .eslintignore 文件的位置解析。

註： 如果您使用 .eslintignore 文件，並且您經常從項目根目錄以外的地方運行 ESLint，則可能會以不同的模式匹配路徑名。您應該更新 .eslintignore 文件中的匹配模式，以確保它們與該文件相關，而不是與工作目錄相關。

默認情況下 padded-blocks 規則將更嚴格

現在默認情況下， padded-blocks 規則要求在類內填充空行以及在 switch 語句中填充空行。而過去除非用戶更改配置，否則默認情況下這條規則會忽略上述情況的檢查。

註： 如果此更改導致代碼庫中出現更多的錯誤，您應該修復它們或重新配置規則。

默認情況下 space-before-function-paren 規則將更嚴格

現在默認情況下， space-before-function-paren 規則要求非同步箭頭函數的圓括弧與 async 關鍵詞之間存在空格。而過去除非用戶更改配置，否則默認情況下這條規則會忽略對非同步箭頭函數的檢查。

註： 如果要與 ESLint 3.x 的默認配置保持一致，您可以這樣配置：

{

"rules":{

"space-before-function-paren":["error",{

"anonymous":"always",

"named":"always",

"asyncArrow":"ignore"

}]

}

}

默認情況下 no-multi-spaces 規則將更嚴格

現在默認情況下， no-multi-spaces 規則禁止行章節附註釋前存在多個空格。而過去這條規則不對此進行檢查。

註： 如果要與 ESLint 3.x 的默認配置保持一致，您可以這樣配置：

{

"rules":{

"no-multi-spaces":["error",{"ignoreEOLComments":true}]

}

}

現在必須包含命名空間，才能引用限定在命名空間下的插件

在 ESLint 3.x 中存在一個 bug：引用限定在命名空間下的插件可能會忽略該命名空間。舉個例子，在 ESLint 3.x 中以下配置是合法的：

{

"plugins":[

"@my-organization/foo"

],

"rules":{

"foo/some-rule":"error"

}

}

換句話說，過去可以引用限定命名空間的插件的規則（例如 foo/some-rule），同時無需明確聲明 @my-organization 的命名空間。這是一個 bug，因為如果同時載入了一個名為 eslint-plugin-foo 的不限定命名空間的插件，可能會導致引用規則時產生歧義。

為了避免歧義，在 ESLint 4.0 中必須包含命名空間，才能引用限定在命名空間下的插件。

{

"plugins":[

"@my-organization/foo"

],

"rules":{

"@my-organization/foo/some-rule":"error"

}

}

註： 如果您在配置文件中引用了限定在命名空間下的插件，那麼請確保在引用的時候包含命名空間。

現在 RuleTester 將驗證測試用例對象的屬性

從 ESLint 4.0 開始，RuleTester 工具將驗證測試用例對象的屬性，如果遇到未知屬性，將拋出錯誤。這番改動是因為我們發現開發人員在測試規則時的拼寫錯誤是比較常見的，且通常會使測試用例試圖作出的斷言無效。

註： 如果您對自定義規則的測試用例對象具有額外的屬性，則應該移除這些屬性。

AST 節點不再具有注釋屬性

在 ESLint 4.0 之前，ESLint 需要解析器實現附加註釋的解析，這個過程中，AST 節點將從源文件的前後置注釋中獲取額外的相關聯屬性。這就使得用戶很難去開發自定義解析器，因為他們不得不去重複解析那些令人困惑同時又是 ESlint 必需的附加註釋語義。

在 ESLint 4.0 中，我們已經擺脫了附加註釋的概念，並將所有的注釋處理邏輯轉移到了 ESLint 本身。這樣可以更容易地開發自定義解析器，但這也意味著 AST 節點將不再具有 leadingComments 和 trailingComments 屬性。 從概念上來說，規則作者現在可以在 tokens 上下文而不是 AST 節點的上下文中考慮注釋。

註： 如果您有一個依賴於 AST 節點的 leadingComments 或 trailingComments 屬性的自定義規則，則可以分別使用 sourceCode.getCommentsBefore() 和 sourceCode.getCommentsAfter() 替代。

此外，sourceCode 對象現在也有 sourceCode.getCommentsInside() 方法（它返回一個節點內的所有注釋），sourceCode.getAllComments() 方法（它返迴文件中的所有注釋），並允許注釋通過各種其他 token 迭代器方法（例如 getTokenBefore() 和 getTokenAfter()）並設置選項 進行訪問。

對於想要同時兼容 ESLint v3.0 和 v4.0 的規則作者，現在已經不推薦使用的 sourceCode.getComments() 仍然可用，並且這兩個版本都兼容。

最後請注意，以下 SourceCode 方法已被棄用，將在以後的 ESLint 版本中被移除：

getComments() - 請使用 getCommentsBefore()、getCommentsAfter() 和 getCommentsInside() 來替換

getTokenOrCommentBefore() - 請使用 getTokenBefore() 方法並設置選項 來替換

getTokenOrCommentAfter() - 請使用 getTokenAfter() 方法並設置選項 來替換

在 AST 遍歷期間不會觸發 LineComment 和 BlockComments 事件

從 ESLint 4.0 開始，在 AST 遍歷期間不會觸發 LineComment 和 BlockComments 事件。原因如下：

過去這種行為依賴於在解析器級別的注釋附屬物，而自 ESLint 4.0 開始不再如此，以確保所有注釋將被考慮

在 tokens 上下文中考慮注釋更容易預測和更容易理解，而非在 AST 節點上下文中考慮注釋 token

註： 規則現在可以使用sourceCode.getAllComments() 來獲取文件中的所有注釋，而非依賴於 LineComment 和 BlockComment。要檢查特定類型的所有注釋，規則可以使用以下模式：

sourceCode.getAllComments().filter(comment=>comment.type==="Line");

sourceCode.getAllComments().filter(comment=>comment.type==="Block");

現在 Shebang 可以通過注釋 API 返回

（譯者註：Shebang 是一個由井號和嘆號構成的字元序列 #!，其出現在文本文件的第一行的前兩個字元。參考：Shebang_(Unix)）

在 ESLint 4.0 之前，源文件中的 shebang 注釋不會出現在 sourceCode.getAllComments() 或 sourceCode.getComments() 的輸出中，但它們將作為行注釋出現在 sourceCode.getTokenOrCommentBefore 的輸出中。這種不一致會給規則開發者帶來困惑。

在 ESLint 4.0 中，shebang 注釋被視為 Shebang 類型的注釋 tokens，並可以通過任何返回注釋的 SourceCode 方法返回。該變化的目的是為了讓 shebang 的評論更符合其他 tokens 的處理方式。

註： 如果您有一個自定義規則對注釋執行操作，可能需要一些額外的邏輯來確保 shebang 注釋被正確處理或被正常過濾掉：

sourceCode.getAllComments().filter(comment=>comment.type!=="Shebang");

linter.verify() API 不再支持 global 屬性

過去，linter.verify() API 接受 global 屬性作為一個配置項，它與官方文檔中的 globals 作用相同。但是，global 屬性從未出現在官方文檔中或者被官方支持，並且在配置文件中該屬性會失效。自 ESLint 4.0 起，該屬性已被移除。

註： 如果您先前使用了 global 屬性，請用 globals 屬性替換，其作用與 global 相同。

現在更多報告消息具有完整的位置範圍

從 ESLint 3.1.0 開始，除了開始位置之外，規則還可以通過調用 report 時明確指定一個結束位置來指定問題報告的結束位置。這對於編輯器集成這樣的工具很有用，可以使用範圍來精確顯示出現問題的位置。從 ESLint 4.0 開始，如果報告了節點而不是一個具體位置，則該結束位置的範圍將自動從節點的結束位置推斷出來。因此，更多報告的問題將會有結束位置。

這不會帶來兼容性問題。然而，這可能會導致比以前更大的報告位置範圍。例如，如果一條規則報告的是 AST 的根節點，則問題的範圍將是整個程序。在某些集成中，這可能導致用戶體驗不佳（例如，如果整個程序都被高亮顯示以指示錯誤）。

註： 如果您有處理報告問題範圍的集成，請確保以對用戶友好的方式處理大型報告範圍。

部分暴露的 API 將使用 ES2015 中的類

現在部分 ESLint 的 Node.js API，比如 CLIEngine、SourceCode 以及 RuleTester 模塊使用了 ES2015 中的類。當然這不會影響到介面的正常使用，不過這的確會產生一些明顯的影響（舉個例子，CLIEngine.prototype 將不可枚舉）。

註： 如果您需要對 ESLint 的 Node.js API 提供的方法進行枚舉遍歷，可以用諸如 Object.getOwnPropertyNames 的函數來訪問不可枚舉屬性。（譯者註：可參考 MDN 文檔：屬性的可枚舉性和所有權）

最後，有興趣來參與下

關於本文

原文地址：http://eslint.org/docs/user-guide/migrating-to-4.0.0

原文作者：ESLint

譯者：@吃土小2叉

校對者：@薛定諤的貓、@sqrthree

譯文：https://github.com/xitu/gold-miner/blob/master/TODO/eslint-migrating-to-4.0.0.md(掘金翻譯計劃)

最後，插播一條視頻直播消息

不管是年中職業評審，還是剛走出象牙塔的學生黨們，下面這條新聞可以看看。

三位資深前端大咖，教你做好前端工程師職業規劃。

小爝，芋頭，Jasin Yip是分別來自國美，大搜車，美團的三位資深前端開發工程師，本次live會對大家分享如下主題：

前端工程師的職業現狀和前景是什麼？

前端工程師的專業能力差距究竟在哪？

不同背景的前端工程師應該如何自我定位？

前端如何少走彎路，找到最適合自己的學習路徑？

我會為職場晉陞做些什麼？晉陞評審最看重什麼能力？

前端大牛們都是如何做自己的職業規劃的？

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！