proposals

proposals copied to clipboard

Champions: @jdalton @benjamn (prev @leebyron) Spec Repo: https://github.com/tc39/proposal-export-default-from Stayed at Stage 1 at the July 2017 meeting: https://github.com/tc39/agendas/blob/master/2017/07.md

Syntax

export v from "mod";

Implementation

Already implemented in https://babeljs.io/docs/plugins/transform-export-extensions/ but we should split it out

The committee decided we were more comfortable with supporting just

export default from "module";

as another export default variant, whereas

export DefaultFromModule from "module";

was less compelling, given that it feels dangerously close to

export { DefaultFromModule } from "module";

which means something totally different. By comparison, the following code (which already works) seems less likely to confuse someone reading the code:

export { default as DefaultFromModule } from "module";

We believe a common use case for export default from "module" will be adding the default export to export * from "module", which otherwise skips default by design:

export * as "module";
export default from "module";

To shorten this common idiom, we think the following shorthand syntax should work as well:

export *, default from "module";

I mention this because it probably has consequences for existing parsers (e.g. Babylon).

I think I'd expect default to go first, e.g. export default, * from the same way import foo, * as foo from can't be flipped around. Is that set in stone?

I admit I feel like this reasoning is weird, because the argument applies equally to the existing syntax when comparing

import foo from "";

and

import {foo} from "";

Why break the symmetry in the syntax for a concern that already applies to both the import and re-export cases?

Why break the symmetry in the syntax for a concern that already applies to both the import and re-export cases?

No worries. Clause order was brought up and is something to-be further discussed. As to not distract from the proposal we'll align with existing order rules and continue the clause order as a separate discussion/proposal.

If only export default from "module"; is allowed, then the only way to get multiple default re-exports to work (for example in an index file) would be to use the bracketed default as?

// index.js
export { default as One } from "./module-one";
export { default as Two } from "./module-two";

@jdalton The symmetry more important to me in this case is

 import foo from "bar";
 import {foo} from "bar";

vs

 export foo from "bar";
 export {foo} from "bar";

@pshrmn

If only export default from "module"; is allowed, then the only way to get multiple default re-exports to work (for example in an index file) would be to use the bracketed default as?

Yes, multiple default re-exports requires the "as" forms.

@loganfsmyth The committee felt export { default as foo } from "bar" (which already works) was clearer than export foo from "bar". However, if you have any data that export foo from "bar" is already in wide use (via Babel plugins or otherwise), that might be an argument in its favor!

^ if someone can make a AST grep tool with babylon/ as a babel-plugin it would be cool if we could run that through github/bigquery to see usage. Otherwise we would need analytics in babel.

I get the confusion argument, but I guess I don't see it because we already have the same problem with import foo from vs import {default as foo} from and it's no more or less confusing than what we already have. Mostly I'm just surprised because I thought the symmetry argument was a pretty strong one. I'm consistently surprised by the seeming unnecessary restrictions on re-export syntax vs import syntax.

I can't say I have a ton of data, but it came up on SO yesterday: https://stackoverflow.com/questions/45311530/unexpected-token-when-compiling-es6-to-es5-whats-going-on/45311558#45311558 That user's using a bunch both syntax options, so IDK.

Here's another usage example that illustrates why it can be a nice pattern: https://github.com/callemall/material-ui/blob/master/src/svg-icons/index.js since having to repeat { default as ... } on ever 900 times would just hinder readability.

@loganfsmyth You don't have to convince either @benjamn or I, we're just the messengers of the meeting results. You should ping @michaelficarra (someone against it) and Slack about this.

Of course I also pretty strongly agree with you, @loganfsmyth - that's why I pitched the proposal in the first place. I agree that the potential for confusion is really minor considering we have the exact same syntactic differences in the much more frequently used import from, and your example case is a great example of exactly the kind of case I foresaw improving legibility for.

I also suggest you reach out to @michaelficarra and others to try to convince them of this.

aside: I think Logan should able to join in the TC39 calls (if he wants to), or attend in person haha 😄

Made an issue to split the proposals into 2 if anyone wants to comment more https://github.com/babel/babel/issues/6075