ES6 modules (sorry...)

[Brian Donovan]

Guy Bedford and I have been discussing a compromise with bundling of
“internal” dependencies but leaving “external” dependencies out of the
bundle. There are legitimate concerns around exposing a library’s internal
module structure to the outside world. For example, Ember is written using
ES6 modules but the module structure is not (yet) intended to be part of
the API. So it makes sense to scrub those internal modules to act as if
they had not existed.

However, if something else in your application depends on RSVP (as Ember
does) you should be able to share that dependency with that other e.g.
library rather than forcing both libraries to bundle RSVP separately.

The re-write of the ES6 Module Transpiler [1] is being done in such a way
to support bundles, and I plan to augment it to support this idea of
internal and external modules.

[1]: https://github.com/square/es6-module-transpiler/pull/126


On Mon, Jun 16, 2014 at 4:12 PM, Kevin Smith <zenparsing at gmail.com> wrote:

>
>> All major browsers (including safari) support SPDY today. But the point
>> is, we should not consider "bundling" as a prime use-case for modules,
>> because it is not going to be important at all.
>>
>
> I agree, in principle, but I'm not quite as confident that bundling will
> have *no* place on the web.  For example, will it really make sense to
> distribute a third-party library as a collection of individual internal
> modules?  I think it remains to be seen...
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140616/54ed6753/attachment-0001.html>