Module Comments

David Herman dherman at
Wed Dec 5 22:25:01 PST 2012

On Dec 5, 2012, at 7:16 PM, Kevin Smith <khs4473 at> wrote:

> 1) "export" ExportSpecifierSet ("," ExportSpecifierSet)* ";"
> This rule seems too permissive.  It allows strange combinations like:
>     export x, { y: a.b.c, z }, { j, k }, * from "bloop";
> I think it would be better to flatten it out a little bit:
>     ExportDeclaration: "export" "{" ExportSpecifier ("," ExportSpecifier)* "}" ";"
>     ExportDeclaration: "export" Identifier ("," Identifier)* ";"
>     ExportDeclaration: "export" "*" "from" StringLiteral ";"

Reasonable point, I'll think about that.

> 2) Do we need `export *;`?
> I don't see the point of exporting every declaration in the current module scope.  If the programmer wants to export a bunch of stuff, the other forms make that sufficiently easy.  Exporting everything encourages bad (de-modular) design.

Again, reasonable point.

> 3) I'm just OK with "as".  Note that it inverts the position of the string and the binding:
>     import { x } from "goo";
>     import "ga" as ga;
> Which makes it harder to read when you have a bunch of imports mixed together.  It's harder for the eyes to scan back and forth.

Yeah, that's the known downside to this syntax. We've been around this block so many times, and it's just one of those things that will end up with bikeshed colored not in paint but in blood. I'm open to alternative suggestions but not to endless discussion (it goes nowhere).

The alternative of

    import ga = "ga"

has the problem of looking like it's saying that ga is a string.

The alternatives of

    import ga = module("ga")


    import ga = (module "ga")

have the problem of making it look like the RHS is an expression.

Feel free to suggest alternatives, but forgive me if I'm not willing to respond to every opinion on this one. :}

> 4) Why was this form eliminated?
>     import x from "goo";  // Note lack of curlies!
> In an object-oriented application, we're often going to be importing a single thing (the class) from external modules.  So we may see long lists like this:
>     import { ClassA } from "ClassA.js";
>     import { ClassB } from "ClassB.js";
>     ....
>     import { ClassZ } from "ClassZ.js";
> Removing the curlies for this simple case would seem like a win.

Another fair point. I think it might've just been a refactoring oversight.

> 5) Dynamic exports via `export = ?` could make interop with existing module systems easier.  But how does that work?

Basic semantics:

- The module has one single anonymous export.
- Clients can only get access to the export with the "as" form; there's no way to access it via a named export.
- The value of the export is undefined until the RHS is evaluated.

> 6) Adding ".js" as the default resolution strategy:
> I don't think this is tenable.  First, there's the practical issue of what happens when someone actually wants to load a resource without a ".js" extension?

They change the resolution hook.

> Second, there's the philosophical problem of essentially setting up an alternate URL scheme.  That's fine for libraries like AMD loaders or YUI.  But EcmaScript is a cornerstone of the internet.  External resource resolution can't conflict with HTML/CSS/etc.

"I'll wait till it's fleshed out more" didn't last long, eh? ;-) Anyway, I don't really understand this argument but do you think there's much value to a philosophical debate on es-discuss?


More information about the es-discuss mailing list