Working circular

My impression of the default export of a module is that it is intended for
people to be able to go `import name from '. /path' ` and just get that
thing, so if a default export exists it is a likely guess that it is what
someone wants when they require a module.

though it is early and there isn't a huge amount of examples of modules in
the wild/the spec seems to be in flux.  If people start exporting different
things via named and default exports then it would likely be a good idea to
change this.

But in the mean time somebody default exporting likely means it as a single
export.  I hope having to write code like this is rare (if it's allowed, I
don't remember if you can combine then)

    import name, {thing1,thing2} from 'path';

But yeah to get back to the point it's probably the least worst thing for
es6 modules as well as cjs at the moment.
On Jul 4, 2014 2:36 PM, "Guy Bedford" <notifications@github.com> wrote:

> In lib/evaluate.js:
>
> > +  // this can also be done with VM or something cleaner
> > +  scopedEval.call(global, global, localRequire, localModule, record.exports, record.address, record.dirname);
> > +}
> > +
> > +function ourRequire(name, loader) {
> > +  // if in the side table
> > +  if (sidetable.has(name)) {
> > +    var record = sidetable.get(name);
> > +    evaluate(name, loader);
> > +    return record.exports;
> > +  }
> > +
> > +  if (loader.has(name)) {
> > +    var mod = loader.get(name);
> > +    if ('default' in mod) {
> > +      return mod.default;
>
> I suppose my complaint is not that this is being done for CommonJS, but
> that this is also affecting ES6 modules in the registry. When you do
> loader.get you don't know if the CommonJS itself is potentially requiring
> an ES6 module. That is the scenario I added the __cjs flag to the module
> object for.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/calvinmetcalf/es6-translate/pull/10/files#r14566346>.
>