网站搜索

reactjs - 如何在 TypeScript React 项目中使用 eslint import 插件启用绝对路径别名？

我已经在我的项目中安装了eslint-plugin-import，我的目标是使用'import/no-relative-parent-imports': 'error' 设置来禁止项目中的相对导入，以提高可读性。

然而，这个设置会在我的整个项目中产生错误，因为它无法识别我对根文件夹的 tsconfig 别名。
我的 tsconfig.json 有以下设置。

 "paths": {
      "src/": ["./src/*"]
    }

我尝试在我的项目中以如下方式导入组件。
import { Component } from 'src/components/ComponentA' 但是 eslint 会抱怨使用了相对导入，而实际上我使用 tsconfig 的路径别名进行了绝对导入。我已经安装了 eslint-import-resolver-typescript 并在我的 .eslintrc.js 文件中启用了它。

settings: {
    'import/resolver': {
      typescript: {},
    },
  },

我的错误消息如下。

Relative imports from parent directories are not allowed. Please either pass what you're importing through at runtime (dependency injection), move `example.ts` to same directory as `src/components/ComponentA` or consider making `src/components/ComponentA` a package. (eslintimport/no-relative-parent-imports)

答案＃1

这种行为是正确的。根据 no-relative-parent-imports 的代码库，这个 lint 只会检查你是否从另一个父目录使用了任何组件/类。此规则不关心你的导入路径是相对的还是绝对的。

假设你有以下目录路径：

src
+---utils
|   +---time
|   |   +---- TimeWrapper.ts
|   +---Logger.ts
+---index.ts

现在，如果你尝试在 Logger 内使用 TimeWrapper，此规则将允许此导入，因为 TimeWrapper 位于 Logger 的父文件夹（src/util）中。而如果你尝试在 TimeWrapper 内访问 Logger，此规则将抛出错误，因为 Logger 不在 TimeWrapper 的父文件夹（src/util/time）中。

所以，实际上，这条规则并不关心你是使用相对路径还是绝对路径导入类。它只关心解析后的路径依赖是否存在于同一个父文件夹中。

此规则应仅在代码的某些部分使用。比如，你不希望 Database 文件夹的类依赖于其他文件夹如 Services。因此你不应该将其用于整个项目，因为那样会使开发变得非常困难。

如果你想避免相对导入，你可以使用以下方法：

module.exports = {
  rules: {
    'no-restricted-imports': [
      'error',
      {
        patterns: [
          {
            group: ['../*'],
            message: 'Usage of relative parent imports is not allowed.',
          },
        ],
      },
    ],
  },
};

答案＃2

它按预期工作。根据规则文档：

使用此规则防止导入相对父路径中的文件夹。

与您预期的相反，这并不意味着要阻止相对于父路径文件夹的相对导入。因此，如果一个导入模块的路径在完全解析之后位于相对于当前文件的父路径中，这条规则将会给你一个错误提示。

文档进一步解释道：

此规则有助于强制执行类似树状的文件夹结构，而不是复杂的图状文件夹结构。

因此，模块被迫仅依赖于相邻的和子级的依赖，而完全不依赖于父级的依赖。这是一种有效防止循环依赖的方法，例如，一个子模块依赖于父模块，而父模块又反过来依赖于子模块（直接或间接）。

用相对于项目的绝对路径覆盖相对路径不会改变文件彼此之间的相对关系。相反，它会混淆你的依赖关系，并使查找导入问题变得困难。

有了这种理解并牢记规则的意图，它按预期工作，抛出了上述提到的错误。

保持这一规则将需要付出一些努力来相应地重组您的项目，并修复导入到父文件的路径。作为回报，您将获得更稳定、错误更少的依赖管理，我强烈建议利用这一点。如果您只是想防止任何相对导入路径，您应该改为使用另一条规则。

相关文章