This post announced component and hook syntax for React when it was introduced. For current syntax and behavior, see the Component Syntax and Hook Syntax documentation.
Flow is excited to announce Component Syntax, adding first-class support for React primitives such as components and hooks to the Flow language. These features bring improved ergonomics, expressiveness, and static enforcement for many of the Rules of React.
This post announced conditional types when it was introduced. For current syntax and behavior, see the Conditional Types documentation.
Conditional types allow you to choose between two different output types by inspecting an input type.
This post announced user-defined type guards when it was introduced. For current syntax and behavior, see the Type Guards documentation.
Flow now lets you define a function that encodes a type predicate over its parameter.
This post announced the as type casting syntax when it was introduced. For current syntax and behavior, see the Type Casting documentation.
To make it easier for new users to get started with Flow, we’re updating our type casting syntax to use 'as'.
We’ve refreshed our documentation, and added the ability to configure options and lints in Try Flow!
This post announced new tuple type features when it was introduced. For current syntax and behavior, see the Tuples documentation.
Labeled tuple elements, read-only tuples, optional tuple elements, tuple spread, and more.
This post announced unused Promise detection when it was introduced. For current syntax and behavior, see the Linting documentation.
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.
This post announced Partial, Required, and catch annotations when it was introduced. For current syntax and behavior, see the Utility Types documentation.
Starting in Flow version 0.201, make an object type’s fields all optional using Partial<ObjType> (use instead of the unsafe $Shape),
and make an object type’s optional fields required with Required<ObjType>.
This post announced exact object types becoming the default when it was introduced. For current syntax and behavior, see the Objects documentation.
We announced 5 years ago a plan to eventually make exact object types the default. We are now proceeding with this plan.
This post announced local type inference when it was introduced. For current syntax and behavior, see the Annotation Requirement documentation.
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.
This post announced improved handling of the empty object when it was introduced. For current syntax and behavior, see the Objects documentation.
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.
This post announced increased annotation requirements for functions and classes when it was introduced. For current syntax and behavior, see the Annotation Requirement documentation.
Flow will now require more annotations to functions and classes.
This post announced the constrained writes rule when it was introduced. For current syntax and behavior, see the Variables documentation.
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.
This post announced local type inference when it was introduced. For current syntax and behavior, see the Annotation Requirement documentation.
We're replacing Flow’s current inference engine with a system that behaves more predictably and can be reasoned about more locally.
This post announced Flow Enums when it was introduced. For current syntax and behavior, see the Flow Enums documentation.
Flow Enums are an opt-in feature which allow you to define a fixed set of constants which create their own type.
This post announced TypeScript Enums vs. Flow Enums when it was introduced. For current syntax and behavior, see the Flow Enums documentation.
A comparison of the enums features of TypeScript and Flow.
This post announced indexed access types when it was introduced. For current syntax and behavior, see the Indexed Access Types documentation.
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.
This post announced sound typing for this when it was introduced. For current syntax and behavior, see the Functions documentation.
Improvements in soundness for this-typing in Flow, including the ability to annotate this on functions and methods.
This post described Flow's direction and open source engagement at the time of writing and may not reflect the current state of the project.
An update on Flow's direction and open source engagement.
This post announced Types-First becoming the only supported mode when it was introduced. Syntax and behavior may have changed since this post was written.
Types-First will become the only mode in Flow in v0.143 (mid Jan 2021).
This post announced improved handling of generic types when it was introduced. For current syntax and behavior, see the Generics documentation.
Flow has improved its handling of generic types by banning unsafe behaviors previously allowed and clarifying error messages.
This post announced the Types-First architecture when it was introduced. Syntax and behavior may have changed since this post was written.
Flow Types-First mode is out! It unlocks Flow’s potential at scale by leveraging fully typed module boundaries. Read more in our latest blog post.
This post announced more specific error suppressions when it was introduced. For current syntax and behavior, see the Error Suppressions documentation.
We’re improving Flow error suppressions so that they don’t accidentally hide errors.
This post described the Flow team's plans for 2020 at the time of writing and may not reflect the current state of the project.
Learn about how Flow will improve in 2020.
This post described improvements to Flow in 2019 at the time of writing and may not reflect the current state of the project.
Take a look back at improvements we made to Flow in 2019.
This post described upgrading to exact-by-default object type syntax at the time of writing. For current syntax and behavior, see the Objects documentation.
Object types will become exact-by-default. Read this post to learn how to get your code ready!
This post described object spread errors at the time of writing. For current syntax and behavior, see the Objects documentation.
Fixes to object spreads will expose errors in your codebase. Read more about common errors and how to fix them.
This post announced live Flow errors in IDEs when it was introduced. For current syntax and behavior, see the Editors documentation.
Live errors while you type makes Flow feel faster in your IDE!
This post announced changes to object spreads when it was introduced. For current syntax and behavior, see the Objects documentation.
Changes are coming to how Flow models object spreads! Learn more in this post.
This post described upgrading Flow codebases at the time of writing. The migration steps may no longer be relevant.
Having trouble upgrading from 0.84.0? Read about how the Flow team upgrades Flow at Facebook!
This post announced Flow performance improvements when it was introduced. Syntax and behavior may have changed since this post was written.
Flow 0.92 improves on the Flow developer experience.
This post described the Flow team's work in 2018 at the time of writing and may not reflect the current state of the project.
Take a look at what the Flow was up to in 2018.
This post announced React.AbstractComponent when it was introduced. For current syntax and behavior, see the Component Types documentation.
We made some major changes to our React model to better model new React components. Let's talk about React.AbstractComponent!
This post announced required annotations when it was introduced. For current syntax and behavior, see the Annotation Requirement documentation.
Flow will be asking for more annotations starting in 0.85.0. Learn how to deal with these errors in our latest blog post.
This post described exact objects by default at the time of writing. For current behavior, see the Objects documentation.
We are changing object types to be exact by default. We'll be releasing codemods to help you upgrade.
This post announced errors on unknown property access in conditionals when it was introduced. For current syntax and behavior, see the Refinements documentation.
TL;DR: Starting in 0.68.0, Flow will now error when you access unknown properties in conditionals.
This post announced improved error messages when it was introduced. For current syntax and behavior, see the Error Messages documentation.
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.
This post announced Flow support in Recompose when it was introduced. Syntax and behavior may have changed since this post was written.
One month ago Recompose landed an official Flow library definition. The definitions were a long time coming, considering the original PR was created by @GiulioCanti a year ago.
This post announced private object properties using opaque types when it was introduced. For current syntax and behavior, see the Opaque Types documentation.
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.
This post announced React support in Flow when it was introduced. For current syntax and behavior, see the React documentation.
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.
This post announced Flow's linter when it was introduced. For current syntax and behavior, see the Linting documentation.
Flow’s type information is useful for so much more than just proving your programs are correct. Introducing Flow linter.
This post announced opaque type aliases when it was introduced. For current syntax and behavior, see the Opaque Types documentation.
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!
This post announced strict function call arity when it was introduced. For current syntax and behavior, see the Functions documentation.
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.
This post announced flow-typed when it was introduced. For current syntax and behavior, see the Library Definitions documentation.
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:
This post announced property variance when it was introduced. For current syntax and behavior, see the Variance documentation.
The next release of Flow, 0.34, will include a few important changes to object types:
This post announced Windows support when it was introduced. For current syntax and behavior, see the Getting Started documentation.
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!
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.
This post announced union and intersection types when it was introduced. For current syntax and behavior, see the Unions and Intersections documentation.
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].
This post announced Flow v0.21.0. For current features and behavior, see the Flow documentation.
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!
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!
This post announced Flow v0.19.0. For current features and behavior, see the Flow documentation.
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!
@noflowFlow 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.
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.
This post announced generator types when it was introduced. For current syntax and behavior, see the Functions documentation.
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.