Flow support is broken as of 0.57.0

PR #9311 adds this:

Warning

An existing bug in flow regarding the use of higher order components (HOC) limits the usefulness of flow by an application. As of November 27, 2017 we cannot at this time recommend the use of flow typing in your application in conjunction with material-ui until such time as a resolution is present.

For those getting started, I want to make sure and warn them to avoid any unnecessary effort if possible.

Expected Behavior

Applications should be able to use flow typing with material-ui.

Current Behavior

Due to https://github.com/mui-org/material-ui/pull/9311, the flow bug prevents use of proper HOC typing as would be used by an application.

Context

From https://github.com/mui-org/material-ui/issues/9109#issuecomment-347283291

We cannot have proper flow support for apps since flow itself is broken. Since we cannot, not even an external libdef in flow-typed could have proper support. If we re-typed the HOCs to effectively any (as I discovered prior to #8419), you could pretend it had flow support, but we would have to do so knowing that we stopped static typing for almost everything. I found in #8419 with any HOCs, we were hiding 1700 flow errors! Essentially, we would have to make flow support almost useless.

Workaround

As a last resort, simply ignore material-ui in .flowconfig. If https://github.com/facebook/flow/issues/5382 remains unresolved for any amount of time, we will likely stop adding flow shadow files to the distribution, as it just makes every flow user ignore them. We aren’t sure yet, but it’s not a good situation.

Your Environment

Tech	Version
Material-UI	> v1.0.0-beta.21
Flow	0.57.0+

TL;DR

I went through considerable pain to get flow to work here and in our apps, only to have to abandon it. I have more invested with flow and material-ui than anyone, and I do think it says something important that I have chosen to abandon it for typescript. Now I think we should contemplate what this might mean for material-ui.

Next steps

TBD.

1. I will not be continuing to maintain flow in material-ui, at least as it pertains to external use.
2. @rsolomon did a good job with the latest PR to get us updated to 0.57+. He and others may be willing to step into the void I am leaving
3. HOCs in flow are in a very fragile state, and I found unusable external to material-ui due to https://github.com/mui-org/material-ui/pull/9311. I am actually surprised that flow is currently working inside material-ui because I could not get the same patterns to work in my app after the flow 0.57+ update.

I am open to transitioning the source files to Typescript, and moving flow outside the library to flow-typed (also see #7857). If the maintainers are not going to be using flow, I would prefer to follow this path.

I’m open to all discussion, I just wanted to make this situation known to all.

/cc @rsolomon @oliviertassinari @mbrookes @pelotom @sebald @m2mathew

[prastut]

I am currently working on integrating MUI with a codebase that uses Flow for type checking. During my research on how to workaround Flow errors, I went through issue 9312 and PR 9453 (Not referencing them as don’t want unnecessary bubbling up of Github thread). I completely understand why you would drop flow support.

I see that some of the flow maintainers did try to reach out here: but I guess it was too late by then.

But one thing I was not able to find in MUI’s documentation for flow is the current state of how devs can integrate MUI with an existing codebase that uses flow. Our codebase uses other HOC libraries as well like recompose so I am not sure how best I can ignore flow errors from Material UI but let the rest of the code getting type checked. Moving to Typescript on our end would be a very drastic step, therefore some clarity would help.

I am more than happy to update the documentation if I have some clarity myself. Right now it looks as if the docs tell that we do support Flow but with a warning, but my experience reading all of the above links suggest that you have completely done away with Flow.

@rsolomon provides some information but it’s lost in terms of getting context for a third person like me.

cc: @rosskevin

[rosskevin]

For watchers - we are actively dropping flow support.

With the broken state of flow, we cannot in good conscience distribute flow files here - we feel it gives the mistaken impression of coverage when we know well at this point that too many implicit anys due to poor hoc support.

Community flow-typed definition?

If you are interested in maintaining a flow-typed definition, please let the community know so perhaps you may join forces together. With our current sentiment regarding flow, we have decided we will not distribute any flow files from this hosted repository. It is probably best that you take a branch of what is current on v1-beta before #9453 is merged so that you may copy existing definitions out of source into a libdef.