JavaScript - Flow

see also JavaScript - ESLint.



install Flow locally

$ yarn add flow-bin --dev

install babel-preset-flow

$ yarn add babel-preset-flow --dev
// .babelrc

  "presets": ["flow"]

Now, Babel will always strip away Flow source and your JS runtime can interpret the code. This is especially important for feeding into ESlint.

install eslint-plugin-flowtype

$ yarn add eslint-plugin-flowtype --dev
# .eslintrc.yml

  - 'plugin:flowtype/recommended'
  - flowtype

there will be some warnings about unused variables whenever you write type declarations. The eslint plugin eslint-plugin-flowtype will mute those warnings.

I don’t see any warnings mentioned above but this plugin is still useful: say, it adds ESLint rule to check for presence of Flow declaration (// @flow) if type annotation is added to the file - ESLint will complain if declaration is missing:

Type annotations require valid Flow declaration.

this rule flowtype/no-types-missing-file-annotation must be a part of recommended configuration (plugin:flowtype/recommended).

eslint-plugin-flowtype plugin is ESLint plugin - it’s not meant to check for Flow type errors or to show them! checking for type errors is performed by flow binary (use either flow status in terminal or flow syntastic JS checker in Vim).


generate Flow config

$ yarn run flow init

this will create empty .flowconfig in the project root.


flag files to be checked with // @flow

according to Flow documentation @flow annotation can be placed anywhere in JS file - it just instructs Flow to check current file.

but in my case ONLY the files with @flow annotation at the very beginning of the file are checked by Flow.

it’s possible to use @flow weak for weak mode - say, it allows not to specify types for all parameters.

ignore Flow errors on a one-off basis

// $FlowFixMe
'foo' + {};

add Flow script

// package.json

"scripts": {
  "flow": "flow"

now Flow can be run using any of these commands:

$ yarn run flow


it’s not required to add flow script - everything works as is.

run Flow

Vim integration

[NOT USED] syntastic

NOTE: Flow must be installed globally for syntastic flow checker to be available (like for ESLint).

$ yarn global add flow-bin
" ~/.vim/vimrc

let g:syntastic_aggregate_errors = 1

let g:syntastic_javascript_flow_exe = '$(npm bin)/flow focus-check'
let g:syntastic_javascript_checkers = ['flow']

another way to integrate Flow with syntastic is to feed file content into flow check-contents - but now that flow focus-check command is added this method seems to be obsolete.

[NOT USED] vim-flow

syntastic already performs linting of JS files so linting provided by this plugin (automatic or manual checks - via FlowMake command) seems to be excessive.

still FlowJumpToDef and FlowType commands might be useful - just make sure to disable automatic checks on save.


unlike syntastic, ALE doesn’t require Flow to be installed globally - it finds Flow script ($(npm bin)/flow) somehow.

" ~/.vim/vimrc

let g:ale_linters = {
      \   'javascript': ['flow']
      \ }

style guide



function and property variance


One function type is a subtype of another when it is safe to use a function of one type in a context that expects a function of a different type. It is safe to substitute a function f for a function g (substitute function g with function f) if f accepts a more general type of arguments and returns a more specific type than g.

In other words, the type constructor is contravariant in the input type and covariant in the output type.

Flow has contravariant inputs (accepts less specific types to be passed in), and covariant outputs (allows more specific types to be returned).

By default, object properties are invariant, which allow both reads and writes, but are more restrictive in the values they accept (when they are declared - my note).

Type Annotations

JavaScript classes in Flow operate both as a value and a type. You write classes the same way you would without Flow, but then you can use the name of the class as a type:

class MyClass { // … }

let myInstance: MyClass = new MyClass();

This is because classes in Flow are nominally typed.

use interface to add structural typing for classes.

Classes (when being used as a type), type aliases, and interfaces with generics are parameterized (all require that you pass type arguments). Functions and function types do not have parameterized generics.

say, React.Component<Props, State> is a parameterized generic class type (it’s necessary to pass Props and State types when using this class type).

Union types requires one in, but all out.

Intersection types require all in, but one out.

When you create an intersection of object types, you merge all of their properties together.

Type System

The function subtyping rule is this: a function type B is a subtype of a function type A if and only if B’s inputs are a superset of A’s, and B’s outputs are a subset of A’s.

Flow uses structural typing for objects and functions, but nominal typing for classes.

If you wanted to use a class structurally you could do that by mixing them with objects as interfaces.

This is a kind of subtyping commonly referred to as “width subtyping” because a type that is “wider” (i.e., has more properties) is a subtype of a narrower type.

Exact object types disable width subtyping, and do not allow additional properties to exist.



a very useful example of using Flow types (with their corresponding prop types) from of babel-plugin-react-flow-props-to-prop-types plugin:

type FooProps = {
  an_optional_string?: string,
  a_number: number,
  a_boolean: boolean,
  a_generic_object: Object,
  array_of_strings: Array<string>,
  instance_of_Bar: Bar,
  anything: any,
  mixed: mixed,
  one_of: 'QUACK' | 'BARK' | 5,
  one_of_type: number | string,
  nested_object_level_1: {
    string_property_1: string,
    nested_object_level_2: {
      nested_object_level_3: {
        string_property_3: string,
      string_property_2: string,
  should_error_if_provided: void,
  intersection: {foo: string} & {bar: number} & Qux,
  some_external_type: SomeExternalType,
  some_external_type_intersection: {foo: string} & SomeExternalType,



Using the /flow-typed directory for libdefs is a convention that enables Flow to JustWork™ out of the box and encourages consistency across projects that use Flow

=> it’s not necessary to specify flow-typed/ as libdefs directory explicitly using [libs] section of .flowconfig.


$ yarn run flow --show-all-branches

output gives detailed information about what Flow is complaining about.


using with GraphQL


Flow typechecks the whole node_modules/ directory


the best solution so far is to install library definitions from flow-typed.

Required module not found

if the whole node_modules/ directory is ignored in .flowconfig, Flow cannot find some modules like react-native or react-redux.

Experimental decorator usage

# .flowconfig


Property not found


this is usually a problem when adding new properties to a sealed object.

to fix it cast object to Object (it makes this object unsealed?):

(object: Object).newProp = 'foo';

for class fields in particular this error can be fixed in 2 ways:

Unexpected super class type: CallExpression

packager log and emulator window:

SyntaxError: <APP_DIR>/node_modules/react-native/Libraries/Network/XMLHttpRequest.js:
Unexpected super class type: CallExpression

and other cryptic errors that seem to be Flow related.


remove react-flow-props-to-prop-types package.

  // .babelrc

    "plugins": [
-     "react-flow-props-to-prop-types"
$ yarn remove babel-plugin-react-flow-props-to-prop-types --dev