Flow: Switch to new "Types-First" mode.

[chrisbobbe]

We generally keep our Flow version at the same version as the React Native project uses at the time of the RN release we're using. That's because different Flow versions tend to flag different errors and warnings; this happens naturally as Flow fixes bugs and adds/improves features.

• This means we should aim for Flow v0.137 in the upcoming React Native v0.64 upgrade (link); that's Upgrade to RN v0.64 #4426.
• RN v0.65 hasn't been released yet (and we don't have an issue for it yet). But from a release candidate, it looks like we should expect to aim for v0.149 or later (link).

From the doc, it looks like Types-First was released as experimental in v0.102 and released officially in v0.125. It'll be enabled by default starting in v0.134, and that's why we'll have to either switch to it before the RN v0.64 upgrade, or temporarily opt out with types_first=false.

From the Flow changelog, I see that v0.143 removed the ability to opt out:

Support for Classic mode has been dropped and Types-First mode is now always enabled (Types-First has been the default mode since v0.134). The types_first and well_formed_exports flowconfig options are no longer recognized. See https://medium.com/flow-type/types-first-a-scalable-new-architecture-for-flow-3d8c7ba1d4eb/ for more about Types-First mode.

So, to keep up with React Native, we'll want to have Types-First enabled by the time we upgrade to RN v0.65, at the latest, since we'll want to aim for Flow v0.149 for that upgrade.

As I mentioned at #4426 (comment):

The thing we'll have to do to enable it is annotate almost all the exports of our modules:

The caveat of this new version is that it requires exported parts of the code to be annotated with types, or to be expressions whose type can be trivially inferred (for example numbers and strings).

Not annotating an export sufficiently will raise a signature-verification-failure error.

[chrisbobbe]

OK, I've just made another pass through the errors that appear if I temporarily set well_formed_exports=true. A few exports stood out to me as particularly challenging to annotate, and I'll probably start discussions for them on CZO once we take care of the easier things:

• action export in exampleData.js (we have a comment saying we've explicitly chosen not to annotate this)
• default export of src/styles/index.js
• functions where the return value is the result of a fetch (would be good to get facebook/react-native@6651b7c59 so fetch won't be untyped anymore, but that was released in v0.65, which is our deadline for turning on Types-First)
• Thunk action creators

Other than those, I think the main challenge will be some unusually tricky conversions to function components; I see about 9 of those in the error output. (From the tip of my current revision for #4914, I see about 30 in the error output that I've marked as "easy".) But of course there's an escape hatch with those 9: we can always just work out the required annotations and add them, sacrificing some cleanliness because those might end up being pretty verbose.

[gnprice]

Thanks! I took a look at this earlier today, and started a chat thread: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flow.20types-first/near/1237897

Here's how I think we can handle those four classes of exports:

• eg.action: I think we can do this by just exporting the individual action types like RealmInitAction, and casting each action to the appropriate one of those.
• src/styles/index.js: looks like we can do this by writing Object.freeze for the export, and doing the type-checking that createStyleSheet does separately
• fetch return values: The status quo here is actually already that these functions are inferred to return empty (or Promise<empty>). So we might as well write that explicitly in annotations -- I didn't realize that was happening myself until I ran into it when developing Clean up API error-distinguishing logic #4896 last week.
  • Also we should fix it, but that's independent of types-first.
• Thunk action creators: looks like these are easy, fortunately

I'd also encourage you to try using the codemod. Its output requires a bit of fixing up, but then it completely successfully takes care of a large swath of the errors.

The major remaining class of errors looks to be connect calls. I'm happy to see those handled by converting to Hooks, as you're doing, so long as that's easy. For any components where that's hard, let's handle getting an annotation the direct way: I think it's basically a matter of writing down an OuterProps type, and then annotating the export as ComponentType<OuterProps>.