Skip to main content

consistent-type-assertions

Enforce consistent usage of type assertions.

🎨

在 ESLint 配置 中扩展"plugin:@typescript-eslint/stylistic" 可启用此规则。

🔧

此规则报告的一些问题可通过 --fix ESLint 命令行选项自动修复。

💡

此规则报告的一些问题可以通过编辑器 建议 手动修复。


TypeScript 为 "类型断言" 提供了两种语法：

英：TypeScript provides two syntaxes for "type assertions":

  • 尖括号： <Type>value
  • 作为： value as Type

该规则旨在标准化整个代码库中类型断言样式的使用。 始终坚持一种语法有助于提高代码的可读性。

英：This rule aims to standardize the use of type assertion style across the codebase. Keeping to one syntax consistently helps with code readability.

注意

类型断言在 TypeScript 中通常也称为 "类型铸造"。 然而，该术语在技术上与其他语言中类型转换的理解略有不同。 类型断言是对 TypeScript 编译器说 "我比你更清楚，其实这是不同的类型！" 的一种方式。

此规则始终允许 const 断言。 例如 let x = "hello" as const; 和 let x = <const>"hello";。

英：const assertions are always allowed by this rule. Examples of them include let x = "hello" as const; and let x = <const>"hello";.

.eslintrc.cjs
module.exports = {
  "rules": {
    "@typescript-eslint/consistent-type-assertions": "error"
  }
};
在线运行试试这个规则 ↗

选项​

assertionStyle​

该选项定义了预期的断言样式。 assertionStyle 的有效值为：

英：This option defines the expected assertion style. Valid values for assertionStyle are:

  • as 将强制你始终使用 ... as foo。
  • angle-bracket 将强制你始终使用 <foo>...
  • never 将强制你不执行任何类型断言。

大多数代码库都希望强制不使用 angle-bracket 样式，因为它与 JSX 语法冲突，并且与通用语法配对时会令人困惑。

英：Most codebases will want to enforce not using angle-bracket style because it conflicts with JSX syntax, and is confusing when paired with generic syntax.

一些代码库喜欢追求额外的类型安全级别，并通过 never 选项完全禁止断言。

英：Some codebases like to go for an extra level of type safety, and ban assertions altogether via the never option.

objectLiteralTypeAssertions​

始终优先选择 const x: T = { ... }; 而不是 const x = { ... } as T;（或类似的尖括号）。 后一种情况下的类型断言要么是不必要的，要么可能会隐藏错误。

英：Always prefer const x: T = { ... }; to const x = { ... } as T; (or similar with angle brackets). The type assertion in the latter case is either unnecessary or will probably hide an error.

编译器将警告此语法中的过多属性，但不会丢失必需的字段。 例如： const x: { foo: number } = {}; 将无法编译，但 const x = {} as { foo: number } 将成功。

英：The compiler will warn for excess properties with this syntax, but not missing required fields. For example: const x: { foo: number } = {}; will fail to compile, but const x = {} as { foo: number } will succeed.

TypeScript 3.4 中引入的 const 断言 const x = { foo: 1 } as const 被认为是有益的，并且被该选项忽略。

英：The const assertion const x = { foo: 1 } as const, introduced in TypeScript 3.4, is considered beneficial and is ignored by this option.

此选项也会忽略对 any 的断言。

英：Assertions to any are also ignored by this option.

{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' } 的代码示例：

英：Examples of code for { assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }:

const x = { ... } as T;

function foo() {
  return { ... } as T;
}
Open in Playground

{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' } 的代码示例：

英：Examples of code for { assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }:

const x = { ... } as T;

function foo() {
  return { ... } as T;
}
Open in Playground

何时不使用它​

如果你不想强制执行一致的类型断言。

英：If you do not want to enforce consistent type assertions.

但是，请记住，不一致的风格可能会损害项目的可读性。 我们建议为此规则选择一个最适合你的项目的选项。

英：However, keep in mind that inconsistent style can harm readability in a project. We recommend picking a single option for this rule that works best for your project.

选项​

该规则接受以下选项

type Options = [
  | {
      assertionStyle: 'angle-bracket' | 'as';
      objectLiteralTypeAssertions?: 'allow' | 'allow-as-parameter' | 'never';
    }
  | {
      assertionStyle: 'never';
    },
];

const defaultOptions: Options = [
  { assertionStyle: 'as', objectLiteralTypeAssertions: 'allow' },
];

资源​