Skip to main content

使用类型信息进行代码检查

一些 typescript-eslint 规则利用 TypeScript 的类型检查 API 来更深入地了解你的代码。这需要 TypeScript 分析整个项目，而不仅仅是被 linted 的文件。因此，这些规则比传统的 lint 规则慢，但功能更强大。

¥Some typescript-eslint rules utilize TypeScript's type checking APIs to provide much deeper insights into your code. This requires TypeScript to analyze your entire project instead of just the file being linted. As a result, these rules are slower than traditional lint rules but are much more powerful.

要启用类型化 linting，你需要对配置文件进行两项小更改：

¥To enable typed linting, there are two small changes you need to make to your config file:

  1. 将 TypeChecked 添加到你正在使用的任何预设配置的名称中，即 recommended、strict 和 stylistic。

    ¥Add TypeChecked to the name of any preset configs you're using, namely recommended, strict, and stylistic.

  2. 添加 languageOptions.parserOptions 以告诉我们的解析器如何找到每个源文件的 TSConfig。

    ¥Add languageOptions.parserOptions to tell our parser how to find the TSConfig for each source file.

eslint.config.mjs
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  eslint.configs.recommended,
  tseslint.configs.recommended,
  tseslint.configs.recommendedTypeChecked,
  {
    languageOptions: {
      parserOptions: {
        projectService: true,
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
);
注意

import.meta.dirname 仅存在于 Node.js >=20.11.0 / >= 21.2.0.
中的 ESM 文件中。对于 CommonJS 模块和/或旧版本的 Node.js，使用 __dirname 或替代方案。

¥import.meta.dirname is only present for ESM files in Node.js >=20.11.0 / >= 21.2.0.
For CommonJS modules and/or older versions of Node.js, use __dirname or an alternative.

更详细地说：

¥In more detail:

  • tseslint.configs.recommendedTypeChecked 是 共享配置。它包含推荐的规则，这些规则还需要类型信息。

    ¥tseslint.configs.recommendedTypeChecked is a shared configuration. It contains recommended rules that additionally require type information.

  • parserOptions.projectService: true 表示向 TypeScript 的类型检查服务询问每个源文件的类型信息（参见 解析器 > 项目服务）。

    ¥parserOptions.projectService: true indicates to ask TypeScript's type checking service for each source file's type information (see Parser > Project Service).

  • parserOptions.tsconfigRootDir 告诉我们的解析器项目根目录的绝对路径（参见 解析器 > tsconfigRootDir）。

    ¥parserOptions.tsconfigRootDir tells our parser the absolute path of your project's root directory (see Parser > tsconfigRootDir).

提醒

你的 ESLint 配置文件可能会开始收到有关类型信息的解析错误。参见 我们的 TSConfig 包含常见问题解答。

¥Your ESLint config file may start receiving a parsing error about type information. See our TSConfig inclusion FAQ.

完成后，运行之前运行的相同 lint 命令。你可能会看到新规则根据类型信息报告错误！

¥With that done, run the same lint command you ran before. You may see new rules reporting errors based on type information!

共享配置​

¥Shared Configurations

如果你在上一步中启用了 strict 共享配置 和/或 stylistic 共享配置，请确保分别用 strictTypeChecked 和 stylisticTypeChecked 替换它们以添加它们的类型检查规则。

¥If you enabled the strict shared config and/or stylistic shared config in a previous step, be sure to replace them with strictTypeChecked and stylisticTypeChecked respectively to add their type-checked rules.

eslint.config.mjs
export default tseslint.config(
  eslint.configs.recommended,
  tseslint.configs.strict,
  tseslint.configs.stylistic,
  tseslint.configs.strictTypeChecked,
  tseslint.configs.stylisticTypeChecked,
  // ...
);

你可以在我们的 规则文档 和 共享配置文档 中阅读有关 typescript-eslint 提供的规则的更多信息。

¥You can read more about the rules provided by typescript-eslint in our rules docs and shared configurations docs.

性能​

¥Performance

键入的规则有一个问题。通过在配置中使用类型化 linting，你将承担性能损失，因为要求 TypeScript 在 ESLint 进行 linting 之前构建项目。对于小型项目，这需要的时间可以忽略不计（几秒或更短）；对于大型项目，可能需要更长的时间。

¥Typed rules come with a catch. By using typed linting in your config, you incur the performance penalty of asking TypeScript to do a build of your project before ESLint can do its linting. For small projects this takes a negligible amount of time (a few seconds or less); for large projects, it can take longer.

我们的大多数用户并不介意这笔成本，因为类型感知静态分析规则的功能和安全性值得权衡。此外，大多数用户主要通过 IDE 插件处理 lint 错误，而通过缓存，不会遭受同样的惩罚。这意味着通常他们通常只在推送之前或通过 CI 运行完整的 lint，而额外的时间通常并不重要。

¥Most of our users do not mind this cost as the power and safety of type-aware static analysis rules is worth the tradeoff. Additionally, most users primarily consume lint errors via IDE plugins which, through caching, do not suffer the same penalties. This means that generally they usually only run a complete lint before a push, or via their CI, where the extra time often doesn't matter.

我们强烈建议你使用类型感知 linting，但上述信息包含在内，以便你可以做出自己的明智决定。有关更多信息，请参阅 故障排除 > 类型 Linting > 性能。

¥We strongly recommend you do use type-aware linting, but the above information is included so that you can make your own, informed decision. See Troubleshooting > Typed Linting > Performance for more information.

故障排除​

¥Troubleshooting

如果你在类型 lint 方面遇到问题，请参阅我们的 故障排除常见问题解答，特别是 故障排除 > 类型 Linting。

¥If you're having problems with typed linting, please see our Troubleshooting FAQs and in particular Troubleshooting > Typed Linting.

有关启用类型 linting 的解析器选项的详细信息，请参阅：

¥For details on the parser options that enable typed linting, see: