eslint-plugin-import-x

该插件旨在支持对ES2015+（ES6+）import/export语法的检查，并防止文件路径和导入名称拼写错误的问题。ES2015+静态模块语法提供的所有优点，都可以在您的编辑器中得到体现。

eslint-plugin-i现已更名为eslint-plugin-import-x

如果您正在Sublime中使用本插件：请查看底部章节获取重要信息。

规则

💼 在配置中启用。
⚠️ 在配置中设置为警告。
🚫 在配置中禁用。
❗ 在errors配置中设置。
☑️ 在recommended配置中设置。
⌨️ 在typescript配置中设置。
🚸 在warnings配置中设置。
🔧 可通过--fix CLI选项自动修复。
💡 可通过编辑器建议手动修复。
❌ 已废弃。

有用的警告

模块系统

静态分析

风格指南

安装

# 在项目的工作树内
npm install eslint-plugin-import-x --save-dev

所有规则默认都是关闭的。但是，您可以在 .eslintrc.(yml|json|js) 中手动配置它们，或扩展预设配置：

---
extends:
  - eslint:recommended
  - plugin:import-x/recommended
  # 或者，'recommended' 是以下两个规则集的组合：
  - plugin:import-x/errors
  - plugin:import-x/warnings

# 或手动配置：
plugins:
  - import-x

rules:
  import-x/no-unresolved: [2, { commonjs: true, amd: true }]
  import-x/named: 2
  import-x/namespace: 2
  import-x/default: 2
  import-x/export: 2
  # 等等...

TypeScript

您可以使用以下代码片段，或使用下面描述的精细设置自行组装配置。

确保您已安装 [@typescript-eslint/parser] 和 [eslint-import-resolver-typescript]，它们在以下配置中使用。

extends:
  - eslint:recommended
  - plugin:import-x/recommended
  # 以下几行是关键
  - plugin:import-x/typescript
settings:
  import-x/resolver:
    # 您还需要安装和配置 TypeScript 解析器
    # 另请参阅 https://github.com/import-js/eslint-import-resolver-typescript#configuration
    typescript: true
    node: true

解析器

随着模块打包工具的出现以及模块和模块语法规范的当前状态，import x from 'module' 应该在哪里查找 module 背后的文件并不总是显而易见的。

直到 v0.10 左右，这个插件直接使用 substack 的 resolve 插件，它实现了 Node 的导入行为。在大多数情况下，这种方法效果很好。

然而，webpack 允许在导入模块源字符串中使用 Node 不允许的一些内容，比如加载器（import 'file!./whatever'）和一些别名方案，如 externals：在运行时将模块 ID 映射到全局名称（允许一些模块通过脚本标签以更传统的方式包含）。

为了支持这两种方法，v0.11 引入了解析器。

目前已实现了 Node 和 webpack 解析，但解析器只是 npm 包，所以支持（并鼓励）第三方包。

您可以通过几种方式引用解析器（按优先顺序）：

• 作为常规的 eslint-import-resolver 名称，如 eslint-import-resolver-foo：

# .eslintrc.yml
settings:
  # 使用 'eslint-import-resolver-foo'：
  import-x/resolver: foo

// .eslintrc.js
module.exports = {
  settings: {
    'import-x/resolver': {
      foo: { someConfig: value },
    },
  },
}

• 使用完整的 npm 模块名称,如 my-awesome-npm-module:

# .eslintrc.yml
settings:
  import-x/resolver: 'my-awesome-npm-module'

// .eslintrc.js
module.exports = {
  settings: {
    'import-x/resolver': {
      'my-awesome-npm-module': { someConfig: value },
    },
  },
}

• 使用文件系统路径作为解析器,在此示例中定义为计算属性名称:

// .eslintrc.js
module.exports = {
  settings: {
    'import-x/resolver': {
      [path.resolve('../../../my-resolver')]: { someConfig: value },
    },
  },
}

相对路径将相对于源代码最近的 package.json 进行解析,如果找不到 package.json,则相对于进程的当前工作目录进行解析。

如果你有兴趣编写解析器,请查看规范以获取更多详细信息。

设置

你可以在 .eslintrc 中设置以下选项:

import-x/extensions

将被解析为模块并检查 export 的文件扩展名列表。

默认为 ['.js'],除非你使用 react 共享配置,在这种情况下它被指定为 ['.js', '.jsx']。尽管有默认值,如果你使用 TypeScript(但未使用上述的 plugin:import-x/typescript 配置),你必须指定新的扩展名(.ts,如果使用 React 还需要 .tsx)。

"settings": {
  "import-x/extensions": [
    ".js",
    ".jsx"
  ]
}

如果你需要更细粒度的扩展名定义,可以使用:

"settings": {
  "import-x/resolver": {
    "node": {
      "extensions": [
        ".js",
        ".jsx"
      ]
    }
  }
}

请注意,这与任何 import-x/resolver 扩展设置不同(且可能是其子集),后者可能包括 .json、.coffee 等,这些仍将影响 no-unresolved 规则。

此外,以下 import-x/ignore 模式将覆盖此列表。

import-x/ignore

正则表达式字符串列表,如果路径匹配,则在未找到 export 时不会报告匹配的模块。实际上,这意味着除了 no-unresolved 之外的规则不会报告与此模式匹配的(绝对文件系统)路径的任何 import。

no-unresolved 有自己的 ignore 设置。

settings:
  import-x/ignore:
    - \.coffee$ # 充满解析错误
    - \.(scss|less|css)$ # 也无法解析未处理的 CSS 模块

import-x/core-modules

要考虑为"核心"模块的附加模块数组 - 应该被视为已解析但在文件系统上没有路径的模块。你的解析器可能已经定义了其中一些(例如,Node 解析器知道 fs 和 path),因此你无需重新定义这些。

例如,Electron 暴露了一个 electron 模块:

import 'electron' // 没有额外配置,将被标记为未解析!

否则将无法解析。为避免这种情况,你可以提供 electron 作为核心模块:

# .eslintrc.yml
settings:
  import-x/core-modules: [electron]

在 Electron 的特定情况下,有一个名为 electron 的共享配置为你指定了这一点。

欢迎为其他平台贡献更多此类共享配置!

import-x/external-module-folders

文件夹数组。只有来自这些文件夹的已解析模块才会被视为"外部"模块。默认为 ["node_modules"]。如果你已配置路径或 webpack 以不同方式处理内部路径,并希望将某些文件夹(例如 bower_components 或 jspm_modules)中的模块视为"外部"模块,则此选项很有意义。

此选项在单体仓库设置中也很有用:在此列出包含单体仓库包的所有目录,无论使用哪个解析器,它们都将被视为外部模块。

如果你使用 yarn PnP 作为包管理器,添加 .yarn 文件夹,所有已安装的依赖项将被视为 external,而不是 internal。

此数组中的每个项目可以是文件夹的名称、其子路径或其绝对前缀路径:

• jspm_modules 将匹配任何名为 jspm_modules 的文件或文件夹,或具有名为 jspm_modules 的直接或非直接父级的文件或文件夹,例如 /home/me/project/jspm_modules 或 /home/me/project/jspm_modules/some-pkg/index.js。

• packages/core 将匹配包含这两个片段的任何路径,例如 /home/me/project/packages/core/src/utils.js。

• /home/me/project/packages 将仅匹配此目录内的文件和目录,以及目录本身。

请注意,此处不允许使用不完整的名称,因此 components 不会匹配 bower_components,packages/ui 不会匹配 packages/ui-utils(但会匹配 packages/ui/utils)。

import-x/parsers

从解析器到文件扩展名数组的映射。如果匹配到文件扩展名,依赖解析器将使用映射键作为解析器,而不是配置的 ESLint 解析器。如果你直接使用 webpack 与 TypeScript 进行互操作,这很有用,例如:

# .eslintrc.yml
settings:
  import-x/parsers:
    '@typescript-eslint/parser': [.ts, .tsx]

在这种情况下,必须安装 @typescript-eslint/parser 并且可以从运行的 eslint 模块位置引入(即,将其作为 ESLint 的对等依赖安装)。

目前仅测试过 @typescript-eslint/parser(及其前身 typescript-eslint-parser),但理论上应该适用于任何基本符合 ESTree 的解析器。 很难说各种插件功能的支持程度如何，这取决于问题的深度。如果您发现此处以外的奇怪行为，请提交问题，但要做好可能会以"不予修复"结束的心理准备。

import-x/resolver

请参阅解析器。

import-x/cache

缓存行为设置。在各个层面使用记忆化来避免大量的fs.statSync/模块解析调用，这些调用是正确报告错误所必需的。

对于普通的eslint控制台运行，缓存生命周期无关紧要，因为我们可以强烈假设在linter进程的生命周期内（因此，内存中的缓存）文件不应该发生变化。

然而，对于长期运行的进程，如eslint_d或eslint-loader，有一些过时的概念很重要。

如果您从不使用eslint_d或eslint-loader，可以将缓存生命周期设置为Infinity，一切应该没问题：

# .eslintrc.yml
settings:
  import-x/cache:
    lifetime: ∞ # 或 Infinity

否则，设置一个整数，缓存条目将在经过那么多秒后被逐出：

# .eslintrc.yml
settings:
  import-x/cache:
    lifetime: 5 # 默认为30

import-x/internal-regex

应被视为内部的包的正则表达式。当您使用monorepo设置或开发一组相互依赖的包时，这很有用。

默认情况下，任何从import-x/external-module-folders引用的包都将被视为"外部"，包括在monorepo（如yarn工作空间或lerna环境）中的包。如果您想将这些包标记为"内部"，这将很有用。

例如，如果您monorepo中的包都在@scope中，您可以这样配置import-x/internal-regex：

# .eslintrc.yml
settings:
  import-x/internal-regex: ^@scope/

SublimeLinter-eslint

SublimeLinter-eslint引入了一项支持.eslintignore文件的变更，这改变了在编辑时传递文件路径给ESLint的方式。这一变更发送相对路径而不是文件的绝对路径（ESLint通常提供的），这可能使得此插件无法解析文件系统上的依赖关系。

随着ESLint 2.0的发布，这个解决方法应该不再需要了，因为.eslintignore将被更新为更像.gitignore那样工作，应该支持通过--stdin-filename正确忽略绝对路径。

同时，请参阅roadhump/SublimeLinter-eslint#58以获取更多详细信息和讨论，但基本上，您可能需要在Sublime项目文件中添加以下SublimeLinter配置：

{
  "folders": [
    {
      "path": "code"
    }
  ],
  "SublimeLinter": {
    "linters": {
      "eslint": {
        "chdir": "${project}/code"
      }
    }
  }
}

注意，${project}/code与folders[0].path提供的code相匹配。

在这种情况下，chdir设置的目的是将ESLint执行的工作目录设置为与SublimeLinter-eslint提供相对路径的基础目录相同。

如果这对您的项目不起作用，请参阅SublimeLinter关于chdir的文档以获取更多信息。

如果您不使用.eslintignore，或者没有Sublime项目文件，您也可以通过在代码的某个祖先目录中的.sublimelinterrc文件进行以下设置：

{
  "linters": {
    "eslint": {
      "args": ["--stdin-filename", "@"]
    }
  }
}

我还发现需要将rc_search_limit设置为null，这会在查找目录树中的.sublimelinterrc时取消文件层次结构搜索限制：

在Package Settings / SublimeLinter / User Settings中：

{
  "user": {
    "rc_search_limit": null
  }
}

我相信这默认为3，所以根据您的项目文件夹最大深度，您可能不需要更改它。