flow-typed VS hacktoberfest-hunt

I'm very curious, which "Redux code" are you referring to here?

I don't think the `redux` core lib ever shipped any Flow types itself. Looking at the FlowTyped repo, I see community typedefs at https://github.com/flow-typed/flow-typed/tree/master/definit... , and the Git history suggests those were indeed written by community members.

(of course on the flip side, _I_ didn't even start learning TS myself until 2019, and goodness knows _that_ has been a lot of trial and error over time :) )

As for configurability of whether casts should error, in my experience with flow it's paradoxically riskier to rely on a type nag when refactoring an unknown "offending" type casts. I've ran into cases where upgrading flow raised a cast issue, it got "fixed" it in a way that made the type system happy, but inadvertently broke tests because falsy values are tricky like that. Here's an example where a type nag showed up for someone refactoring, they did what they thought was reasonable to silence it, and proceeded to accidentally break the entire tool (slipping through tests and code review, to boot). This happened in the flow-typed tool of all places.

The process of supporting Flow users is extremely similar to that of TypeScript. Instead of adding the definition file to "types" in package.json, make a .js.flow file alongside every .js file that is being exported (for example, if you export lib/index.js, make sure to create lib/index.js.flow with the definitions). See the docs on how to create such a definition. If you want to support Flow yourself, don't publish to flow-typed; it's mainly meant for community members to create their own types for third-party packages and publish them there.