Jeff Morrison jeffmo

We removed Promise.prototype.done a while back because it's not actually in the JS spec. The hacky workaround for getting it back would be to copy the promise definition here into your own libdef file.

Specifically: Copy it (only the declare class Promise { ... } definition) into some file called, say, promise-override.js and put that file into a directory called flow-typed in the same directory as your .flowconfig file. From there you can update your override to include a definition for done().

(The flow-typed directory is a special directory that Flow assumes contains library definitions if it exists)

Parser

/src/parser/spider_monkey_ast.ml: The type definitions for the AST. Tries to stay very close to ESTree
/src/parser/lexer_flow.mll: The ocamllex lexer logic
/src/parser/parser_flow.ml: The recursive descent JS parser

Inference

/src/typing/type_inference_js.ml: Contains the "entry point" for inference (Function called infer_ast).
/src/typing/statement.ml: Most of the inference logic (runs through the AST and generates the initial constraints)

A few reasons why we decided to build Flow

tldr: Flow is built to find a lot more kinds of bugs than what TypeScript is built for.

Flow avoids as much gratuitous unsoundness as possible in order to find more bugs: It never infers any, it models variance for objects/functions/type parameters soundly (this is critical), it minimizes type precision loss, it has sound support for various dynamic features with inference (Function.prototype.bind()/Function.prototype.call()/Object.assign()/etc), etc.

Flow infers and understands more kinds of types with fewer annotations. Extensive inference was important to us for easing the process of converting untyped code without missing errors as much as possible. It also helps reduce boilerplate when writing new, typed code. You get to decide if and when you want to express types in your code (with type annotations), but Flow will pick things up from there without much worry of losing type info.

Flow is built on top of a more general level of code understandi

	// @flow

	import {connect} from './connect';

	type Props = {
	name: string,
	magic: number,
	};

	export function MyComponent(props: Props) {

	// @flow

	import {connect} from './connect';

	type Props = {
	name: string,
	magic: number,
	};

	export function MyComponent(props: Props) {

	// @flow

	import {connect} from './connect';

	type Props = {
	name: string,
	magic: number,
	};

	export function MyComponent(props: Props) {

	/* flow-typed/lib.js */

	type JSXHelper<T> = Class<React$Component<{}, T, any>>;

	// $JSXIntrinsics is special and magic.
	// This declares the types for `div` and `span`
	type $JSXIntrinsics = {
	div: JSXHelper<{id: string}>,
	span: JSXHelper<{id: string, class: string}>,
	};

	/**
	* This file provides type definitions for use with the Flow type checker.
	*
	* An important caveat when using these definitions is that the types for
	* `Iterable.Keyed`, `Iterable.Indexed`, `Seq.Keyed`, and so on are stubs.
	* When referring to those types, you can get the proper definitions by
	* importing the types `KeyedIterable`, `IndexedIterable`, `KeyedSeq`, etc.
	* For example,
	*
	* import { Seq } from 'immutable'

	// @flow

	const K = require('./main');

	new K({errorHandler(err) { err.code; }});

	export default (async function() => {
	return 42;
	})();