babel / proposals

✍️ Tracking the status of Babel's implementation of TC39 proposals (may be out of date)
https://github.com/tc39/proposals
432 stars 39 forks source link

export-default-from (Stage 1) #17

Open hzoo opened 7 years ago

hzoo commented 7 years ago

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

benjamn commented 7 years ago

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";
benjamn commented 7 years ago

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).

loganfsmyth commented 7 years ago

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?

jdalton commented 7 years ago

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.

pshrmn commented 7 years ago

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";
loganfsmyth commented 7 years ago

@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";
jdalton commented 7 years ago

@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.

benjamn commented 7 years ago

@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!

hzoo commented 7 years ago

^ 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.

loganfsmyth commented 7 years ago

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.

loganfsmyth commented 7 years ago

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.

jdalton commented 7 years ago

@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.

leebyron commented 7 years ago

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.

hzoo commented 7 years ago

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

hzoo commented 7 years ago

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