Likely to cause new Flow errors:
invalid-recursive-exported-annotationwill now have error code ofrecursive-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-typeerrors. (example). - Unsupported statements like loops within
declare modulewill no longer cause parse errors. Instead, they will be errored on during type checking. declare export typeanddeclare export interfacestatements in toplevel are no longer parser errors. Instead, they will now be errored during type checking.- Previous
toplevel-library-importerrors andunsupported-statement-in-liberrors will all haveunsupported-syntaxerror code now.
New Features:
- We introduced
experimental.ts_syntaxflag that you can set totrue. 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 usingextendsto 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 fordeclare constanddeclare letwas missing. This has now been fixed.
Misc:
- Make
boththe default value for the .flowconfigcasting_syntaxoption, if not supplied.