There are a number of issues with types imported from other files behaving differently from types defined local to their usage.
I've collected many that I can verify are still valid as of 0.41.
From what I understand, these issues occur because of architectural challenges - is there a plan to tackle these in Q2?
any, but doesn't mark expressions referencing them as not covered [#1528]These bugs, at least for me, have tended to be the most difficult and time-consuming to debug and reproduce.
CC @gabelevi @avikchaudhuri @samwgoldman
Seems to still be an issue with v0.51.0.
These bugs also affect my team's projects which are trying to migrate to flow. /cc @ericsoco @chrisirhc
Is there anything we can do to help get these issues fixed?
I'm getting the exact same situation as @btford. We're currently working through migrating, and these unexpected behaviors mean we basically can't use flow at all until they're fixed.
@cbranch101 Just use $FlowFixMe without exact type and covariants. Still very useful. And pray the team fix those issues asap.
I have some changes planned that should help, and I'll check in on the linked issues after it lands, then update here. Thanks.
I believe https://github.com/facebook/flow/issues/5382 is another example of such an issue.
I'm seeing a bug where an imported $Call type alias fails to produce the same errors as it does locally. I've spent hours trying to make a minimum repro case, but the errors are only missing in test code in my full-blown library. I'm really suffering here guys :cry:
Do you want me to make an issue for my particular case or is this issue sufficient?
@samwgoldman is there any plan to fix this issue? 馃槶
Most helpful comment
I have some changes planned that should help, and I'll check in on the linked issues after it lands, then update here. Thanks.