Is Flow still maintained?
Yes — Flow is actively developed by Meta (Facebook) and used in their largest internal codebases including the Meta web stack and React. The public release cadence is steady (multiple releases per year), and 2023–2024 saw major work on Flow Local Type Inference (LTI), which significantly improved inference quality. Flow is no longer the obvious default for new projects — TypeScript has won that mindshare — but it is not deprecated, abandoned, or unsupported. If you maintain a Flow codebase you can rely on Meta's continued investment.
Flow vs TypeScript — what is the practical difference?
Both add static types to JavaScript. TypeScript has the larger ecosystem (DefinitelyTyped, library types shipped in node_modules, every major editor has TS support out of the box), VS Code as its reference editor, and a much larger community. Flow has stronger type narrowing in some cases, exact object types ({| ... |} that disallow extra properties — TS got this with stricter literal types but the syntax differs), variance annotations on properties (+read, -write), opaque types (true nominal types), and tighter integration with the Babel transpiler used at Meta. For new projects, TypeScript is the conventional choice. For existing Flow codebases, migration to TS is possible but non-trivial — and not always necessary.
Does this formatter understand Flow-specific syntax?
It is brace-aware, not Flow-AST aware — but Flow syntax is a strict superset of JavaScript so the brace-and-indent rules apply directly. Type aliases (type X = ...), opaque types (opaque type Id:number=number), exact object types ({| field: T |}), generic constraints (T: Comparable), and variance annotations (+read, -write) all format correctly because they are tokens between braces, not new structural elements. The output is consistent indentation; for full re-printing of complex generic constraints use Prettier with the babel-flow parser.
Will it preserve // @flow pragmas and $FlowFixMe directives?
Yes. Comments are preserved verbatim including the file-header // @flow pragma (which marks a file as Flow-checked), $FlowFixMe[error-code] suppression comments above lines, $FlowExpectedError[code] for tests, and $FlowIgnore. Removing or moving these would change checker behaviour, so the formatter never touches them.
Does it handle React.Component<Props, State> patterns?
Yes. class MyComponent extends React.Component<Props, State> formats as a generic class declaration with the type parameters preserved. Props and State type aliases above the class indent normally. The render() method returns React$Node or React.Node depending on Flow version — both are formatted as ordinary type annotations on the method signature.
How does it handle nullable types (?T) and maybe types?
Flow uses ?T to mean T | null | void (a maybe type that includes both null and undefined), distinct from T | null. The formatter preserves the ? prefix exactly as written. Inside generic constraints, function return types, and class field declarations, the ? marker stays adjacent to its type — there is no space inserted between ? and the type name.
Will this format correctly for files using both Flow and JSX?
Yes — Flow JSX (.js files with // @flow and JSX, no extension change) is just JavaScript with extra type annotations. The brace-aware formatter follows the surrounding curly braces, so a return ( <Component prop={value: string} /> ) gets indented as a function body and the JSX is left intact. For deeper JSX-specific reformatting (attribute wrapping, self-closing normalisation), Prettier remains the better choice.
Is the Flow code I paste sent to your servers?
No. Formatting runs entirely in your browser using JavaScript. Source files containing internal Meta-specific or proprietary type definitions, $FlowFixMe suppressions referencing JIRA tickets, or unreleased features never leave your device. Open DevTools → Network and click Format to verify no requests are made.