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.