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

booleanのエイリアスに過ぎないbool型でトリガーされます。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の設定は、すべての不審なnullチェックのレベルを設定しますが、特定の型に対するより詳細なルールがあります。それらは次のとおりです。

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

type固有のバリアントは、あるタイプの不審なnullチェックは許容でき、他のタイプはエラーや警告にする必要があることを指定するために役立ちます。たとえば、（未定義のオプションのブーリアンをfalseとして扱うというパターンについては）booleanの不審なnullチェックを許可したいが、他のタイプの不審なnullチェックは禁止したい場合は、次のような.flowconfig [lints]セクションを使用できます。

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

そして今

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

警告は報告されません。

1種類の不審な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 が使用されたときにトリガーされます。現在、このリントは 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

利用可能な型情報に基づいて常に true であることを知っている条件を確認するために 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

不要な場所で ?. を使用するときにトリガーされます。これには主に 2 つのタイプがあります。1 つ目は、左辺が 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]

2 つ目は、左辺が 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]

2 つ目の例では、foo が nullish の可能性があるので、?. の最初の使用は有効ですが、?. の 2 番目の使用は不要です。2 番目の ?. (foo?.bar) の左辺は、foo が nullish であることでのみ nullish になり、foo が nullish の場合、短絡回路により 2 番目の ?. をまったく回避できます。

foo?.bar.baz;

これにより、読者に bar が nullish の可能性のあるプロパティではないことが明確になります。

unsafe-getters-setters

ゲッターまたはセッターを使用するとトリガーされます。ゲッターやセッターは副作用を与える可能性があり、安全ではありません。

例

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 が使用されていないとトリガーされます。これは、エラーが未処理になる可能性があり、コードが目的の順序で実行されない可能性があるため、危険です。

Promise は...によって「使用」できます

• await
• 拒否ハンドラー（つまり、2 つの引数）で .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 演算子を使用して、明示的に Promise を無視できます（例: void foo();）。

注: v0.201.0 以降、このルールは unused-promise-in-async-scope と unused-promise-in-sync-scope のルールを取り込みました。