Flow: Object field type errors fail to blame the actual culprit

[pelotom]

Take this example:

File foo.js (doesn't know about bar or baz):

// @flow

export type Foo = { x: number, y: number }

File bar.js (doesn't know about foo or baz)

// @flow

// `bar` is not a `Foo`... but it never claimed to be! This module
// doesn't even know about the existence of the `Foo` type.
export const bar = { x: "hello", y: 3 }

File baz.js (using libraries foo and bar)

// @flow

import type { Foo } from './foo'
import { bar } from './bar'

const baz: Foo = bar

Type checking yields this error:

src/bar.js:5
  5: export const bar = { x: "hello", y: 3 }
                             ^^^^^^^ string. This type is incompatible with
  3: export type Foo = { x: number, y: number }
                            ^^^^^^ number. See: src/foo.js:3

The error message mentions foo.js and bar.js, but neither of these modules has done anything wrong! The real culprit is baz.js, but it's not mentioned anywhere. If you're using Flow as an editor plugin you won't see errors annotating your own code where you made the mistake, and even on the CLI you will be confused by mysterious errors mentioning only third-party libraries, with no indication of the real source of the problem.

[gre]

I've just mysteriously fall into this bug after doing some project structure refactoring.
I believe there are weird cases where this bug happen, and normal cases where this is fine.
I'm having trouble identifying in which cases this problem appears though.

[calebmer]

We agree that this is the wrong place to output an error! I’ll be doing some error message work soon and plan on working on this. Thanks for reporting 👍

[pelotom]

It seems like an odd policy to close an issue saying you plan to work on it soon, rather than linking it to a PR and closing only once the PR is merged. Leaving it open until it's actually implemented allows people who are interested in a fix to subscribe to the issue and be notified when the fix is in. Why leave us in the dark?