Flowtype - is there any reason not to put all node_modules in [declarations]?

Question

It's fairly common to get errors within node_modules when upgrading Flow, but this makes a bunch of errors go away:

[declarations]
<PROJECT_ROOT>/node_modules/.*

Also, I assume it significantly cuts down on the amount of stuff Flow has to process, since

In declaration mode the code is not typechecked. However, the signatures of functions, classes, etc are extracted and used by the typechecker when checking other code.

Yet this isn't the default. Is there any reason I shouldn't do it? If the type signatures themselves have errors (like a class implementing an interface but differing in method types, or installed flow-typed defs differing between library and consuming project), would it fail to report some errors in my code that uses those type signatures?

I should note because AFAIK Flow still doesn't have a tool to output definitions only from source code*, I've just been copying the entire source files to .js.flow in many of our internal packages. So errors occur when upgrading Flow in projects that use those packages. However I've seen errors even from within the version of graphql that we're currently on.

*The print-signature CLI command mentioned in the docs doesn't actually appear to exist when I try to use it.

Anselm

Answer 1

Using [declarations] definitely makes sense to either move forward or stay behind with your version of the Flow server in relation to some third-party package, without having to completely discard it's type definitions.

I've been explicitly providing intelligible paths that clearly denote packages in [declarations] which are causing issues, as this helped hint which dependencies to keep an eye out for and prioritize upgrades to get a better typing experience when it becomes available.

And that's I think the only thing you'd truly lose at the end of the day, the ability to know exactly for which dependencies you might not have complete type information.

Peacock