跳到主要內容

consistent-type-assertions

強制執行類型斷言的一致性使用。

🎨

擴充 “plugin:@typescript-eslint/風格" 在 ESLint 組態 中啟用這項規則。

🔧

有些由這項規則報告的問題可透過 --fix ESLint 指令列選項自動修正.

💡

有些由這項規則報告的問題可透過編輯器建議手動修正 建議.

TypeScript 提供兩種「類型斷言」語法

  • 小於號和大於號：<Type>value
  • 作為：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 語法衝突，並且與泛型語法配對時會造成混淆，因此大多數程式碼庫將希望強制執行不使用 angle-bracket 風格。

有些程式碼庫希望執行額外層級的類型安全性，並透過 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;
}
在遊樂場中開啟

{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' } 的程式碼範例

const x = { foo: 1 } as T;

function bar() {
  return { foo: 1 } as T;
}
在遊樂場中開啟

不應使用的時機​

您不想強制執行一致的類型斷言。

然而，請謹記不一致的風格可能會影響專案的可讀性。我們建議您為此規則選取適用於專案的單一選項。

資源​