Bridge the syntax gap between _Flow_ and _TypeScript_

[Conaclos]

Proposal

The goal of this proposal is to improve interoperability between Flow and TypeScript.

• Allow export declare as an alias of declare export
• Add unknown type as an alias of mixed
• Add undefined type as an alias of void
• Add readonly as an alias of + in object type and interface. e.g. type Person = { readonly name: string }.
• Add in, out as aliases of - and + for type parameter variance
• Add extends as an alias of : for type parameter bounds. e.g. function f<A extends string>(a:A){}.
• Add never type as an alias of empty
• Add type guards (x: unknown) => x is X
• Add as type assertion as an alias of (:)
• Add keyof T as an alias of $Keys<T>
• Add readonly arrays readonly string[]
• Add readonly tuples readonly [string, number]
• Add Readonly, ReadonlyArray, ReadonlySet, ReadonlyMap, Record<K, V> as aliases of $ReadOnly, $ReadOnlyArray, $ReadOnlySet, $ReadOnlyMap, { [key: K]: V }
• Add Partial, Required utility types

Use case

I would like to use Flow. However, it is hard to give up all TypeScript tooling.
More interoperability could help to use Flow.

[gkz]

We already have symbol as a type. As of the next version, we parse and error (with a quickfix to the Flow version) everything you've mentioned above other than type guards and the utility type aliases.

[Conaclos]

We already have symbol as a type

I updated the issue :)

As of the next version, we parse and error (with a quickfix to the Flow version) everything you've mentioned above other than type guards and the utility type aliases.

Thanks for the info :)

The main goal of this issue is improving compatibility between Flow and TypeScript.
I love the strictness of Flow.
I think there is no value to defend a distinct syntax.
Flow evolved in parallel of TypeScript.
However, TypeScript is now largely spread.
This makes hard to defend a distinct syntax for types like unknown, ...

[gkz]

The first step to potentially changing out syntax is parsing it, and then updating all tooling (Prettier, ESLint, etc.) to handle these new AST nodes. That process takes a while (but by parsing and erroring, we're starting it). Once that is done, all that would be required is for Flow to make the change, and we will have discussions on a case by case basis - it's something we're thinking about for sure

[Conaclos]

Thanks for your input :)

[gkz]

We have Partial and Required now: https://medium.com/flow-type/announcing-partial-required-flow-utility-types-catch-annotations-3a32f0bf2a20

[matclayton]

Firstly thank you for flow! It’s been an amazing tool for us at mixcloud, especially when combine with relay.

However unfortunately we’re fighting an uphill battle compared to the typescript 3rd party library support. I wonder if there is any appetite for allowing flow to ingest typescript types for 3rd party libraries or using flow-gen to automate bridging the gap somehow? Allowing us to benefit from flows speed/correctness and the typescript ecosystem?