Default exports, without explicit syntactic support

C. Scott Ananian ecmascript at
Thu Jun 26 09:22:15 PDT 2014

On Thu, Jun 26, 2014 at 9:39 AM, Kevin Smith <zenparsing at> wrote:

> (I’m happy with David’s proposal, but I’d like to try bikeshedding one
>> more time.)
> For my part, I no longer think that the "import * as foo" change solves
> anything.  The underlying problem is default exports - it's just plain
> confusing to users.

I am coming around to a similar, but I think not identical, conclusion.  I
like the syntax proposed in the other thread:
import foo, bar from "bat" as bat;
Now the confusion is between:
import _ from "underscore";
import "underscore" as _;
But here it's not "default exports" per se.  I need to know whether the
module defines a single named export, or whether I need to dereference from
the module object.  I can't know which to use without consulting the source
of the module, and I expect that "real" ES6 code will probably end up with
an unpleasant mix of the two styles of import.

I'm not sure that there is an easy solution here.  The various compromises
seem to try to make these two forms quasi-identical (modulo lazy binding,
and given some support by the module author).  Is that enough?  Does it
actually solve the problem?

In node modules the ambiguity is solved because (by and large) `var Foo =
require("foo").Foo;` is just "not done".  So in almost all cases I can just
write `var Foo = require("foo");` and assume that will be correct.  But
socially or syntactically deprecating one of our two ES6 import forms is

(a) We can't discourage the `import _ from "underscore";` form because we
are forced to use this form for, eg, for jquery. `import "jquery" as $;`
won't work because `$` needs to be a function object, not a module.

(b) We can't discourage the `import "underscore" as _;` form without giving
up lazy binding.

There is a fundamental confusion here, but it's related mostly to the
relative immutability of the "module" object and the mechanism for lazy
binding.  Default exports are one attempt to paper over these differences,
but maybe not the only one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list