delimiter-dangle

The --fix option on the command line automatically fixes problems reported by this rule.

Enforces consistent use of trailing commas in Object and Tuple annotations.

This rule takes two arguments which both mirror ESLint's default comma-dangle rule.
The first argument is for Object and Tuple annotations.
The second argument is used for Interface annotations as ESLint's default comma-dangle doesn't apply to interfaces - this defaults to whatever the first argument is.

If it is 'never' then a problem is raised when there is a trailing comma.

If it is 'always' then a problem is raised when there is no trailing comma.

If it is 'always-multiline' then a problem is raised when there is no trailing comma on a multi-line definition, or there is a trailing comma on a single-line definition.

If it is 'only-multiline' then a problem is raised when there is a trailing comma on a single-line definition. It allows, but does not enforce, trailing commas on multi-line definitions.

generic-spacing

This rule takes one argument. If it is 'never' then a problem is raised when there is a space surrounding the generic type parameters. If it is 'always' then a problem is raised when there is no space surrounding the generic type parameters.

The default value is 'never'.

The following patterns are considered problems:

type X = Promise< string>
// Message: There must be no space at start of "Promise" generic type annotation
// Options: ["never"]
type X = Promise< string>
// Message: There must be no space at start of "Promise" generic type annotation
type X = FooBar<string >
// Message: There must be no space at end of "FooBar" generic type annotation
type X = Promise< string >
// Message: There must be no space at start of "Promise" generic type annotation
// Message: There must be no space at end of "Promise" generic type annotation
type X = Promise< (foo), bar, (((baz))) >
// Message: There must be no space at start of "Promise" generic type annotation
// Message: There must be no space at end of "Promise" generic type annotation
// Options: ["always"]
type X = Promise<string >
// Message: There must be a space at start of "Promise" generic type annotation
// Options: ["always"]
type X = FooBar< string>
// Message: There must be a space at end of "FooBar" generic type annotation
// Options: ["always"]
type X = Promise<string>
// Message: There must be a space at start of "Promise" generic type annotation
// Message: There must be a space at end of "Promise" generic type annotation
// Options: ["always"]
type X = Promise<(foo), bar, (((baz)))>
// Message: There must be a space at start of "Promise" generic type annotation
// Message: There must be a space at end of "Promise" generic type annotation
// Options: ["always"]
type X = FooBar< string >
// Message: There must be one space at start of "FooBar" generic type annotation
// Options: ["always"]
type X = FooBar< string >
// Message: There must be one space at end of "FooBar" generic type annotation
// Options: ["always"]
type X = Promise< (foo), bar, (((baz))) >
// Message: There must be one space at start of "Promise" generic type annotation
// Message: There must be one space at end of "Promise" generic type annotation

no-mutable-array

The --fix option on the command line automatically fixes problems reported by this rule.

Requires use of $ReadOnlyArray instead of just Array or array shorthand notation. $ReadOnlyArray is immutable array collection type and the superclass of Array and tuple types in Flow. Use of $ReadOnlyArray instead of Array can solve some "problems" in typing with Flow (e.g., 1, 2).

General reasons for using immutable data structures:

They are simpler to construct, test, and use

They help to avoid temporal coupling

Their usage is side-effect free (no defensive copies)

Identity mutability problem is avoided

They always have failure atomicity

They are much easier to cache

Note that initialization of a variable with an empty array is considered valid (e.g., const values: Array<string> = [];). This behavior resembles the behavior of Flow's unsealed objects, as it is assumed that empty array is intended to be mutated.

no-weak-types

Warns against weak type annotations any, Object and Function.
These types can cause flow to silently skip over portions of your code,
which would have otherwise caused type errors.

This rule optionally takes one argument, an object to configure which type warnings to enable. By default, all of the
warnings are enabled. e.g. to disable the any warning (allowing it to exist in your code), while continuing to warn
about Object and Function:

require-compound-type-alias

Requires to make a type alias for all union and intersection types. If these are used in "raw" forms it might be tempting to just copy&paste them around the code. However, this brings sort of a source code pollution and unnecessary changes on several parts when these compound types need to be changed.