How do people using Flow handle this problem?
One bit of feedback we received from many DefinitelyTyped users was that it provides a large repository of definitions to get started, but often the definitions are out of date, un-versioned, not well-tested, use lots of `any`s, etc. What we took away from this was that whatever we do, it needs to have a focus on quality and really leverage the community. It should be as simple as possible for anyone to contribute improvements to libdefs, but also we want to make sure those tweaks and improvements are verified by both people AND automation as much as possible.
We looked at the approach of using npm to define/distribute library definitions, but we decided to go with something more integrated instead for consistent coordination/testing/versioning/tooling/validation/etc.
For example: We use automated CI to ensure that all libdefs are tested and versioned against both the library and the version(s) of Flow they are meant to work with. Additionally, we intend to continue building more ways to automatically verify libdefs. Things like heuristics to detect when an impl doesn't align with interface, well-typed tests to allow community members to do this verification themselves, bots that can offer suggestions on pull requests when they see types that could be better written in a different way -- things like using `any` vs `mixed`, etc.
Also, if a new version of Flow goes out with features that might make a libdef better/more expressive, anyone in the community can contribute an update with the same level of assurances without worrying too much about breaking users who use an older/different version of Flow.
Another thing we want to do is to make sure that packages that use Flow in the first place never have to write implementation/interfaces separately, but are still able to easily publish them separately.
For this, we've started encouraging libraries to publish with a .js.flow "shadow" file alongside their compiled files. In the future, flow-typed will be able to automatically extract a library definition from these shadow files that is versioned against both npm and the version of Flow the library was written with. From there, the community can help maintain that auto-generated type interface for newer/older versions of Flow, etc.