Skip to content

Instantly share code, notes, and snippets.

Jeff Morrison jeffmo

  • Cambridge, MA
Block or report user

Report or block jeffmo

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View a.js
// @flow
import {connect} from './connect';
type Props = {
name: string,
magic: number,
};
export function MyComponent(props: Props) {
View a.js
// @flow
import {connect} from './connect';
type Props = {
name: string,
magic: number,
};
export function MyComponent(props: Props) {
View a.js
// @flow
import {connect} from './connect';
type Props = {
name: string,
magic: number,
};
export function MyComponent(props: Props) {
View interesting.js
export default (async function() => {
return 42;
})();
View lib.js
/* 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}>,
};
View dep.js
// @flow
const K = require('./main');
new K({errorHandler(err) { err.code; }});
View a.md

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)

View immutable.js.flow
/**
* 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'
View flowFileStructure.md

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)
View a.md

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

You can’t perform that action at this time.