eslint 遷移 v6 指南 翻譯

前言

ESLint v6.0.0是ESLint的主要版本，此版本中作了一些重大更改。

下面的列表大體按每一個更改預計會影響的用戶數量排序，其中第一個項目預計會影響大多數用戶

對用戶來講的重大變化

1. 再也不支持Node.js 6
2. eslint:recommended 已更新
3. 插件和可共享配置再也不受ESLint位置的影響
4. 默認解析器如今更嚴格地驗證選項
5. 默認狀況下，no-redeclare 規則如今更加嚴格
6. 默認狀況下，comma-dangle 規則如今更加嚴格
7. 默認狀況下，no-confusing-arrow 規則如今更寬鬆
8. 配置文件中的重寫 如今能夠匹配dotfiles
9. 如今，父配置文件能夠重寫 擴展配置文件中的重寫規則
10. 如今驗證全局變量的配置值
11. 已棄用的experimentalObjectRestSpread選項已被刪除
12. 使用unicode 解析 規則選項 中用戶提供的正則表達式

對自定義插件的開發人員的重大變化

1. 插件做者可能須要更新安裝說明
2. RuleTester 如今驗證規則列表 中的無效默認關鍵字
3. RuleTester如今須要 parser 選項的絕對路徑
4. 已刪除eslintExplicitGlobalComment範圍分析屬性

####對集成開發者的 重大變化

1. 插件和可共享配置再也不受ESLint位置的影響
2. Linter再也不嘗試從文件系統加載丟失的解析器

變化詳述

1. 再也不支持Node.js 6

截至2019年4月，Node.js 6將在EOL，將再也不接收安全更新。所以，咱們決定在ESLint v6中放棄對它的支持。咱們如今支持如下版本的Node.js：

• Node.js 8 (8.10.0 and above)
• Node.js 10 (10.13.0 and above)
• Anything above Node.js 11.10.1

使用ESLint v6時，請確保至少升級到Node.js 8。若是您沒法升級，咱們建議您繼續使用ESLint v5.x，直到您可以升級Node.js.

2. eslint:recommended 已更新

如下規則已添加到eslint：recommended config：

• no-async-promise-executor不容許使用異步函數做爲Promise構造函數的參數，這一般是一個bug。
• no-misleading-character-class報告正則表達式中可能沒法按預期運行的字符類。
• no-prototype-builtins定義方法調用，如foo.hasOwnProperty（「bar」）（這是bug的常見來源），並建議將它們替換爲Object.prototype.hasOwnProperty.call（foo，「bar」）。
• no-shadow-restricted-names 不容許使用未定義的陰影變量（例如使用let undefined = 5等代碼），由於它可能會使讀者感到困惑.
• no-useless-catch 報告catch子句是多餘的，能夠從代碼中刪除而不改變其行爲.
• no-with禁止使用with語句，這會使代碼難以理解並致使兼容性問題。
• require-atomic-updates報告在異步函數中從新分配變量時可能發生的競爭條件錯誤

此外，如下規則已從eslint:recommended中刪除

• no-console 不容許調用console.log之類的函數。雖然此規則在許多狀況下頗有用（例如，爲了不無心中將調試語句留在生產代碼中），但它並不像eslint:recommended中的其餘規則那樣普遍適用，而且在console.log的狀況下它是誤報的來源是能夠接受的（例如在CLI應用程序中）

最後，在ESLint v5 eslint中：eslint:recommended將明確禁用全部未被視爲「recommended」的核心規則。若是eslint：recommended在另外一個配置以後被加載，這可能會致使使人困惑，由於eslint：recommended會產生關閉某些規則的效果。在ESLint v6中，eslint：recommended對非推薦規則沒有影響。

要模仿eslint：5.x中推薦的行爲，您能夠在配置文件中顯式禁用/啓用規則，以下所示：

{
  "extends": "eslint:recommended",

  "rules": {
    "no-async-promise-executor": "off",
    "no-misleading-character-class": "off",
    "no-prototype-builtins": "off",
    "no-shadow-restricted-names": "off",
    "no-useless-catch": "off",
    "no-with": "off",
    "require-atomic-updates": "off",
    "no-console": "error"
         }
    }
複製代碼

在極少數狀況下（若是您依賴之前eslint:recommended禁用核心規則），您可能須要禁用這些規則來恢復之前的行爲。

3. 插件和可共享配置再也不受ESLint位置的影響

之前，ESLint相對於ESLint包自己的位置加載了插件。所以，咱們建議使用全局ESLint安裝的用戶也應該全局安裝插件，而使用本地ESLint安裝的用戶應該在本地安裝插件。可是，因爲設計錯誤，此策略致使ESLint在某些狀況下隨機沒法加載插件和可共享配置，尤爲是在使用lerna和Yarn Plug n'Play等包管理工具時。

據經驗：使用ESLint v6，即便全局安裝了ESLint，也應始終在本地安裝插件。更確切地說，ESLint v6默認解析相對於最終用戶項目的插件，而且老是相對於導入它們的配置文件的位置解析可共享配置和解析器。

若是您使用ESLint的全局安裝（例如，使用npm install eslint --global安裝）以及插件，則應在運行ESLint的項目中本地安裝這些插件。若是您的配置文件擴展了可共享的配置和/或解析器，則應確保將這些包安裝爲包含配置文件的項目的依賴項。

若是您使用位於本地項目以外的配置文件（帶有--config標誌），請考慮將插件安裝爲該配置文件的依賴項，並將--resolve-plugins-relative-to標誌設置爲配置文件的location。

4. 默認解析器如今更嚴格地驗證選項

espree是ESLint使用的默認解析器，如今會在如下狀況下引起錯誤：

• ecmaVersion解析器選項設置爲數字之外的其餘選項，例如字符串「2015」。 （之前，會忽略非數字選項。）
• The sourceType: "module" parser option is set while ecmaVersion is set to 5 or left unspecified. (Previously, setting sourceType: "module" would implicitly cause ecmaVersion to be set to a minimum of 2015, which could be surprising.)
• sourceType設置爲「script」或「module」之外的任何內容。
• 若是您的配置將ecmaVersion設置爲數字之外的其餘內容，則能夠經過刪除ecmaVersion來恢復之前的行爲。 （可是，您可能須要仔細檢查您的配置是否實際按預期工做。）若是您的配置設置了parserOptions：{sourceType：「module」}而沒有設置parserOptions.ecmaVersion，則應添加parserOptions：{ecmaVersion：2015}恢復之前的行爲。

5. 默認狀況下，no-redeclare 規則如今更加嚴格

no-redeclare規則的默認選項已從{builtinGlobals：false}更改成{builtinGlobals：true}。此外，no-redeclare規則如今將報告由/ * global foo * /等註釋啓用的全局變量的錯誤，若是這些全局變量已經經過配置啓用了。

要恢復規則的先前選項，能夠按以下方式進行配置：

{
      "rules": {
         "no-redeclare": ["error", { "builtinGlobals": false }]
               }
      }
複製代碼

此外，若是您在代碼中看到全局註釋的新錯誤，則應刪除這些註釋。

6. 默認狀況下，comma-dangle 規則如今更加嚴格

之前，除非顯式配置爲檢查函數逗號，不然逗號懸掛規則將忽略尾隨函數參數和參數。在ESLint v6中，函數逗號的處理方式與其餘類型的尾隨逗號相同。

You can restore the previous default behavior of the rule with:

{
  "rules": {
    "comma-dangle": ["error", {
        "arrays": "never",
        "objects": "never",
        "imports": "never",
        "exports": "never",
        "functions": "ignore"
                }]
            }
      }
複製代碼

要恢復字符串選項的先前行爲，例如「always-multiline」，請在上面的示例中將「never」替換爲「always-multiline」

7. 默認狀況下，no-confusing-arrow 規則如今更寬鬆

no-confusing-arrow規則的默認選項已從{allowParens：false}更改成{allowParens：true}。 You can restore the previous default behavior of the rule with:

{
      "rules": {
         "no-confusing-arrow": ["error", { "allowParens": false }]
                }
      }
複製代碼

8. 配置文件中的重寫 如今能夠匹配dotfiles

• Due to a bug, the glob patterns in a files list in an overrides section of a config file would never match dotfiles, making it impossible to have overrides apply to files starting with a dot. This bug has been fixed in ESLint v6.
• If you don’t want dotfiles to be matched by an override, consider adding something like excludedFiles: [".*"] to that overrides section. See the documentation for more details.

9. 如今，父配置文件能夠重寫 擴展配置文件中的重寫規則

因爲存在錯誤，之前的狀況是，可共享配置中的覆蓋塊優先於父配置的頂級。例如，使用如下配置設置，即便在最終用戶的配置中明確禁用了the semi rule，也會最終啓用the semi rule：

// .eslintrc.js
      module.exports = {
         extends: ["foo"],
         rules: {
            semi: "off"
               }
         };

      // eslint-config-foo/index.js
      module.exports = {
         overrides: {
            files: ["*.js"],
            rules: {
               semi: "error"
            }
         }
     };
複製代碼

• In ESLint v6.0.0, a parent config always has precedence over extended configs, even with overrides blocks.
• 咱們預計此問題的影響很是低，由於大多數可共享配置不使用overrides 塊。可是，若是您使用帶有overrides 塊的可共享配置，則因爲在配置中明確指定但在此以前處於非活動狀態的某些內容，您可能會遇到行爲更改。若是您但願從可共享配置繼承行爲，只需從您本身的配置中刪除相應的條目。 （在上面的示例中，能夠經過從.eslintrc.js中刪除semi：「off」來恢復先前的行爲。）

10. 如今驗證全局變量的配置值

之前，在使用對象配置一組全局變量時，可使用任何內容做爲對象的值。未知值將被視爲「可寫」。

// .eslintrc.js
   module.exports = {
   globals: {
      foo: "readonly",
      bar: "writable",
      baz: "hello!" // ???
     }
   };
複製代碼

經過此更改，globals對象中的任何未知值都會致使配置驗證錯誤。 若是您在更新後看到與全局變量相關的配置驗證錯誤，請確保爲全局變量配置的全部值都是readonly，writeable或off。 （ESLint還接受一些替代拼寫和變體的兼容性。）

11. 已棄用的experimentalObjectRestSpread選項已被刪除

之前，在使用默認解析器時，配置可使用experimentalObjectRestSpread選項來啓用對象rest / spread屬性的解析支持：

{
   "parserOptions": {
      "ecmaFeatures": {
         "experimentalObjectRestSpread": true
      }
       }
   }
複製代碼

從ESLint v5開始，ecmaFeatures：{experimentalObjectRestSpread：true}已經等同於ecmaVersion：2018，而且還發出了棄用警告。在ESLint v6中，experimentalObjectRestSpread功能已徹底刪除且無效。若是您的配置依賴於experimentalObjectRestSpread來啓用ES2018解析，您可能會開始看到解析最近語法的錯誤。

若是您使用experimentalObjectRestSpread選項，則應更改配置以包含此選項

{
   "parserOptions": {
      "ecmaVersion": 2018
      }
   }
複製代碼

12. 使用unicode 解析 規則選項 中用戶提供的正則表達式

max-len之類的規則接受一個字符串選項，該選項被解釋爲正則表達式。在ESLint v6.0.0中，這些正則表達式使用unicode標誌進行解釋，當匹配像星體符號這樣的字符時，它應該表現出更合理的行爲。 Unicode正則表達式還比非unicode正則表達式更嚴格地驗證轉義序列。

若是升級後出現規則選項驗證錯誤，請確保規則選項中的任何正則表達式都沒有無效的轉義序列。

13. 插件做者可能須要更新安裝說明

若是您維護插件並提供安裝說明，則應確保安裝說明是最新的，其中包含有關插件加載方式的用戶更改。特別是，若是您的插件是使用generator-eslint包生成的，那麼它可能包含有關如何將插件與全局ESLint安裝一塊兒使用的過期說明。

14. RuleTester如今驗證規則模式中的無效默認關鍵字

某些狀況下，規則架構可使用default關鍵字自動指定規則選項的默認值。可是，default關鍵字僅在某些架構位置有效，並在其餘位置被忽略，若是規則錯誤地預期將默認值做爲規則選項提供，則會產生錯誤風險。可是，default關鍵字僅在某些架構位置有效，並在其餘位置被忽略，若是規則錯誤地預期將默認值做爲規則選項提供，則會產生錯誤風險。 若是RuleTester開始報告有關無效默認值的錯誤，則能夠刪除規則架構中指定位置的默認屬性，而且該規則的行爲方式相同。 （若是發生這種狀況，您可能還但願在該位置未提供選項值時驗證規則是否正常運行。）。

15. RuleTester如今須要 parser 選項的絕對路徑

To use custom parsers in tests, we could use parser property with a package name or file path. However, if a package name was given, it’s unclear where the tester should load the parser package from because the tester doesn’t know which files are running the tester. In ESLint v6.0.0, RuleTester disallows parser property with a package name. 若是在測試用例中使用包名稱的parser屬性，請使用require.resolve（）函數更新它，以將包名稱解析爲包的絕對路徑。

16. 已刪除eslintExplicitGlobalComment範圍分析屬性

Previously, ESLint would add an eslintExplicitGlobalComment property to Variable objects in scope analysis to indicate that a variable was introduced as a result of a /* global / comment. This property was undocumented, and the ESLint team was unable to find any usage of the property outside of ESLint core. The property has been removed in ESLint v6, and replaced with the eslintExplicitGlobalComments property, which can contain a list of all / global */ comments if a variable was declared with more than one of them. If you maintain a rule that uses the eslintExplicitGlobalComment property, update it to use the eslintExplicitGlobalComments property as a list instead.

17. Linter再也不嘗試從文件系統加載丟失的解析器

Previously, when linting code with a parser that had not been previously defined, the Linter API would attempt to load the parser from the filesystem. However, this behavior was confusing because Linter never access the filesystem in any other cases, and it was difficult to ensure that the correct parser would be found when loading the parser from the filesystem. In ESLint v6, Linter will no longer perform any filesystem operations, including loading parsers. If you’re using Linter with a custom parser, use Linter#defineParser to explicitly define the parser before linting any code.