Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

export-default-from (Stage 1) #17

Open
hzoo opened this issue Jul 27, 2017 · 15 comments
Open

export-default-from (Stage 1) #17

hzoo opened this issue Jul 27, 2017 · 15 comments

Comments

@hzoo
Copy link
Member

hzoo commented Jul 27, 2017

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
Copy link

benjamn commented Jul 27, 2017

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
Copy link

benjamn commented Jul 27, 2017

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
Copy link
Member

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
Copy link
Member

jdalton commented Jul 27, 2017

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
Copy link

pshrmn commented Jul 27, 2017

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
Copy link
Member

@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
Copy link
Member

jdalton commented Jul 27, 2017

@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
Copy link

benjamn commented Jul 27, 2017

@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
Copy link
Member Author

hzoo commented Jul 27, 2017

^ 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
Copy link
Member

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.

@hzoo hzoo mentioned this issue Jul 27, 2017
10 tasks
@loganfsmyth
Copy link
Member

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
Copy link
Member

jdalton commented Jul 28, 2017

@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
Copy link

leebyron commented Jul 28, 2017

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
Copy link
Member Author

hzoo commented Jul 28, 2017

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

@hzoo
Copy link
Member Author

hzoo commented Aug 8, 2017

Made an issue to split the proposals into 2 if anyone wants to comment more babel/babel#6075

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants