Skip to main content

As of v0.201.0, Flow can now lint against unused/floating Promises. Unused promises can be dangerous, because errors are potentially unhandled, and the code may not execute in the intended order. They are usually mistakes that Flow is perfectly positioned to warn you about.

Local Type Inference makes Flow’s inference behavior more reliable and predictable, by modestly increasing Flow’s annotation requirement, bringing it closer to industry standard and capitalizing on increasingly strongly and explicitly typed codebases.

Flow handled the empty object literal {} in a permissive but unsafe way. The fix described in this post increases safety and predictability, but requires using different patterns and behavior.

Flow is releasing a new language rule that determines the type of an unannotated variable at its initialization. Along with these new rules come several fixes to soundness bugs that were causing refinements to not be invalidated.

Flow Enums are an opt-in feature which allow you to define a fixed set of constants which create their own type.

Flow’s Indexed Access Types are a new type annotation syntax that allows you to get the type of a property from an object, array, or tuple type.

Improvements in soundness for this-typing in Flow, including the ability to annotate this on functions and methods.

Fixes to object spreads will expose errors in your codebase. Read more about common errors and how to fix them.

Having trouble upgrading from 0.84.0? Read about how the Flow team upgrades Flow at Facebook!

We made some major changes to our React model to better model new React components. Let's talk about React.AbstractComponent!

Flow will be asking for more annotations starting in 0.85.0. Learn how to deal with these errors in our latest blog post.

Over the last year, the Flow team has been slowly auditing and improving all the possible error messages generated by the type checker. In Flow 0.66 we’re excited to announce a new error message format designed to decrease the time it takes you to read and fix each bug Flow finds.

In the last few weeks, a proposal for private class fields in Javascript reached stage 3. This is going to be a great way to hide implementation details away from users of your classes. However, locking yourself in to an OOP style of programming is not always ideal if you prefer a more functional style. Let’s talk about how you can use Flow’s opaque type aliases to get private properties on any object type.

The first version of Flow support for React was a magical implementation of React.createClass(). Since then, React has evolved significantly. It is time to rethink how Flow models React.

Flow’s type information is useful for so much more than just proving your programs are correct. Introducing Flow linter.

Do you ever wish that you could hide your implementation details away from your users? Find out how opaque type aliases can get the job done!

Strict Checking of Function Call Arity

One of Flow's original goals was to be able to understand idiomatic JavaScript. In JavaScript, you can call a function with more arguments than the function expects. Therefore, Flow never complained about calling a function with extraneous arguments.

We are changing this behavior.

Introducing Flow-Typed

Having high-quality and community-driven library definitions (“libdefs”) are important for having a great experience with Flow. Today, we are introducing flow-typed: A repository and CLI tool that represent the first parts of a new workflow for building, sharing, and distributing Flow libdefs.

The goal of this project is to grow an ecosystem of libdefs that allows Flow's type inference to shine and that aligns with Flow's mission: To extract precise and accurate types from real-world JavaScript. We've learned a lot from similar efforts like DefinitelyTyped for TypeScript and we want to bring some of the lessons we've learned to the Flow ecosystem.

Here are some of the objectives of this project:

Property Variance and Other Upcoming Changes

The next release of Flow, 0.34, will include a few important changes to object types:

  • property variance,
  • invariant-by-default dictionary types,
  • covariant-by-default method types,
  • and more flexible getters and setters.

Windows Support is Here!

We are excited to announce that Flow is now officially available on 64-bit Windows! Starting with Flow v0.30.0, we will publish a Windows binary with each release. You can download the Windows binary in a .zip file directly from the GitHub releases page or install it using the flow-bin npm package. Try it out and report any issues you come across!

![Windows Support GIF]({{ site.baseurl }}/static/windows.gif)

Getting Flow working on Windows was not easy, and it was made possible by the hard work of Grégoire, Çagdas and Fabrice from OCamlPro.

New Implementation of Unions and Intersections

Summary

Before Flow 0.28, the implementation of union/intersection types had serious bugs and was [the][gh1759] [root][gh1664] [cause][gh1663] [of][gh1462] [a][gh1455] [lot][gh1371] [of][gh1349] [weird][gh842] [behaviors][gh815] you may have run into with Flow in the past. These bugs have now been addressed in [a diff landing in 0.28][fotu].

Version 0.21.0

Yesterday we deployed Flow v0.21.0! As always, we've listed out the most interesting changes in the Changelog. However, since I'm on a plane and can't sleep, I thought it might be fun to dive into a couple of the changes! Hope this blog post turns out interesting and legible!

JSX Intrinsics

If you're writing JSX, it's probably a mix of your own React Components and some intrinsics. For example, you might write

render() {
return <div><FluffyBunny name="Fifi" /></div>;
}

In this example, FluffyBunny is a React Component you wrote and div is a JSX intrinsic. Lower-cased JSX elements are assumed to be intrinsics by React and by Flow. Up until Flow v0.21.0, Flow ignored intrinsics and gave them the type any. This meant Flow let you set any property on JSX intrinsics. Flow v0.21.0 will, by default, do the same thing as v0.20.0, However now you can also configure Flow to properly type your JSX intrinsics!

Version-0.19.0

Flow v0.19.0 was deployed today! It has a ton of changes, which the Changelog summarizes. The Changelog can be a little concise, though, so here are some longer explanations for some of the changes. Hope this helps!

@noflow

Flow is opt-in by default (you add @flow to a file). However we noticed that sometimes people would add Flow annotations to files that were missing @flow. Often, these people didn't notice that the file was being ignored by Flow. So we decided to stop allowing Flow syntax in non-Flow files. This is easily fixed by adding either @flow or @noflow to your file. The former will make the file a Flow file. The latter will tell Flow to completely ignore the file.

Declaration files

Files that end with .flow are now treated specially. They are the preferred provider of modules. That is if both foo.js and foo.js.flow exist, then when you write import Foo from './foo', Flow will use the type exported from foo.js.flow rather than foo.js.

We imagine two main ways people will use .flow files.

Typing Generators with Flow

Flow 0.14.0 included support for generator functions. Generator functions provide a unique ability to JavaScript programs: the ability to suspend and resume execution. This kind of control paves the way for async/await, an upcoming feature already supported by Flow.

Version-0.17.0

Today we released Flow v0.17.0! The first thing you may notice is that we changed the way we display errors at the command line. The new errors look like this:

![New error format]({{ site.baseurl }}/static/new_error_format_v0_17_0.png)

This should hopefully help our command line users understand many errors without having to refer to their source code. We'll keep iterating on this format, so tell us what you like and what you don't like! Thanks to @frantic for building this feature!

There are a whole bunch of other features and fixes in this release! Head on over to our Release for the full list!

Version-0.16.0

On Friday we released Flow v0.16.0! We had some major perf improvements that we wanted to get into a release, plus let/const support was ready (thanks again @samwgoldman)!

As always, the Changelog is best at summing up the big changes.

Version-0.15.0

Today we released Flow v0.15.0! A lot has changed in the last month and we're excited to get the hard work of all our contributors in front of people! Big thanks to everyone who contributed to this release!

Check out the Changelog to see what's new.

Version-0.14.0

It has come to our attention that not everyone obsessively checks GitHub for Flow releases. This came as a surprise, but we would like to support these users too. Therefore, we will start announcing each Flow release on the blog, starting with this release.

So here is Flow v0.14.0! Check out the Changelog for the canonical list of what has changed.

Announcing Disjoint Unions

Sometimes programs need to deal with different kinds of data all at once, where the shape of the data can be different based on what kind of data the code is looking at. This kind of programming is so common in functional programming languages that almost all such languages come with a way of:

  • Specifying such data by a set of disjoint cases, distinguished by “tags”, where each tag is associated with a different “record” of properties. (These descriptions are called “disjoint union” or “variant” types.)
  • Doing case analysis on such data, by checking tags and then directly accessing the associated record of properties. (The common way to do such case analysis is by pattern matching.)

Examples of programs that analyze or transform such data range from compilers working with abstract syntax trees, to operations that may return exceptional values, with much more in between!

As of Flow 0.13.1 it is now possible to program in this style in JavaScript in a type-safe manner. You can define a disjoint union of object types and do case analysis on objects of that type by switching on the value of some common property (called a "sentinel") in those object types.

Flow's syntax for disjoint unions looks like:

type BinaryTree =
{ kind: "leaf", value: number } |
{ kind: "branch", left: BinaryTree, right: BinaryTree }

function sumLeaves(tree: BinaryTree): number {
if (tree.kind === "leaf") {
return tree.value;
} else {
return sumLeaves(tree.left) + sumLeaves(tree.right);
}
}