Open hzoo opened 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";
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 bracketeddefault 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
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