Make type aliases exportable.

[spion]

Hack: generates empty var declarations for type aliases. Flow users
should now be able to attach types to the exports object without it
resulting with errors being thrown.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

[spion]

Done

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[jeffmo]

Thanks for sending this. We've been talking about this a lot lately and were hoping to go in a slightly different direction (and very soon I think -- it's one of our most requested features right now. cc @gabelevi).

Specifically, this does make it possible to at least export type aliases as runtime variables, but it does not solve the problem of importing them and having a linter tell you that you have unused variables (since the bindings aren't used in any runtime positions).

So instead of converting type bindings to a runtime binding for the purposes of the module system, we're actually planning on introducing a small syntactic extension to the ES6 import/export syntax for Flow that allows one to import/export just a type (rather than a type+value). Currently we're thinking something like import type Foo from "Foo";/export default type Foo = number;, import type {Foo, Bar} from "Foo";/export Foo; export Bar;, etc.

This works out great because it means that the type-only import declarations are lexically identifiable (which means the transform can strip them out since they aren't needed for the runtime), the export declarations are also easily stripped because it's easy to distinguish value bindings from type bindings locally while doing the transform, and we solve both the type importing/exporting problem and linting problem all at once.

The only work items left to do this are to build the type keyword extension into the parsers, build it into the transform, and build the semantic reasoning into Flow itself (probably in that order)

[spion]

This would mean that type exports wont ever be supported for CommonJS modules? Thats pretty sad - its a huge ecosystem in desperate need of a good type system. I guess we'll see how compatible will ES6 modules be with CommonJS - judging by the support from other compilers, not very much

[jeffmo]

Not exactly -- it just means you'd need to use the flow-extended import/export declarations for importing and exporting types in commonjs modules. For example:

ModuleA.js

type foo = number;

function myFunc() {
}

export foo;
exports.myFunc = myFunc;

ModuleB.js

import type {foo} from "ModuleA";
var myFunc = require("ModuleA").myFunc;

...

You could think of import type as another flow syntactic extension (just like type annotations are).

This of course bleeds in to module system pluggability topics for Flow, which we've thought a bit about as well, but haven't quite proven with implementation yet. Our plans are to move Flow's default module system to ES6 modules, but we know we can't just utterly drop support for CJS -- so that will probably be an opt-in Flow option when we make that switch.

[spion]

Oh okay, I didn't think of that. I suppose that would work (its a bit weird, but on the other hand its clearer that types cannot be used as values)

[jeffmo]

I'm going to close this out, but I'm happy to chat about this further either here or in the Flow IRC channel if any new thoughts/concerns pop up.

Again, thanks for sending this PR in any case