Chris Toshok toshok at
Thu Jun 19 10:23:23 PDT 2014

On Thu, Jun 19, 2014 at 6:57 AM, Erik Arvidsson <erik.arvidsson at>

> On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf <calvin.metcalf at>
> wrote:
>> One other option could be for import name from 'path'  to resolve to the
>> module body there is no default export, thanks to the static analysis
>> you'll always know when default is present.
> That is a refactoring hazard. If the module changes to add/remove the
> default export the import will still succeed but the value is either a
> module instance object or anything:
> // a.js
> export default class C { ... }
> // importer.js
> import A from './a';
> new A();
> Now a.js changes.
> // a.js V2
> export class C { ... }
> // importer.js
> import A from './a';
> new A();  // TypeError: A is not a function
> With this idea you cannot look at the import statement to see if the
> imported binding is a module instance object or not.
I think you're example misses one point - The module author changed the
exported api, going from exporting a function named C to exporting an
object with a property named C.  Problems caused by this refactoring would
exist regardless of Calvin's suggestion.

Calvin's suggestion would allow the following refactoring to be done by the
module author without impacting his users, something not possible with
current ES6:

// a.js V1
export default { C: class C { ... } }

// a.js V2
export class C { ... }

The refactoring hazard is real, but exists iff the module consumer uses
implicit exports (i.e. an Object.prototype method with the above default
export).  This is another reason why the named export form is better -
everything is explicit.  IMO the only good reason to use default export is
to export a single function.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list