Skip to main content

TypeScript 常见问题

应该全局还是本地安装 TypeScript？​

¥Should TypeScript be installed globally or locally?

确保你已在本地安装了 TypeScript，即使用 npm install typescript 而不是 npm install -g typescript，或者使用 yarn add typescript 而不是 yarn global add typescript。有关更多信息，请参阅 #2041。

¥Make sure that you have installed TypeScript locally i.e. by using npm install typescript, not npm install -g typescript, or by using yarn add typescript, not yarn global add typescript. See #2041 for more information.

为什么我在 ESLint 输出中看不到 TypeScript 错误？​

¥Why don't I see TypeScript errors in my ESLint output?

TypeScript 的编译器（或任何你的构建链）是专门设计和构建的，用于验证代码库的正确性。我们的工具不会重现 TypeScript 提供的错误，因为这样做会减慢 lint 运行 [1]，并重复 TypeScript 已经为你输出的错误。

¥TypeScript's compiler (or whatever your build chain may be) is specifically designed and built to validate the correctness of your codebase. Our tooling does not reproduce the errors that TypeScript provides, because doing so would slow down the lint run [1], and duplicate the errors that TypeScript already outputs for you.

相反，我们的工具存在是为了增强 TypeScript 的内置检查，使用 lint 规则，以新的方式使用类型信息，而不仅仅是验证代码的运行时正确性。

¥Instead, our tooling exists to augment TypeScript's built in checks with lint rules that consume the type information in new ways beyond just verifying the runtime correctness of your code.

[1] - TypeScript 以惰性方式计算类型信息，因此我们向编译器请求它产生的错误将需要每个文件额外花费约 100 毫秒。这听起来不是很多，但根据代码库的大小，lint 运行的时间很容易就会增加几秒到几分钟。

¥[1] - TypeScript computes type information lazily, so us asking for the errors it would produce from the compiler would take an additional ~100ms per file. This doesn't sound like a lot, but depending on the size of your codebase, it can easily add up to between several seconds to several minutes to a lint run.

如何指定 TypeScript 版本/parserOptions.typescriptLocation？​

¥How can I specify a TypeScript version / parserOptions.typescriptLocation?

你不能，你也不想。

¥You can't, and you don't want to.

你应该使用与项目其余部分相同版本的 TypeScript 进行 linting。TypeScript 版本通常在边缘情况下存在细微差异，这可能会导致 typescript-eslint 规则和编辑器信息之间出现矛盾的信息。例如：

¥You should use the same version of TypeScript for linting as the rest of your project. TypeScript versions often have slight differences in edge cases that can cause contradictory information between typescript-eslint rules and editor information. For example:

  • @typescript-eslint/strict-boolean-expressions 可能使用 TypeScript 版本 X 运行，并认为变量是 string[] | undefined

    ¥@typescript-eslint/strict-boolean-expressions might be operating with TypeScript version X and think a variable is string[] | undefined

  • TypeScript 本身可能处于 X+1-beta 版本，并认为变量是 string[]

    ¥TypeScript itself might be on version X+1-beta and think the variable is string[]

请参阅 问题评论 以了解更多详细信息。

¥See this issue comment for more details.

为什么没有 // @ts-expect-error 或 // @ts-ignore 注释影响 lint 结果？​

¥Why aren't // @ts-expect-error or // @ts-ignore comments affecting lint results?

// @ts-expect-error 和 // @ts-ignore 注释指令是 TypeScript 的一项功能。它们只会影响 TypeScript 的类型检查。TypeScript（类型检查器）是独立于 ESLint（linter）的工具。

¥// @ts-expect-error and // @ts-ignore comment directives are a feature of TypeScript. They only impact TypeScript's type checking. TypeScript (a type checker) is a separate tool from ESLint (a linter).

类似，ESLint 配置注释 和 /* eslint ... */ 一样，只影响 ESLint。它们不会改变 TypeScript 的类型检查。

¥Similar, ESLint configuration comments like /* eslint ... */ only impact ESLint. They don't change anything with TypeScript's type checking.

提示

你可以使用 ESLint 来强制正确使用 ESLint 和 TypeScript 注释指令：

¥You can use ESLint to enforce good uses of both ESLint and TypeScript comment directives:

我应该如何处理与 verbatimModuleSyntax 冲突的报告？​

¥How should I handle reports that conflict with verbatimModuleSyntax?

几个 TypeScript 选项会影响项目中导入和导出的处理方式，包括：

¥Several TypeScript options impact how imports and exports are handled in your project, including:

此外，无论是编写 ES 模块还是 CommonJS 都会影响 import/export/require 语义。我们的某些规则可能不适用，或者可能需要在使用这些选项的项目中进行特殊配置。

¥Additionally, whether one is authoring ES Modules or CommonJS impacts import/export/require semantics. Some of our rules may not apply or may need special configuration in projects using these options.

例如，no-require-imports 的默认行为完全禁止 CommonJS require 语法，但 verbatimModuleSyntax 在编写 CommonJS 模块时需要它。因此，你需要配置规则以允许 import x = require('foo') 语法。

¥For example, the default behavior of no-require-imports prohibits CommonJS require syntax entirely, but verbatimModuleSyntax requires it when authoring CommonJS modules. Therefore, you'll need to configure the rule to permit import x = require('foo') syntax.

已知与 verbatimModuleSyntax 冲突或需要特殊配置才能与 verbatimModuleSyntax 一起使用的规则包括：

¥Known rules that conflict with or require special configuration to be used with verbatimModuleSyntax include:

如果你使用的是 importsNotUsedAsValues、isolatedModules 和/或 preserveValueImports TSConfig 选项，你可能还需要额外配置这些 lint 规则。有关更多信息，请参阅规则的文档。

¥If you are using the importsNotUsedAsValues, isolatedModules, and/or preserveValueImports TSConfig options, you may need to additionally configure those lint rules as well. See the rules' documentation for more information.