跳至主要内容

一致类型断言

强制一致使用类型断言。

🎨

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

🔧

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

💡

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

TypeScript 提供两种“类型断言”语法

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

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

注意

类型断言在 TypeScript 中也常被称为“类型转换”。但是，该术语在技术上与其他语言中对类型转换的理解略有不同。类型断言是一种告诉 TypeScript 编译器的方式，“我知道比你更多，它实际上是这种不同的类型！”。

const 断言 始终允许使用此规则。它们的示例包括 let x = "hello" as const; 和 let x = <const>"hello";。

.eslintrc.cjs
module.exports = {
  "rules": {
    "@typescript-eslint/consistent-type-assertions": "error"
  }
};

在游乐场中尝试此规则 ↗

选项​

此规则接受以下选项

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

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

assertionStyle​

此选项定义了预期的断言风格。assertionStyle 的有效值为

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

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

一些代码库喜欢通过 never 选项来实现额外的类型安全性，并完全禁止断言。

objectLiteralTypeAssertions​

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

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

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

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

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

const x = { foo: 1 } as T;

function bar() {
  return { foo: 1 } as T;
}
在 Playground 中打开

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

const x = { foo: 1 } as T;

function bar() {
  return { foo: 1 } as T;
}
在 Playground 中打开

何时不使用它​

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

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

资源​