What we’re building in 2020
Our plan for 2020 covers three areas:
- Improve the capabilities and responsiveness of our VS Code editing and browsing experience
- Make our type system more simple, expressive, and correct
- Reduce our peak memory usage while holding the line on recheck performance
VS Code editing and browsing
Flow provides a language server to provide rich editing and code browsing features such as in-editor diagnostics (type errors), autocomplete and “go to definition”. While our focus is on providing a best-in-class experience in VS Code, any editor that uses LSP can take advantage of Flow’s language server.
In 2020 we’ll focus on two kinds of investments in our editing and browsing experience. First, we’ll continue to improve the reliability and responsiveness of our IDE features. Second, we’ll add support for some top-requested IntelliSense features.
The Flow language server doesn’t always respond immediately because it needs to initialize when first starting up, and sometimes needs to restart after events like large rebases. Most language features require that the Flow server be running continuously while you edit code. Where possible, we’ll convert our edit and browse requests to make them possible to complete without requiring the server. We’ll also continue to reduce the situations where the Flow server needs to restart itself.
A second set of investments come from adding support for the top-requested IntelliSense features: parameter info, quick info, and quick fixes.
- Parameter info includes signature help — the number and types of parameters expected — displayed as you type the function call. We’ll also show documentation about the parameter extracted from JSDoc comments in the code.
- Quick info shows the declaration when you hover over an identifier in your code. Flow already shows function signatures. We’ll improve the formatting for quick info and add documentation comments similar to parameter info.
- We’ve just added our first quick fix feature — a “Did You Mean?” that suggests corrections to your code as you type. For example, if you write
foo.baron an object
foothat doesn’t have a field named
barbut does have a field named
baz, the quick fix will apply that suggestion. We're also investigating adding Flow error suppressions and automatic generation of static
Enhanced type system
We believe that a thoughtfully designed type system that is simple, expressive, and correct can provide a better experience for developers.
- Simple: can developers predict how Flow would behave on their code?
- Expressive: can developers do what they need to do without being blocked by Flow?
- Correct: can developers rely on Flow to help them avoid common costly mistakes?
- Use of
thisin functions and methods often leads to unchecked code, because it can be implicitly typed as
anyis unsafe and prevents Flow from reporting errors. Implementing typing for
thiswill allow Flow to check code that uses
- Unsealed object types are used to model empty object literals and properties on functions. Unsealed objects allow new properties to be written at any time. They’re useful for scenarios like enabling object initialization across multiple statements. But Flow doesn’t check reads from unsealed objects with no matching writes. We’ll work on addressing this unsoundness, by carefully tracking common initialization patterns.
- Many of Flow’s utility types, such as
$PropertyType, don't reflect the semantics of the corresponding runtime operations. We'll create first-class designs for those types.
- Flow error suppressions are very coarse. Adding a
$FlowFixMeabove a line of code to suppress one kind of error actually suppresses all errors introduced by that code, potentially masking future errors. We're designing error codes that will allow you to suppress specific errors without hiding another error on the same line of code. And we'll move suppressions to the primary position of an error, preventing a suppression attached to a definition from hiding errors where that definition is used.
- Generic types and functions currently have unpredictable behavior, with generic type parameters able to escape their scope and calls to generic functions able to accumulate new bounds far away from the call-site. We are designing new behavior for generics, including more reliable detection of errors in generic functions, a test to prevent escaped type parameters, and a check to ensure function calls are properly constrained.
In 2020, the Flow team will deliver a developer experience that is on par with industry-wide standards of reliability, feature completeness, and delight. As part of this developer experience, we’ll continue to improve on fundamentals: memory usage and reliability. We’ll deliver the most-requested IDE edit and browse features. And we’ll enhance Flow’s type system to make it easier for developers to write safe, correct code.
We’ll keep in touch with you on this blog, on GitHub, and in our Flowtype Discord channel.