Eslint配置文件详解eslint 一般只做check syntax and find problems; enfor

eslint 一般只做check syntax and find problems; enforce code style 一般交给pritter来做。

Eslint核心概念

Rules eslint的核心构建块（the core building block of ESLint）验证你的代码是否满足特定格式，以及不满足时的特定行为（error,warning）,rules配置还可以传递参数。
eslint包含数百个built-in rules；你也可以自定义rules or 使用其他plugins 提供的rules
具体实例详见semi.

semi: ["error", "never", { "beforeStatementContinuationChars": "never"}]

详情：semi

Shareable Configurations

Eslint configurations that are shared via npm
shareable configurations通常是用built-in rules来强制代码格式。
具体实例eslint-config-airbnb-base是使用Airbnb的代码风格。
直接在configuration文件中填写在extends字段下就可以了。

Configuration Files

使用方式两种：

Cascading and Hierarchy
eslint -c myconfig.json myfiletotest.js 使用--config 指定configuration位置。

Congiguration File Formats

javascipt .eslintrc.js导出一个commonjs的对象
javascript(esm) 使用 .eslintrc.cjs,在package.json中指定 type: "module"时使用
JSON .eslintrc.json 允许使用 JavaScript-style comments
packages.json pagckage.json 中的eslintConfig属性。
NOTICE：有多个configuration files在同一个文件夹时，eslint只使用一个，有限顺序如下
.eslintrc.js >.eslintrc.cjs>.eslintrc.yaml>.eslintrc.yml>.eslintrc.json>package.json

Cascading and Hierarchy

.eslintrc 跟被linted的文件在同一个文件夹，则此configuration优先，然后沿着父文件夹查找.eslitrc,直到查找到root directory or 某一个.eslintrc中root: true. 子文件的.eslintrc 的属性会覆盖父文件中.eslintrc的相同属性。
为什么要这么搞？你可能想让你的所有项目有相同的代码风格；但是有时clone下来的其他项目有不同的代码风格，此时可以使用root:true限制eslit的作用范围。
configuration hierarchy优先级： Inline configuration > Command line options > Project-level configuration
Inline configuration：在 JavaScript 文件的任何位置指定配置。可以使用 /* eslint */ 注释来内联配置。只需在注释中提供配置选项即可。例如：

// Some code
define(['require', 'exports'], function(require, exports) {
    /* eslint no-alert: "error" */
    // More code
});

Adding Shared Settings

ESLint 插件可以使用 settings 属性来定义插件的全局配置，可以用于跨文件共享配置。在插件开发中，有时需要在插件的多个规则之间共享同一配置，或者是插件需要使用到的全局变量等信息。这些信息可以通过 settings 属性传递给插件，在插件的规则中进行使用。

例如，假设有一个 ESLint 插件用于检查源代码中的 API 调用，而这些 API 都需要附加一个访问令牌（access token）。为了不在每个规则中重复指定 access token，可以将其定义为一个 settings 属性，并在规则中引用此属性。示例代码如下：

module.exports = {
  rules: {
    'api-call': {
      create: function(context) {
        // 获取 access token 配置
        const accessToken = context.settings && context.settings.accessToken;
        return {
          // 在规则中使用 access token
          CallExpression: function(node) {
            if (isAPI(node)) {
              if (!hasToken(node, accessToken)) {
                context.report(node, 'Missing access token');
              }
            }
          }
        };
      }
    }
  },
  // 定义访问令牌配置
  settings: {
    accessToken: 'myAccessToken'
  }
};

在上面的示例中，插件定义了一个 api-call 规则，规则中定义了一个创建方法，该方法可以接受一个 context 参数，该参数包含了插件执行的上下文信息。在方法中，首先通过 context.settings 获取到插件的配置信息，然后在规则中使用此信息对源代码进行检查。

extending

使用extends,可以继承另一个配置文件的所有特点，包括 rules、plugins、language options并修改所有的options.所以有三种configurations
Base config: 被extended的配置
Derived config:使用extends引入其他config的文件。
Resulting actual config：最终合并Derived and Base config的配置。
Notice: extends 中相对路径和shareable config names 是相对此配置文件的。
"extends": "eslint:recommended",是rules page中列举的规则生效，这些规则是common problems。
"extends": "eslint:all" 当前版本的eslint的core rules 都生效。不太推荐，因为不同版本的eslint的core rules 会有不同。

Using a configuration from a plugin

plugin: an npm package可以添加各种扩展。一个插件可以完成多种功能，包括但不限于rules、exporting sharebale configurations.

{
    "plugins": [
        "react"
    ],
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ],
    "rules": {
       "react/no-set-state": "off"
    }
}

Configuration Based on Glob Patterns

为了细粒度的控制lint,我们可以使用overrides属性，只在匹配成功的时候overrides配置的rules才起作用。

{
  "rules": {
    "quotes": ["error", "double"]
  },

  "overrides": [
    {
      "files": ["bin/*.js", "lib/*.js"],
      "excludedFiles": "*.test.js",
      "rules": {
        "quotes": ["error", "single"]
      }
    }
  ]
}

文件匹配patterns，如 lib/*.js是相对配置文件的。
Glob pattern 优先级高于正常配置，多个overrides按需应用到文件上，最后一个overrides优先级最高。
glob configuration 配置属性基本都可以使用到glob configuration.处理 root、ignorePatterns
glob config 可以使用extends,but the root proptery in the extended configs is ignored.ignorePatterns proprety in the extended configs is used only for the files the blog matched.
NOTICE: 使用 --config 指定configuration file, overrides 的 blob 是相对命令的运行位置，而不是配置文件的位置

如果你在命令行中指定了目录（例如，`eslint lib`），ESLint 将在目录中搜索要检测的目标文件。目标文件是 `*.js` 或与任何 `overrides` 条目匹配的文件（但不包括以 `*` 结尾的条目）。

这意味着，可以使用 CLI 快捷方式来在整个目录层次结构中进行 lint 操作，ESLint 将仅考虑与 `*.js` 或带有适当配置的特定文件扩展名匹配的文件。

例如，以下 CLI 命令将在 `lib` 目录下查找 JavaScript 文件，如果有任何 `overrides` 条目，则将依次应用这些条目：

```
eslint lib
```

这将检查 `lib` 目录中的所有 JavaScript 文件。

如果希望忽略不需要 lint 操作的文件，则可以使用 `.eslintignore` 文件来指定要忽略的文件格式、目录和特定文件。该文件应该类似于 `.gitignore` 文件，并且可以包含注释和排除规则。

如果你在命令行中指定了 `--ext` 选项以及目录，则目标文件仅限于具有指定文件扩展名的文件，而与 overrides 条目无关。

这意味着可以使用 `--ext` 选项来仅在指定文件扩展名的文件上运行 lint 操作。例如，以下 CLI 命令将仅在具有 `.js` 和 `.jsx` 扩展名的文件上运行 lint 操作：

```
eslint --ext .js,.jsx lib
```

倘若在配置文件中定义的 overrides 匹配目标文件但是这些文件扩展名不在 `--ext` 选项中所列出的扩展名列表中，则这些文件将被忽略。

module.exports = { 
    env: { 
        // 指定环境 
        browser: true, // 浏览器环境 document 
        es2021: true, // ECMAScript语法 Promise
        node: true, // node环境 require 
    },
    extends: "eslint:recommended", 
    parserOptions: { 
        // ⽀持语⾔的选项, ⽀持最新js语法，同时⽀持jsx语法 ecmaVersion: "latest", 
        // ⽀持的语法是 
        sourceType: "module", // ⽀持模块化 
        ecmaFeatures:{ "jsx":true }
    },
    rules: { // eslint规则
        "semi": ["error", "always"],
        "quotes": ["error", "double"] 
    },
    globals:{ // 配置全局变量 
        custom:"readonly" // readonly 、 writable } 
    }; 
  //  pnpm install @typescript-eslint/eslint-plugin@latest @typescript-eslint/parser@latest typescript -D 
 "extends": [ 
     "eslint:recommended", 
     "plugin:@typescript-eslint/recommended" // 集成规则和插件 
 ], 
 "parser": "@typescript-eslint/parser" // 解析typescript

cat test.js|npx eslint --stdin

eslint9变化

配置文件扁平化
旧版本是使用extends来进行继承的，会导致继承树的复杂
新版本优点
- js配置，具有完全的控制权
- 简单的继承和覆盖
- 灵活、动态、可定制

旧版本迁移工具

可视化配置

扁平化配置工具

扁平化配置

例如配置indent:2,只需要配置 indent:2即可，不用再每一个插件都配置indent:2了

Eslint配置文件详解