Photo by Ylanite Koppens from Pexels

Improvements to Flow in 2019

Andrew Pardoe
Feb 19, 2020 · 4 min read

The retrospective post we shared last year included a roadmap that spans multiple years. It included three focus areas:

  1. Performance: Make Flow scale as O(size of edits) rather than O(size of codebase)
  2. Reliability: Make Flow type analysis trustworthy with respect to run-time semantics, for product safety and developer efficiency.
  3. Language tooling: Make Flow the basis for unified JavaScript tooling to enable language evolution for performance and reliability.

Working from this roadmap, we identified these goals for 2019:

  1. Reduce recheck time and peak memory usage
  2. Improve IDE reliability and responsiveness
  3. Make enhancements to the type system

“Types-first” for recheck performance

Editing and browsing improvements

  • typeCoverage
  • documentHighlight
  • hover
  • completion
  • definition

We made all of these commands far more robust and responsive.

We also made Flow act and feel more responsive when you edit code:

  • Responding to IDE requests during rechecks makes Flow more responsive. Previously, Flow responded to requests sequentially, so it couldn’t respond to even a simple IDE request while rechecking the codebase. Now, if an IDE request comes while Flow is rechecking, Flow will respond to that request with the most recent information available. (Note that this type information may be out-of-date until the recheck completes.)
  • Building upon that work, Flow now shows live errors while you edit your code. Showing type errors before you save your file makes Flow feel more responsive. If your IDE uses the Flow language server via flow lsp, Flow will respond to onChange notifications to build a copy of your modified file. Flow typechecks that modified file and sends errors back to the IDE while you edit your code.

We’ll continue to invest throughout 2020 in improving the reliability and responsiveness of editing and browsing features.

Type system improvements

  • We’ve heard from developers that they almost always want to use exact object types. Exact objects are much safer, more precise, and clearer. We’ve introduced an exact-by-default type syntax. You can read more and find instructions for taking advantage of this syntax in your code in this post from January.
    Inexact object types interact poorly with spread syntax. For example, given a : { p: string, ... }, the type of the expression { q: 0, ...a } is not { q: number, p: string, ...} because a might include some q of an unknown type via width subtyping.
  • Our object model for spreads was imprecise and unsound, leading us to infer mixed and optional properties in cases where we couldn't infer a precise type. Now, Flow will emit an early error letting you know that a precise type cannot be inferred. You can read more about our new object model for spreads in this post. Work done on top of this object model allowed us to make fixes to object spreads. This post helps you identify and fix common errors in spreads.

Looking forward


The official publication for the Flow static type checker