跳至主要內容

Lint 規則參考

all​

雖然 all 在技術上並非 lint 規則，但值得在此提及。all 設定未明確設定層級的 lint 規則的預設層級。all 只能作為 .flowconfig 中的第一個項目，或作為 --lints 旗標中的第一個規則。它完全不允許用於註解，因為它會有與預期不同的語意。

ambiguous-object-type​

在未明確指定精確性或不精確性時，使用物件類型語法時觸發。

當 exact_by_default 設定為 false 時，會忽略此 lint 設定。

1// flowlint ambiguous-object-type:error2
3type A = {x: number}; // Error
                    
4type B = {x: number, ...} // Ok5type C = {| x: number |} // Ok
3:10-3:20: Please write this object type as explicitly exact (use `{|` and `|}` instead of `{` and `}`) or as explicitly inexact (add `...` to the end of the list of properties). [ambiguous-object-type]

deprecated-type​

在 bool 類型上觸發，它只是 boolean 的別名。請改用 boolean。

1// flowlint deprecated-type:error2
3type A = Array<bool>; // Error
                   
3:16-3:19: Deprecated type. Use `boolean` instead. [deprecated-type]

implicit-inexact-object​

與 ambiguous-object-type 類似，但即使 exact_by_default 選項設定為 false 時也會觸發。

nonstrict-import​

與 Flow Strict 搭配使用。在匯入非 @flow strict 模組時觸發。啟用後，@flow strict 模組的依賴項也必須是 @flow strict。

sketchy-null​

當您對可以為 null/undefined 或 falsey 的值執行存在檢查時觸發。

例如

1// flowlint sketchy-null:error2
3const x: ?number = 5;4if (x) {} // sketchy because x could be either null or 0.
     
5
6const y: number = 5;7if (y) {} // not sketchy because y can't be null, only 0.8
9const z: ?{foo: number} = {foo: 5};10if (z) {} // not sketchy, because z can't be falsey, only null/undefined.
4:5-4:5: Sketchy null check on number [1] which is potentially 0. Perhaps you meant to check for null or undefined [2]? [sketchy-null-number]

設定 sketchy-null 會設定所有 sketchy null 檢查的層級，但針對特定類型有更精細的規則。這些規則為

  • sketchy-null-bool
  • sketchy-null-number
  • sketchy-null-string
  • sketchy-null-mixed
  • sketchy-null-bigint

特定類型的變異可用於指定某些類型的 sketchy null 檢查是可以接受的，而其他類型應為錯誤/警告。例如，如果您想要允許布林 sketchy null 檢查（用於將未定義的選用布林值視為 false 的模式），但禁止其他類型的 sketchy null 檢查，您可以使用這個 .flowconfig [lints] 區段來執行此操作

[lints]
sketchy-null=warn
sketchy-null-bool=off

現在

function foo (bar: ?bool): void {
  if (bar) {
    ...
  } else {
    ...
  }
}

不會回報警告。

抑制一種 sketchy null 檢查只會抑制該類型，因此，例如

1// flowlint sketchy-null:error, sketchy-null-bool:off2const x: ?(number | bool) = 0;3if (x) {}
     
3:5-3:5: Sketchy null check on number [1] which is potentially 0. Perhaps you meant to check for null or undefined [2]? [sketchy-null-number]

第 3 行仍然會有 sketchy-null-number 錯誤。

sketchy-number​

當 number 以可能導致意外結果的方式使用時觸發，如果值為 falsey，目前，如果 number 出現在

  • && 表達式的左側。

作為一個激勵的範例，考慮 React 中的這個常見慣用語法

{showFoo && <Foo />}

在這裡，showFoo 是控制是否顯示 <Foo /> 元素的布林值。如果 showFoo 為 true，則這會評估為 {<Foo />}。如果 showFoo 為 false，則這會評估為 {false}，不會顯示任何東西。

現在假設我們沒有布林值，而是有一個數字值表示一篇文章上的留言數。我們想要顯示留言數，除非沒有留言。我們可能會天真地嘗試做一些類似於布林值案例的事情

{count && <>[{count} comments]</>}

如果 count 為 5，則會顯示「[5 則留言]」。然而，如果 count 為 0，則會顯示「0」，而不是不顯示任何內容。（這個問題僅限於 number，因為 0 和 NaN 是 React 唯一會以可見結果呈現的假值。）這可能會造成微妙的危險：如果這緊接在另一個數字值之後，使用者可能會以為我們將該值乘以 10！相反地，我們應該進行適當的條件檢查

{count ? <>[{count} comments]</> : null}

unclear-type​

當您使用 any、Object 或 Function 作為類型註解時觸發。這些類型是不安全的。

1// flowlint unclear-type:error2
3declare const a: any; // Error
                    
4declare const c: Object; // Error
                       
5declare const d: Function; // Error
                         
3:18-3:20: Unclear type. Using `any`, `Object`, or `Function` types is not safe! [unclear-type]
4:18-4:23: Unclear type. Using `any`, `Object`, or `Function` types is not safe! [unclear-type]
5:18-5:25: Unclear type. Using `any`, `Object`, or `Function` types is not safe! [unclear-type]

unnecessary-invariant​

當您使用 invariant 檢查一個我們已知根據可用類型資訊必定為真值的條件時觸發。這相當保守：例如，如果我們只知道該條件為 boolean，即使該條件在執行階段必定為 true，此檢查也不會觸發。

請注意，當我們知道一個條件永遠為 false 時，此檢查不會觸發。使用 invariant() 或 invariant(false, ...) 來拋出在程式碼中應無法到達的錯誤訊息是一種常見慣例。

1// flowlint unnecessary-invariant:error2declare function invariant(boolean): void;3
4declare const x: Array<string>; // Array is truthy5invariant(x);
            
5:1-5:12: This use of `invariant` is unnecessary because array type [1] is always truthy. [unnecessary-invariant]

unnecessary-optional-chain​

當您在不需要的地方使用 ?. 時觸發。這有兩種主要情況。第一種情況是當左側不能為 nullish

1// flowlint unnecessary-optional-chain:error2type Foo = {3  bar: number4}5
6declare const foo: Foo;7foo?.bar; // Error
        
7:1-7:8: This use of optional chaining (`?.`) is unnecessary because `foo` [1] cannot be nullish or because an earlier `?.` will short-circuit the nullish case. [unnecessary-optional-chain]

第二種情況是當左側可能為 nullish，但 ?. 的短路行為已足夠處理它

1// flowlint unnecessary-optional-chain:error2type Foo = {3  bar: {4    baz: number5  }6}7
8declare const foo: ?Foo;9foo?.bar?.baz; // Error
             
9:1-9:13: This use of optional chaining (`?.`) is unnecessary because `foo?.bar` [1] cannot be nullish or because an earlier `?.` will short-circuit the nullish case. [unnecessary-optional-chain]

在第二個範例中，第一次使用 ?. 是有效的，因為 foo 可能為 nullish，但第二次使用 ?. 是不必要的。第二次 ?. 的左側 (foo?.bar) 只有在 foo 為 nullish 時才會為 nullish，而當 foo 為 nullish 時，短路讓我們完全避免第二次 ?.！

foo?.bar.baz;

這讓讀者清楚了解 bar 不是一個可能為 nullish 的屬性。

unsafe-getters-setters​

當您使用 getter 或 setter 時觸發。getter 和 setter 可能有副作用，而且不安全。

例如

1// flowlint unsafe-getters-setters:error2let a = 1;3const o = {4  get a() { return a; }, // Error: unsafe-getters-setters
                       
5  set b(x: number) { a = x; }, // Error: unsafe-getters-setters
                             
6  c: 10,7};
4:3-4:23: Getters and setters can have side effects and are unsafe. [unsafe-getters-setters]
5:3-5:29: Getters and setters can have side effects and are unsafe. [unsafe-getters-setters]

untyped-import​

當您從未設定類型檔案匯入時觸發。從未設定類型檔案匯入會導致這些匯入被設定為 any 類型，這是不安全的。

untyped-type-import​

當您從未輸入檔案匯入類型時觸發。從未輸入檔案匯入類型會產生 any 別名，這通常不是預期的行為。啟用此程式碼檢查會特別注意此情況，並透過限制隱含 any 類型的擴散，來協助改善已輸入檔案的 Flow 涵蓋範圍。

unused-promise​

當 Promise 未使用時觸發。這很危險，因為錯誤可能會未處理，且程式碼可能不會按照預期的順序執行。

「使用」承諾的方法有...

  • await
  • 呼叫 .then 並附上拒絕處理常式（即使用兩個參數）
  • 呼叫 .catch
  • 呼叫 .finally
  • 將其儲存在變數中、傳遞給函式等。

例如

1// flowlint unused-promise:error2declare function foo(): Promise<void>;3
4async function bar() {5  await foo(); // ok6  foo(); // error, we forgot to await!
        
7}8
9function baz() {10  foo().catch(err => {console.log(err)}); // ok11  foo(); // error
        
12}
6:3-6:8: `Promise` in async scope is unused. Did you mean to `await` it? [unused-promise]
11:3-11:8: `Promise` in sync scope is unused. Promises must be handled by calling .then with a rejection handler, .catch, or .finally. [unused-promise]

您可以使用 void 算子明確忽略承諾（例如，void foo();）。

注意：從 v0.201.0 開始，此規則包含 unused-promise-in-async-scope 和 unused-promise-in-sync-scope 規則。