-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
Comments
The committee decided we were more comfortable with supporting just export default from "module"; as another 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 * 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 I admit I feel like this reasoning is weird, because the argument applies equally to the existing syntax when comparing
and
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 // 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
vs
|
Yes, multiple default re-exports requires the " |
@loganfsmyth The committee felt |
^ 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 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 |
@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 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 babel/babel#6075 |
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
Implementation
Already implemented in https://babeljs.io/docs/plugins/transform-export-extensions/ but we should split it out
The text was updated successfully, but these errors were encountered: