Types imported with `import *` (import star) are treated as values, causing runtime error

[wchargin]

Consider the following two files:

dep.js

// @flow
export type Fruit = string;  // doesn't matter

test.js

// @flow
import * as Dep from "./dep.js";
export type Fruit = Dep.Fruit;

These files type-check (yarn flow check) without problem.

But the output of npx babel test.js is the following:

import * as Dep from "./dep.js";

var bpfrpt_proptype_Fruit = function () {
  return (typeof (Dep.Fruit == null ? {} : Dep.Fruit) === "function" ? PropTypes.instanceOf(Dep.Fruit == null ? {} : Dep.Fruit) : PropTypes.any).apply(this, arguments);
};

import PropTypes from "prop-types";
export { bpfrpt_proptype_Fruit };

It is a runtime error to refer to Dep.Fruit, because that export only
exists at the type level.

.babelrc

{"presets": ["babel-preset-flow"], "plugins": ["babel-plugin-flow-react-proptypes"]}

package.json

{
  "name": "demo",
  "dependencies": {
    "babel-cli": "^6.26.0",
    "babel-core": "^6.26.3",
    "babel-plugin-flow-react-proptypes": "^24.0.1",
    "babel-preset-flow": "^6.23.0",
    "flow-bin": "^0.75.0"
  }
}

[brigand]

Hello. I don't see any way for us to detect this, so I think you'd have to suppress the plugin for this file.

Let me know if you have any ideas on how to improve the behavior.

[wchargin]

Hi. I agree that it’s not possible to detect this from the syntax tree.
For instance, if we add export class Froot {} to dep.js and change
the export in test.js from Dep.Fruit to Dep.Froot, then the only
change to yarn flow ast test.js is in the (string) name of the
identifier being exported, which is clearly insufficient.

However, it is possible to do this with basic static analysis—no
typechecking needed, just textually following the imports. For instance,
using yarn flow type-at-pos on this example yields class Froot or
imported Fruit from "/path/to/dep.js" depending on whether the class
or the alias is used. So, it’s possible, at least in the simple cases.

Is this something that you would like to see in the project?

so I think you'd have to suppress the plugin for this file.

Thanks for the suggestion, but we like import * a lot and use it all
over the place, so this suggestion wouldn’t work for us.

[brigand]

At least for now, I'd like to maintain the plugin not reading files or invoking CLI tools. There are costs to that limitation, and in your case it won't work at all, so I'll think about it some more. Thanks for bringing up the issue.

[wchargin]

Okay! Thanks for letting me know. I’ll stay subscribed to this issue;
feel free to update it if anything changes.