Flow: [Meta] Critical inconsistencies between imported types and locally defined types

Created on 15 Mar 2017  路  7Comments  路  Source: facebook/flow

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?

  • Flow types invalid modules as any, but doesn't mark expressions referencing them as not covered [#1528]
  • Circular type imports wreck typechecking for unions. [#3249]
  • Flow doesn't correctly handle imported function-style constructors [#3521]
  • Failure to use typeof of imports in unions [#3229]
  • Using externally defined types for the arguments of generic classes causes strange ordering issues [#2455]
  • Flow fails checking against imported interface, but not when declared locally [#3520]

These bugs, at least for me, have tended to be the most difficult and time-consuming to debug and reproduce.

CC @gabelevi @avikchaudhuri @samwgoldman

Meta Issue bug

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.

All 7 comments

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? 馃槶

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Macil picture Macil  路  47Comments

Gozala picture Gozala  路  54Comments

jlongster picture jlongster  路  55Comments

danvk picture danvk  路  73Comments

STRML picture STRML  路  48Comments