duizendnegen / ember-cli-lazy-load

Support lazily loading your Ember app via splitting it up into Bundles
MIT License
42 stars 8 forks source link

Add lazy loading for vendor file #4

Open B-Stefan opened 8 years ago

B-Stefan commented 8 years ago

The support for split the vendor file in separate files is more complex then the application. I think the only way to do this is to modify the loader so that the loader itself support lazy loading.

The reason for the is that we don't can control the dependencies between the vendor modules. Currently, for manual setting up the bundles for the vendor file you need to know about the internal structure of the vendor dependencies.

MiguelMadero commented 8 years ago

This works OOB in Ember today, see

https://github.com/ember-cli/rfcs/pull/28

I have not tested it to see if it really satisfy our requirements, but it seems like the right approach. It's implemented and available on cli 2.4.2

MiguelMadero commented 8 years ago

I tested this earlier today and it works great for vendor files (e.g. bower_components or vendor/), but it doesn't do addons yet. All addons still end up in vendor.js. I'm planning to extend the current API to add support for the outputFile for an addon, something like: app.import('addon/ember-power-select/', {outputFile: vendor-core.js}).

It isn't as simple since all of the dependencies of ember-power-select will still end up in the default vendor.js file, so we need to make sure we don't break anything by loading vendor-core first and delaying vendor.js. The trick would be to make the default the "first" non-lazy loaded and manually specify a different output file for things we know that can be lazy loaded. Unfortunately, this creates a lot of coupling since now we need to know about the dependencies of our dependency. For example, if I add ember-power-select today I don't worry about ember-wormhole and truth-helpers, things simply work. In the future, ideally we can be more explicit about "groups" of dependencies, but for now, being aware of indirect dependencies sounds like an acceptable trade-off for cases where lazy-loading is important.