Is it currently possible to have dependencies between library definitions?

I am pretty confused about this. Issues like #16 and #1494 seem to suggest that this isn’t currently doable, but definitions like react-redux seem to be doing it. Is redux a special case or something that allows for this, or is this actually possible for any library?

[EdwardDrapkin]

I’m here to second what @saadq said. Our next React web project at work is going to be TypeScript so we can evaluate if the React-specific stuff in Flow (e.g. ElementConfig, etc.) outweigh the other benefits that TS brings over Flow. This is the issue that kills Flow adoption every time I try to have a conversation with anyone.

I spent several dozen hours spread across many lunch breaks, weekends, and evenings working on this repository, trying to find a way to fix this issue and open a PR that would at least be a POC that could move the conversation forward, but the code quality of the flow-typed code itself is so (no offense, my apologies) abhorrent that my recommendation (were this a project I was getting paid to work on) would be to greenfield a version 2.0 and manually import code that is still useful going forward. That is an enormous task, however, and it seems like there isn’t bandwidth available here in the community to actually get it done. We have over 100 complete, accurate type definition files for various node modules that we can’t contribute back upstream because transitive dependencies don’t work in flow-typed and it’s prohibitively difficult to fix. And that’s with two people in the entire department who have the expertise and willingness to actually write libdefs. I shudder to think how many thousands of libdefs a company with actual size would have to be sitting on.

There’s nothing that a TS typedef file can define that a Flow libdef cannot also describe AFAIK. If the community wants Flow to succeed, the only way I can see out of this mire is to abandon flow-typed altogether and invest every community effort into making the flow server able to read TS libdef files (or a userspace cross compiler to translate one into the other). Otherwise, the DefinitelyTyped community is way too far ahead of where Flow is, the tooling support in IDEs is much further ahead, and like others have said, Facebook’s cold shoulder to the Flow community is as good as a middle finger.

FWIW, I think Flow is a superior product to TS for a multitude of technical reasons, but every other thing about the choice goes to TS right now, and Facebook has not shown that they are willing to fight Microsoft in this cage, so how can anyone in good faith recommend Flow any more? If the Flow community could just absorb the work that the TS community has done - both in typing JS packages and consuming TS code’s type information too - that would solve a lot of these issues.

[villesau]

There are two different ways of importing in libdefs:

import type { MyType } from 'some-module';
declare module 'other-module' {
  declare export function takesMyType(val: MyType): number;
}

and the second is this:

declare module 'other-module' {
  import type { MyType } from 'some-module';
  declare export function takesMyType(val: MyType): number;
}

How are these different from each others? The first one does not work and returns any type, the second one works. Also, AFAIK second approach only supports importing types, so e.g classes etc are tricky. I haven’t tried if you can import class on the top of the file and use it’s type with typeof, it might also just turn out to be any.

Unfortunately flow-typed does not currently support the second approach as it can’t depend on other libdefs during the tests. Other problem is nasty dependencies between library definitions which might become very hard to maintain.

Ideally flow-typed would support dependencies between libdefs, and in optimal situation flow-typed install module@1.2.3 would also install possible dependencies.