Skip to main content

Lint 规则参考

all​

虽然 all 从技术上来说并不是一个 lint 规则，但这里值得一提。all 为没有明确设置级别的 lint 规则设置默认级别。all 只能作为 .flowconfig 中的第一个条目或作为 --lints 标志中的第一个规则出现。根本不允许在注释中使用它，因为它的语义与预期不同。

¥While all isn't technically a lint rule, it's worth mentioning here. all sets the default level for lint rules that don't have a level set explicitly. all can only occur as the first entry in a .flowconfig or as the first rule in a --lints flag. It's not allowed in comments at all because it would have different semantics than would be expected.

ambiguous-object-type​

当你使用对象类型语法而未明确指定精确性或不精确性时触发。

¥Triggers when you use object type syntax without explicitly specifying exactness or inexactness.

当 exact_by_default 设置为 false 时，将忽略此 lint 设置。

¥This lint setting is ignored when exact_by_default is set to false.

1// flowlint ambiguous-object-type:error2
3type A = {x: number}; // Error4type B = {x: number, ...} // Ok5type C = {| x: number |} // Ok

deprecated-type​

在 bool 类型上触发，该类型只是 boolean 的别名。只需使用 boolean 即可。

¥Triggered on the bool type, which is just an alias for boolean. Just use boolean instead.

1// flowlint deprecated-type:error2
3type A = Array<bool>; // Error

implicit-inexact-object​

与 ambiguous-object-type 类似，但即使 exact_by_default 选项设置为 false 也会触发。

¥Like ambiguous-object-type, except triggers even when the exact_by_default option is set to false.

nonstrict-import​

与 Flow 严格 结合使用。导入非 @flow strict 模块时触发。启用后，@flow strict 模块的依赖也必须是 @flow strict。

¥Used in conjuction with Flow Strict. Triggers when importing a non @flow strict module. When enabled, dependencies of a @flow strict module must also be @flow strict.

sketchy-null​

当你对可为 null/未定义或 falsey 的值进行存在性检查时触发。

¥Triggers when you do an existence check on a value that can be either null/undefined or falsey.

例如：

¥For example:

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.

设置 sketchy-null 设置所有粗略空检查的级别，但对于特定类型有更细粒度的规则。这些都是：

¥Setting sketchy-null sets the level for all sketchy null checks, but there are more granular rules for particular types. These are:

  • sketchy-null-bool

  • sketchy-null-number

  • sketchy-null-string

  • sketchy-null-mixed

  • sketchy-null-bigint

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

¥The type-specific variants are useful for specifying that some types of sketchy null checks are acceptable while others should be errors/warnings. For example, if you want to allow boolean sketchy null checks (for the pattern of treating undefined optional booleans as false) but forbid other types of sketchy null checks, you can do so with this .flowconfig [lints] section:

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

现在

¥and now

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

不报告警告。

¥doesn't report a warning.

抑制一种类型的粗略空检查只会抑制该类型，因此，例如

¥Suppressing one type of sketchy null check only suppresses that type, so, for example

1// flowlint sketchy-null:error, sketchy-null-bool:off2const x: ?(number | bool) = 0;3if (x) {}

第 3 行仍然会出现 sketchy-null-number 错误。

¥would still have a sketchy-null-number error on line 3.

sketchy-number​

当 number 的使用方式如果值为假时可能会导致意外结果时触发。目前，如果 number 出现在以下位置，则会触发此 lint：

¥Triggers when a number is used in a manner which may lead to unexpected results if the value is falsy. Currently, this lint triggers if a number appears in:

  • && 表达式的左侧。

    ¥the left-hand side of an && expression.

作为一个激励人心的例子，考虑一下 React 中的这个常见习惯用法：

¥As a motivating example, consider this common idiom in React:

{showFoo && <Foo />}

这里，showFoo 是一个布尔值，控制是否显示 <Foo /> 元素。如果 showFoo 为真，则计算结果为 {<Foo />}。如果 showFoo 为 false，则计算结果为 {false}，不显示任何内容。

¥Here, showFoo is a boolean which controls whether or not to display the <Foo /> element. If showFoo is true, then this evaluates to {<Foo />}. If showFoo is false, then this evaluates to {false}, which doesn't display anything.

现在假设我们有一个数值，而不是布尔值，它代表帖子的注释数。我们希望显示注释计数，除非没有注释。我们可能天真地尝试做类似于布尔情况的事情：

¥Now suppose that instead of a boolean, we have a numerical value representing, say, the number of comments on a post. We want to display a count of the comments, unless there are no comments. We might naively try to do something similar to the boolean case:

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

如果 count 是 5，则显示 "[5 条注释]"。但是，如果 count 是 0，则显示 "0"，而不是不显示任何内容。（这个问题是 number 特有的，因为 0 和 NaN 是 React 渲染可见结果的唯一虚假值。）这可能是非常危险的：如果这紧跟另一个数值，用户可能会觉得我们已将该值乘以 10！相反，我们应该进行适当的条件检查：

¥If count is, say, 5, then this displays "[5 comments]". However, if count is 0, then this displays "0" instead of displaying nothing. (This problem is unique to number because 0 and NaN are the only falsy values which React renders with a visible result.) This could be subtly dangerous: if this immediately follows another numerical value, it might appear to the user that we have multiplied that value by 10! Instead, we should do a proper conditional check:

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

unclear-type​

当你使用 any、Object 或 Function 作为类型注释时触发。这些类型是不安全的。

¥Triggers when you use any, Object, or Function as type annotations. These types are unsafe.

1// flowlint unclear-type:error2
3declare const a: any; // Error4declare const c: Object; // Error5declare const d: Function; // Error

unnecessary-invariant​

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

¥Triggers when you use invariant to check a condition which we know must be truthy based on the available type information. This is quite conservative: for example, if all we know about the condition is that it is a boolean, then the lint will not fire even if the condition must be true at runtime.

请注意，当我们知道条件始终为 false 时，此 lint 不会触发。使用 invariant() 或 invariant(false, ...) 来抛出应该无法访问的代码是一种常见的习惯用法。

¥Note that this lint does not trigger when we know a condition is always false. It is a common idiom to use invariant() or invariant(false, ...) to throw in code that should be unreachable.

1// flowlint unnecessary-invariant:error2declare function invariant(boolean): void;3
4declare const x: Array<string>; // Array is truthy5invariant(x);

unnecessary-optional-chain​

当你在不需要的地方使用 ?. 时触发。这有两种主要风格。第一个是当左侧不能为空时：

¥Triggers when you use ?. where it isn't needed. This comes in two main flavors. The first is when the left-hand-side cannot be nullish:

1// flowlint unnecessary-optional-chain:error2type Foo = {3  bar: number4}5
6declare const foo: Foo;7foo?.bar; // Error

第二种情况是左侧可能为零，但 ?. 的短路行为无论如何都足以处理它：

¥The second is when the left-hand-side could be nullish, but the short-circuiting behavior of ?. is sufficient to handle it anyway:

1// flowlint unnecessary-optional-chain:error2type Foo = {3  bar: {4    baz: number5  }6}7
8declare const foo: ?Foo;9foo?.bar?.baz; // Error

在第二个示例中，第一次使用 ?. 是有效的，因为 foo 可能无效，但第二次使用 ?. 是不必要的。第二个 ?. (foo?.bar) 的左侧只能因为 foo 为空而为空，而当 foo 为空时，短路可以让我们完全避免第二个 ?.！

¥In the second example, the first use of ?. is valid, since foo is potentially nullish, but the second use of ?. is unnecessary. The left-hand-side of the second ?. (foo?.bar) can only be nullish as a result of foo being nullish, and when foo is nullish, short-circuiting lets us avoid the second ?. altogether!

foo?.bar.baz;

这让读者清楚地知道 bar 不是一个潜在无效的属性。

¥This makes it clear to the reader that bar is not a potentially nullish property.

unsafe-getters-setters​

当你使用 getter 或 setter 时触发。getter 和 setter 可能会产生副作用并且不安全。

¥Triggers when you use getters or setters. Getters and setters can have side effects and are unsafe.

例如：

¥For example:

1// flowlint unsafe-getters-setters:error2let a = 1;3const o = {4  get a() { return a; }, // Error: unsafe-getters-setters5  set b(x: number) { a = x; }, // Error: unsafe-getters-setters6  c: 10,7};

untyped-import​

当你从无类型文件导入时触发。从非类型化文件导入会导致这些导入的类型为 any，这是不安全的。

¥Triggers when you import from an untyped file. Importing from an untyped file results in those imports being typed as any, which is unsafe.

untyped-type-import​

当你从非类型化文件导入类型时触发。从无类型文件导入类型会产生 any 别名，这通常不是预期的行为。启用此 lint 会额外关注这种情况，并且可以通过限制隐式 any 类型的传播来帮助提高类型化文件的 Flow 覆盖。

¥Triggers when you import a type from an untyped file. Importing a type from an untyped file results in an any alias, which is typically not the intended behavior. Enabling this lint brings extra attention to this case and can help improve Flow coverage of typed files by limiting the spread of implicit any types.

unused-promise​

当 Promise 未使用时触发。这可能很危险，因为错误可能无法处理，并且代码可能无法按所需顺序执行。

¥Triggers when a Promise is unused. This can be dangerous, because errors are potentially unhandled, and the code may not execute in the desired order.

promise 可以通过...实现 "用过的"

¥A promise can be "used" by...

  • await 了它

    ¥awaiting it

  • 使用拒绝处理程序调用 .then（即使用两个参数）

    ¥Calling .then with a rejection handler (i.e., with two arguments)

  • 调用 .catch

    ¥Calling .catch

  • 调用 .finally

    ¥Calling .finally

  • 将其存储在变量中，将其传递给函数等。

    ¥Storing it in a variable, passing it to a function, etc.

例如：

¥For example:

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(); // error12}

你可以使用 void 运算符（例如 void foo();）显式忽略 promise。

¥You can explicitly ignore the promise with the void operator (e.g., void foo();).

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

¥Note: As of v0.201.0, this rule subsumed the unused-promise-in-async-scope and unused-promise-in-sync-scope rules.