ModuleImport

Kevin Smith zenparsing at gmail.com
Mon Jun 30 13:11:00 PDT 2014


> It's not just about interoperability. It's also about enabling the pattern
> that proved itself to work quite well - module as a function, module as a
> class, module as a function with named exports attached in one "namespace".
>

But we have to ask why that pattern worked out, and my take is that the
user experience with CJS modules (which exported just a single) was poor.
 ES6 modules don't have that problem.


> I suppose if that pattern is not explicitly supported it might be just
> fine since perhaps we'll discover better patterns.
>

That's the idea.


> And if not, we'll be able to just always use 1 named export and do
>
> ```
> import {fs} from "fs";
> import {moment} from "moment";
> import {$} from "jquery";
> // etc.
> ```
>

Right.


> In fact, doesn't being able to import things like above make es6 modules
> already interoperable with CJS?
>

(Looks like Scott got here first...)

Mostly.  If you have a Node module which does the overwrite thing then you
might have to assign an arbitrary export name to import it:

    import { exports as Emitr } from "emitr";

(Where "exports" is arbitrarily chosen by the module environment.)

But there are other issues which make the interoperability thing more
complicated:  modules have different syntax than scripts, and modules must
be parsed in strict mode.  So you need to know before you load the module,
what kind of module it is (ES6 or CJS).

What we need is a complete interoperability story.  I have some ideas which
I'll write up when I get a chance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140630/60e1eae5/attachment.html>


More information about the es-discuss mailing list