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 或假值的变量进行存在性检查时触发。

例如

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

特定于类型的变体对于指定某些类型的可疑 null 检查是可以接受的，而其他类型应该为错误/警告很有用。例如，如果您想允许布尔可疑 null 检查（用于将未定义的可选布尔值视为 false 的模式），但禁止其他类型的可疑 null 检查，您可以使用此 .flowconfig [lints] 部分

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

现在

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

不会报告警告。

抑制一种类型的可疑 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

当您使用 invariant 检查我们根据可用类型信息知道必须为真的条件时触发。这是相当保守的：例如，如果我们只知道条件是 boolean，那么即使条件在运行时必须为 true，lint 也不会触发。

请注意，当我们知道条件始终为 false 时，此 lint 不会触发。在应该无法到达的代码中使用 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 别名，这通常不是预期行为。启用此 lint 会让您更加关注这种情况，并可以通过限制隐式 any 类型的传播来帮助提高类型化文件的 Flow 覆盖率。

unused-promise

当 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();）显式忽略 promise。

注意：从 v0.201.0 开始，此规则取代了 unused-promise-in-async-scope 和 unused-promise-in-sync-scope 规则。