Skip to main content

Lint Rule Reference

all​

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.

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

1// flowlint ambiguous-object-type:error2
3type A = {x: number}; // Errorambiguous-object-typePlease 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).4type B = {x: number, ...} // Ok5type C = {| x: number |} // Ok

deprecated-type​

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

1// flowlint deprecated-type:errorlint-settingRedundant argument. This argument doesn't change any lint settings.2
3type A = Array<bool>; // Errordeprecated-typeDeprecated type. Use boolean instead.

implicit-inexact-object​

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

nested-component​

Triggers when a component is defined directly inside another component or hook. Nested components are problematic because React cannot preserve the state of a nested component across re-renders of the parent — each render creates a brand new component type, so React always unmounts and remounts it.

This lint is enabled as an error by default. It applies to component syntax declarations, which require component_syntax=true in your .flowconfig.

1import * as React from 'react';2
3component Outer() {4  component Inner() { // Errornested-componentComponents may not be nested directly within other components or hooks.5    return null;6  }7  return <Inner />;8}

The lint also fires when a component is defined inside a hook:

1import * as React from 'react';2
3hook useItems() {4  component ItemView() { // Errornested-componentComponents may not be nested directly within other components or hooks.5    return null;6  }7  return ItemView;8}

To fix, move the nested component to the top level:

1import * as React from 'react';2
3component Inner() {4  return null;5}6
7component Outer() {8  return <Inner />;9}

nested-hook​

Triggers when a hook is defined directly inside another component or hook. Nested hooks are problematic because they break the Rules of Hooks — React relies on hooks being called in a consistent order at the top level of a component or hook, and a nested hook definition obscures the call structure.

This lint is enabled as an error by default. It applies to hook syntax declarations, which require component_syntax=true in your .flowconfig.

1import * as React from 'react';2import {useState} from 'react';3
4component Foo() {5  hook useNested() { // Errornested-hookHooks may not be nested directly within other components or hooks.6    return useState();7  }8  return null;9}

The lint also fires when a hook is defined inside another hook:

1import {useState} from 'react';2
3hook useFoo() {4  hook useNested() { // Errornested-hookHooks may not be nested directly within other components or hooks.5    return useState();6  }7  return useNested();8}

To fix, move the nested hook to the top level:

1import * as React from 'react';2import {useState} from 'react';3
4hook useNested() {5  return useState();6}7
8component Foo() {9  useNested();10  return null;11}

libdef-override ≥0.265​

Triggers when a library definition overrides an existing built-in definition. This can happen when a .js.flow library file or a flow-typed stub re-declares a global variable, type, or module that Flow already provides in its builtins. Overriding built-in definitions can lead to surprising behaviors, because the order in which library files are loaded affects which definition wins.

This lint is enabled as an error by default.

There are two forms of this error. The first is a name override, which fires when a library definition re-declares a global variable or type that already exists:

// In a library definition file (.js.flow or [libs])
declare const globalThis: mixed; // Error: overrides built-in globalThis

declare type React$Node = string; // Error: overrides built-in React$Node

The second is a module override, which fires when a library definition re-declares a module that is already declared elsewhere:

// In a library definition file
declare module 'react' { // Error: overrides built-in react module
  declare module.exports: any;
}

This error also fires when the same library file is included twice (for example, if both a directory and its subdirectory are listed in the [libs] section of .flowconfig), causing all declarations in that file to conflict with themselves.

To fix the error, remove the redundant declaration from your library definition. If you intentionally need to override a built-in, you can suppress the error with a $FlowFixMe comment:

// $FlowFixMe[libdef-override]
declare type React$Node = string | number | null;

You can also disable this lint for an entire project in your .flowconfig:

[lints]
libdef-override=off

internal-type​

Triggers when you use an internal Flow type directly in your code. Internal types are implementation details that have public-facing alternatives you should use instead.

This lint is enabled as an error by default.

There are two categories of internal types that trigger this lint:

Dollar-prefixed utility types such as $Omit, $Enum, and $EnumValue have non-dollar equivalents (Omit, Enum, EnumValue):

1type A = $Omit<{x: number, y: number}, 'x'>; // Errorinternal-type$Omit is an internal Flow type. Use Omit instead.2type B = Omit<{x: number, y: number}, 'x'>; // Ok

React$ types such as React$Node and React$ElementConfig should be accessed via the React namespace using dot syntax (React.Node, React.ElementConfig):

1import * as React from 'react';2
3type A = React$Node; // Errorinternal-typeReact$Node is an internal Flow type. Use React.Node instead.4type B = React.Node; // Ok

nonstrict-import​

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

react-intrinsic-overlap​

Triggers when a local definition shares its name with an intrinsic JSX element (such as div, span, or input) and has a type that could be used as a React component. Because JSX treats lowercase element names as intrinsics, writing <div /> always refers to the HTML element, never to a local binding called div. If the local binding is a function, class, abstract component, callable object, or mixed, this overlap is likely a mistake that leads to confusing behavior.

This lint is off by default.

A local function whose name overlaps with an intrinsic:

1// flowlint react-intrinsic-overlap:error2import * as React from 'react';3
4declare function div(): React.Node; // ERRORreact-intrinsic-overlapThe name of intrinsic element div [1] overlaps with a local definition [2] which has a type [1] that can be instantiated as an element. To avoid confusion between this definition and the intrinsic, rename the definition5<div />;

A local variable with a non-component type does not trigger the lint, because there is no ambiguity:

1// flowlint react-intrinsic-overlap:error2import * as React from 'react';3
4const div = 2 / 3;5<div />; // OK

To fix the error, rename the local definition so it does not collide with an intrinsic element name:

1// flowlint react-intrinsic-overlap:error2import * as React from 'react';3
4declare function MyDiv(): React.Node;5<MyDiv />;

sketchy-null​

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.sketchy-null-numberSketchy null check on number [1] which is potentially 0. Perhaps you meant to check for null or undefined [2]?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.

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

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;deprecated-typeDeprecated type. Use boolean instead.3if (x) {}sketchy-null-numberSketchy null check on number [1] which is potentially 0. Perhaps you meant to check for null or undefined [2]?

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

sketchy-number​

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.

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

{showFoo && <Foo />}

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]</>}

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​

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

1// flowlint unclear-type:error2
3declare const a: any; // Errorunclear-typeUnclear type. Using any, Object, or Function types is not safe!4declare const c: Object; // Errorunclear-typeUnclear type. Using any, Object, or Function types is not safe!5declare const d: Function; // Errorunclear-typeUnclear type. Using any, Object, or Function types is not safe!

unnecessary-invariant​

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.

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-invariantThis use of invariant is unnecessary because array type [1] is always truthy.

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; // Errorunnecessary-optional-chainThis use of optional chaining (?.) is unnecessary because foo [1] cannot be nullish or because an earlier ?. will short-circuit the nullish case.

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; // Errorunnecessary-optional-chainThis use of optional chaining (?.) is unnecessary because foo?.bar [1] cannot be nullish or because an earlier ?. will short-circuit the nullish case.

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;

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

unsafe-getters-setters​

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-settersunsafe-getters-settersGetters and setters can have side effects and are unsafe.5  set b(x: number) { a = x; }, // Error: unsafe-getters-settersunsafe-getters-settersGetters and setters can have side effects and are unsafe.6  c: 10,7};

unsafe-object-assign​

Triggers on any use of Object.assign. Flow's support for Object.assign is unsafe, and you should use object spreads instead.

This lint is enabled as an error by default.

Object.assign mutates the first argument in place, which is difficult to track through the type system. The spread syntax ({...obj1, ...obj2}) is a safer alternative because it always creates a new object, and Flow can type it precisely.

1const defaults = {color: 'red', size: 10};2const overrides = {color: 'blue'};3
4const config = Object.assign(defaults, overrides); // Errorunsafe-object-assignFlow's support for Object.assign is unsafe. Use spreads instead.

Use the spread syntax instead:

1const defaults = {color: 'red', size: 10};2const overrides = {color: 'blue'};3
4const config = {...defaults, ...overrides}; // Ok

untyped-import​

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​

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​

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.

A promise can be "used" by...

  • awaiting it
  • Calling .then with a rejection handler (i.e., with two arguments)
  • Calling .catch
  • 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!unused-promisePromise in async scope is unused. Did you mean to await it?7}8
9function baz() {10  foo().catch(err => {console.log(err)}); // ok11  foo(); // errorunused-promisePromise in sync scope is unused. Promises must be handled by calling .then with a rejection handler, .catch, or .finally.12}

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

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