Convert all object types to exact, or explicitly-inexact

[gnprice]

(This becomes possible only with Flow v0.84, which we'll get as part of #3399; so it's blocked on that. And completely finishing it is blocked on later work in upstream Flow.)

Generally almost all our object types should be exact object types. See discussion in 61d2e34 and 7037393... and see the many examples in git log --grep exact of type errors that had been concealed by inexact object types and were discovered by making the object types exact.

The Flow team agrees, and they have been making changes to make it easier to work that way across a codebase:
https://medium.com/flow-type/on-the-roadmap-exact-objects-by-default-16b72933c5cf

We've already gone and made the bulk of our object types exact; see 61d2e34, 7037393, and 8370002 . With Flow v0.84, it becomes possible to explicitly mark as inexact the few types we actually want to describe that way. This task is to

• do that;
• for the remaining types that should be exact but aren't, make them exact (and fix whatever type errors stopped us from doing that before);
• make sure we really have gotten every case of the previous two steps (with that flowlint promised in "Step 1" of the roadmap post linked above -- which doesn't seem to exist yet).

[gnprice]

#3399 is now done.

[gnprice]

Flow upstream recently posted an update on how to do this upgrade:
https://medium.com/flow-type/how-to-upgrade-to-exact-by-default-object-type-syntax-7aa44b4d08ab

Looking through the steps there:

1. Upgrading dev tools. Ensure all your tools support the new syntax.

We already have a few explicit inexact object types and haven't seen them break anything, so this is mostly set.

Checking the four package versions mentioned in the post, we're good on three of them, but we should

• upgrade babel-eslint to at least v11-beta.

2. Codemodding. Upgrade your codebase to use the new syntax.

The flowlint rule implicit-inexact-object, which would find places we have the old syntax, doesn't appear until Flow v0.101. We're on v0.92. So this will be easier to complete, and make it stay completed, once we're up to that Flow version.

Looks like RN v0.60 brings us Flow v0.98, and RN v0.61 brings Flow v0.105. So that Flow upgrade, in turn, will come with the RN v0.61 upgrade #3781.

OTOH that doesn't mean we need to wait to upgrade our code! There's a tool called flow-upgrade linked from that post, which will make the transformation automatically across our code. Might try that.

3. Upgrading dependencies. Upgrade any code dependencies to use the new syntax.

Not going to worry about this until step 2 is done, or at least mostly done.

[chrisbobbe]

• upgrade babel-eslint to at least v11-beta.

I just tried babel-eslint at v11.0.0-beta.2, and it wants at least ESLint 6. We'll get that in, e.g., #4128.

Looks like RN v0.60 brings us Flow v0.98, and RN v0.61 brings Flow v0.105. So that Flow upgrade, in turn, will come with the RN v0.61 upgrade #3781.

Now done, in #4151, great!

[gnprice]

Now that we're on RN v0.61 and Flow v0.105, we have that implicit-inexact-object flowlint rule available. So I made a quick experiment with it.

It finds 411 places. The majority of those are in the libdefs in flow-typed/npm/, which come from flow-typed upstream, so those are to be left for step 3. Something like 100-150 of them are in our code, though.

Skimming through, there's a mix. Some are indeed meant to be inexact. A lot of them -- I think probably the majority -- are meant to be exact, and we just haven't gotten around to making them say so. So we don't want to just sweep through and automatically add , ... to these types; we'll want to look at them one by one and mark them as exact or explicitly-inexact.

This flowlint sure makes easy to find places that need this conversion! So the steps to push this forward now look like:

• Add implicit-inexact-object=warn to the [lints] section of .flowconfig.
• Rerun Flow -- try npx flow --show-all-errors, as otherwise the warnings in flow-typed/ swamp it.
• Look through the warnings, and add either | and | or , ... to each highlighted object type, as appropriate.
• Skip any where it's not clear what's appropriate -- we can come back for those.