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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
