Discuss
  • Module Default Export Syntax

Module Default Export Syntax

# Kevin Smith (11 years ago)

A couple of months ago, we discussed some issues with the default export syntax, and Dave suggested making some minor tweaks so that these forms:

export default function ...
export default class ...

were declarations instead of expressions.

Has there been any movement on this issue recently?

I think this solution is acceptable, but I still maintain that it would be less confusing for the user if we required an equal sign:

export default = foo;

Consider the following case:

export default { a: a1, b: b1 };

It would be easy for a beginner to misinterpret this as a shorthand for multiple exports, when in fact this statement is exporting a single thing which happens to be an object.

If the syntax were instead:

export default = { a: a1, b: b2 };

such confusion is less likely.

# Kevin Smith (11 years ago)
export default { a: a1, b: b1 };

To expand a bit: these two export declarations are both valid:

export { a, b, c };
export default { a, b, c };

They differ only in the presence of a keyword, yet they are have completely different semantics.

So let me propose an alternative to the current syntax that might be acceptable to everyone:

ExportDeclaration:
    ...
    export default ClassDeclaration
    export default FunctionDeclaration
    export default GeneratorDeclaration
    export default = AssignmentExpression

Thoughts?

# Claude Pache (11 years ago)

Le 22 juin 2014 à 06:44, Kevin Smith <zenparsing at gmail.com> a écrit :

export default { a: a1, b: b1 };

To expand a bit: these two export declarations are both valid:

export { a, b, c };
export default { a, b, c };

They differ only in the presence of a keyword, yet they are have completely different semantics.

The confusion comes from that the same delimiters, { and }, are used for both object literals and named exports. But IIUC, these are two different things. So, let's just pick other delimiters.

—Claude

# Brendan Eich (11 years ago)

Standard C-like head form delimiter-pair is '()'...

# Kevin Smith (11 years ago)

The confusion comes from that the same delimiters, { and }, are used for both object literals and named exports. But IIUC, these are two different things. So, let's just pick other delimiters.

I see no reason to consider such a large change (which would require us to reevaluate syntax on both import and export sides). Minor tweaks are the name of the game now.

# Kevin Smith (11 years ago)
ExportDeclaration:
    ...
    export default ClassDeclaration
    export default FunctionDeclaration
    export default GeneratorDeclaration
    export default = AssignmentExpression

To reply to myself (since no one else appears to be interested), I think it might even be best to drop these special forms altogether. The non-sugared form of:

export { someVar as default };

is already very concise, and will help developers understand what this whole "default" thing is about. The sugar appears to be obfuscating the design, and is doing more harm than good.

Again, thoughts?

# Axel Rauschmayer (11 years ago)

I do like the conciseness of the last form. The other forms do indeed not seem very useful.

# Barronville, Jonathan (11 years ago)

Kevin, you're not alone :) . I like that last form, too.

  • Jonathan

— Sent from Mailbox

# Calvin Metcalf (11 years ago)

The place where the current syntax shines is when dealing with anonymous values,

# Claude Pache (11 years ago)

Le 25 juin 2014 à 11:16, Calvin Metcalf <calvin.metcalf at gmail.com> a écrit :

The place where the current syntax shines is when dealing with anonymous values,

For that case, the same sugar as named exports could work:

export let default = ...

at the condition to allow "default" as an identifier in that position.

BTW, I agree with Kevin that the sugar for default export is not worth the obfuscation of the design.