C. Scott Ananian ecmascript at
Tue Jul 1 10:48:04 PDT 2014

On Tue, Jul 1, 2014 at 1:36 PM, Calvin Metcalf <calvin.metcalf at>

> one benefit of default exports is forcing people to choose one of
>     export { x as exports };
>     export { x as default };
>     export { x as _ };
> this is the one chance to get everyone on the same page

I think if default exports were dropped, it would certainly be worth an
explicit non-normative mention in the spec text that "the export named _ is
reserved for interoperability with legacy module systems" or something like
that.  There aren't *that* many widely-used module systems, social pressure
and an explicit recommendation is probably sufficient to get them all on
the same page.  (And presumably the legacy loader implementations which
provide interoperability have a good deal of influence here.)

as far as object-as-module having circular dependency issues, can you
> elaborate on that, I understand how

> is (~)what node uses and has comparable (better for certain things, worse
> for others) circular dependency support (source: writing a CJS loader using
> the es6 loader hooks api) the difficulties I can see with modules as
> objects involve static analysis.

This is, indeed, worth exploring further.  Node.js has a very
straightforward mechanism for dealing with circular dependencies.  As long
as you make all of your references indirectly through the "module object"
they are mutable.  This is pretty much exactly equivalent to what ES6
modules provide, with the exception that they save the required
"modulename." prefix -- but at the cost of possible user confusion, since
JavaScript has never had mutable bindings in the way that the ES6 module
system provides them.

If we're cutting things from the ES6 module spec, can we consider cutting
the magical mutable `import {foo} from "./foo";` bindings as well?
 Experience has shown that the rare cases where circular dependencies are
intended and used can deal with the overhead of prefixing the module object.

Personally, I would like to introduce mutable bindings as a future
language-level feature, not as some weird wart on the module design.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list