v0.229.2

Misc:

• Fixed a potential crash under the experimental flag experimental.blocking_worker_communication=false.

v0.229.1

Misc:

• Bug fixes in preparation of new feature rollout

v0.229.0

Likely to cause new Flow errors:

• invalid-recursive-exported-annotation will now have error code of recursive-definition.
• Previously we would emit confusing errors when you try to use a value that has union types as a type. Now it will consistently emit value-as-type errors. (example).
• Unsupported statements like loops within declare module will no longer cause parse errors. Instead, they will be errored on during type checking.
• declare export type and declare export interface statements in toplevel are no longer parser errors. Instead, they will now be errored during type checking.
• Previous toplevel-library-import errors and unsupported-statement-in-lib errors will all have unsupported-syntax error code now.

New Features:

• We introduced experimental.ts_syntax flag that you can set to true. When this flag is on, Flow will no longer complain about certain TypeScript syntax, and will automatically turn them into the closest Flow equivalent types. Initially, we support the following: Readonly, ReadonlyArray, ReadonlyMap, ReadonlySet, NonNullable, and using extends to specify type parameter bounds. In the future, more kinds of types that we currently parse but error on might be added. (e.g. keyof). Please note that the support here is best effort. We make no guarantee that these types have the same semantics as those in TypeScript 100% of the time, but for common cases, it might be good enough for you.

Notable bug fixes:

• We now allow the use of saved state for glean indexer, if saved state is enabled in flowoconfig or CLI arguments.
• Improved the way we compute contextual hints for spread arguments of calls (e.g. try-Flow).
• In declare module, all the values will be auto-exported if we cannot decide whether the module is in CJS or ESM. However, support for declare const and declare let was missing. This has now been fixed.

Misc:

• Make both the default value for the .flowconfig casting_syntax option, if not supplied.

v0.228.0

Likely to cause new Flow errors:

• Some new errors might be raised when using React.cloneElement with polymorphic components. Eg. try-Flow. Note that React.cloneElement is deprecated
• Nested declare module is no longer a parser error, but a type checking error
• declare module is now explicitly banned in nested scope and outside of library definition files. It already does nothing under those contexts.

New Features:

• All kinds of imports are now supported in library definition files
• We will no longer require annotations on class properties, if the class properties are already initialized with "annotation-like" expressions. e.g. We can now infer the type directly for properties like prop = (foo: string): number => 3.

Notable bug fixes:

• Fixed a bug that causes the first run of flow check to always return 0 errors, when some parts of temporary directory is a symlink.
• Hover type on react elements now show the type of the component and props, instead of just React$Element. (e.g. try-Flow)
• For missing annotation on exports, we now correctly say some annotation is missing on an identifier instead of array pattern. e.g. for export function f(a) {}, we now say "Missing type annotation at identifier" instead of "Missing type annotation at array pattern".

Parser:

• Flow can now parse declare namespace Foo {...} statements. The body of the declare namespace statement shares the same restrictions of declare module.
• Invalid exports in declare module are no longer parse errors. They are now type checker errors.

v0.227.0

Likely to cause new Flow errors:

• Some errors related to empty arrays might have their error locations or codes changed.
• Flow will now interpret trivially recursive types, such as type T = T as empty, instead of any. (e.g. try-Flow).
• We now error when calling .call() on polymorphic functions where the return type is under-constrained (e.g. try-Flow). To fix add an annotation to the return result.

Parser:

• DeclareModule AST will no longer have a kind field

Library Definitions:

• Removed redundant cases in Array.from overloads. It might cause some error locations and codes to change.
• Add types for the Storage API, available via window.navigator.storage (thanks @ZelJin).

v0.226.0

Likely to cause new Flow errors:

• $ObjMap and $TupleMap become stricter. The following code now errors: example

IDE:

• Linked JSX editing will now only trigger if you edit the opening tag, instead of both the opening and the closing tag.
• We now provide IDE services in user-defined library definitions.

Notable bug fixes:

• Fixed a bug where recursive types defined across multiple files caused spurious errors and led to unsound types
• Add .databases() to IDBFactory (thanks @bobrovnikov)
• Mark DOMStringList as iterable, so that it works with Array.from(...) (thanks @bobrovnikov)

v0.225.1

Notable bug fixes:

• [fix] disable aggressive behavior of linkedEditingRange requests when there are parse errors
• [fix] Only print "evaluated" hover type results if the type is of a reasonable size (less than 100 nodes)
• [perf] faster LSP commands through skipping redundant parsing
• [fix][ide] Find-all-references and rename will no longer return stale results on the file that triggers the request. Instead, we will compute the most up-to-date result at the time of the request for the triggering file.

v0.225.0

Notable bug fixes:

• We improved the inference support for function rest parameters in a generic function. This example can now type check. You can also extract the parameters of a function excluding the first parameters now: (example)
• In hover type, when a name is defined in another file but is imported with a different name, Flow will use the locally aliased name.
• fixed a crash happening when a class was defined in a scope where a binding with the same name already existed (try-Flow example)

v0.224.0

Likely to cause new Flow errors:

• %checks is now deprecated. It will still work as before (for now), but if you enable the deprecated-type Flow lint, you will see additional errors. Instead, use type guards.
• $Call, $ObjMap, $ObjMapi, $ObjMapConst are now deprecated. They will still work as before (for now), but if you enable the deprecated-type Flow lint, you will see additional errors. Since Flow 0.209, you can now use builtin types like Parameters, ReturnType, Pick, Omit to easily extract and transform types. For more advanced use cases, you can read the docs of conditional type and mapped type to understand how to write it in equivalent ways.
• Ban creation of object literal computed properties with non-literal number keys
• Ban accessing objects with non-literal number keys
• You can now create and access object keys with int-like number literals, these act as their string equivalents.
• Union of exact objects allow computed access as long as one of the members of the union have the property

New Features:

• Add support for number literals as keys in object literals, e.g. const obj = {1: true, 2: false}
• Support numeric keys in object type annotations. They are equivalent to the string version.

Notable bug fixes:

• Removed spurious underconstrained error with mapped type, if the relevant type parameter already has a default. (example)
• Support calling Array.from with string input and also mapping function, e.g. Array.from('str', x => x.length)

IDE:

• [ide] Go-to-definition for a barrel-exported type name will now jump to the original definition location, instead of incorrectly jumping to itself.

Library Definitions:

• Add type stubs for global crypto object, crypto.getRandomValues, and crypto.randomUUID
• We removed StatelessFunctionalComponent type from the 'react' module and the React$StatelessFunctionalComponent type. The name might give an incorrect assumption that Flow can actually check that a function component doesn't use stateful hooks or can be called directly. If you have code that still uses this type, we recommend you use the React.AbstractComponent type, since it forces you to not make any assumption of what kind of React component you are dealing with.

v0.223.3

Before Flow 0.223, the autoimport system uses the filename as a hint of the name for default export. e.g. if the filename is foo.react.js or foo.js, regardless of whether the default export in that file has a name or not, or even the default name is bar, autoimport will always import it as import foo from 'foo'.

However, in the new system starting from Flow 0.223, we will use the name of the default export as a stronger hint. In a lot of files that just give a default export a random generic name, they are relying on the old system to get reasonable auto imports.

It's not practical to update every Flow codebase to avoid the UX regression, so now auto-import will provide both options.