Allow Flow build-time type checking

[gino-m]

Would it be possible to enable Flow type checks at build time (e.g., like this) without requiring an eject + custom webpack config (#1592)? Opening this issue since #4097 was flagged as a question instead of an feature request, and closed without much explanation.

It seems a pity that atm we can't get both the up-to-date integration goodness of cra, and the static type safety of Flow*. It would be a big win if this were supported, imo. Thanks!

*I assuming manual build steps don't count as part of the build process, since they're optional and entirely up to the developer to know about and execute.

[bugzpodder]

You can run flow CLI to check for errors as a separate step, just like you do with jest tests. Most editors have plugins that shows flow errors inline within the editor, which is much more helpful than a console message from webpack.

[gino-m]

This assumes that we want to treat type errors as if they're lint warnings. What if we would like to elevate them to compile errors (or at least simulate the same behavior), as would happen if the type system were built into ES6 or Babel? My goal is approximate as closely as possible language-level type safety so that we can rely on the compiler to do type checking, instead of assuming the developer will always check for errors in their editor or via CLI command. Thanks for your help!

[bugzpodder]

Personally, I have a CI setup that runs jest tests and flow check, and they can also be added as a pre-commit hook.

I feel like enforcing build failures on flow errors is a bit stringent. While they should be enforced when code is checked in (just like how we don't want test failures), enforcing them before development builds might be a bit too much.
Even though there could be a flow error due to type mismatch, the program could still build/run successfully and even correctly. Also, flow errors are very dependent on the version of the flow installed. A perfectly valid program for flow 0.7 may result in tons of errors for flow 0.8.
Also, I think its useful to prototype something quickly in code without worrying about flow errors breaking the build.

[bugzpodder]

Also, flow itself has tons of issues with invalid library definitions and even react definitions itself:
facebook/flow#7219
This for example will prevent anyone from adopting React.lazy syntax with flow enabled. The only way to disable it to add $FlowFixMe before every React.lazy call...

[holloway]

If you want compile errors then modify package.json like,

"build": "yarn flow && react-scripts build",

Build errors + editor Flow integration gets you most of the way there.

On the broader point of Flow not keeping up, I'm finding that too, sadly.

[gino-m]

Personally, I have a CI setup that runs jest tests and flow check, and they can also be added as a pre-commit hook.

Also, I think its useful to prototype something quickly in code without worrying about flow errors breaking the build.

@bugzpodder I think this makes sense. It may be biases because I've spent a lot more time working with statically typed languages which enforce typing at compile-time. As long as we have types enforced before code is submitted, we'd get the best of both worlds: rapid prototyping, and type safety. I'll set up commit hooks instead. Closing this issue for now.

@holloway Thanks for this, I'll use this to add compile checks to builds to ensure we don't accidentally deploy to test servers w/o validating types.