Will Code Splitting per "Ember Addon" be possible next?

Hi everyone, Our team have been working with Ember about 2 years and we are making healthcare system for cloud. and we are really appreciating to Ember team’s commitment and effort.

We first used ember engine for dividing the app by “domain”, so we had benefit of lazy loading. But recently we had to decide changing ember engine to “ember addon” because of UI design & concept. Now we have only one (main) route and each “domain” is implemented as “ember addon”(exactly many components in it). there are hundreds of domain in the system

Eventually, we want the followings.

  1. we want to “lazy load” each domain(ember addon) when user click the menu
  2. we also want to build and deploy each domain separately (Building app as whole takes tens of minutes)

we are hoping those are possible by Ember team’s “code splitting” work and we want to know those are really possible in the following release of Ember CLI , if possible, WHEN we can use them. Could anyone give us some information?

I’m not 100% sure I understand the questions, but let me give it a shot…

Here you are asking if it will be possible to make a “lazy non-engine addon”? If so, then I think the answer is essentially that this should become possible with the “packager” work that is currently underway (unsure at the moment just how “simple” it will be, still a few unknown unknowns here)…

We are working (generally speaking) on many different ways to pre-build an addon so that the build times of host applications do not suffer.

Please check out the section on treeshaking and code splitting in:

OK. Thanks a lot for your answer, You understand my question exactly. I meant, we are making “lazy non-engine addon” for each domain as you said. So everything that I mentioned is underway. And, I guess, you, Ember team hardly expect when the “packager” will be done at this moment… right? so all we need to do is waiting for this. ( actually we don’t want to do work around for this).

Yeah, sorry about that. I generally try to avoid estimates, doubly so for open source projects…

Here is a workaround that we are using for splitting the add-on(inrepo) code which is shared by engine and app.

Vendor (500KB) + Common addon files (50 KB)(Shared by App and engine).

Our requirement was to split the common addon files and to load it as assets/common-vendor.js


module.exports = {
  commonVendorTrees: [], // an array for all the common code shared by engine and app.


const calculateCacheKeyForTree = require("calculate-cache-key-for-tree");

// ...

  treeForAddon(tree) {
    let app = this._findHost(); // finding the parent project.
    app.options.commonVendorTrees.push(this._super.treeForAddon.call(this, tree));
    // empty return so that files of this addon will not be in vendor.js

// cacheKeyForTree method needs to be overwritten as there is a check in ember-cli which will  cause the addons to opt-out of the caching mechanism
const calculateCacheKeyForTree = require("calculate-cache-key-for-tree");
 cacheKeyForTree(tree) {
    let cacheKey = calculateCacheKeyForTree(tree, this);
    return cacheKey;

bundle-common-addon/index.js (An addon to bundle the common files)

  // merging all the commonVendorTrees and writing it in a single file. Using treeForPublic hook since it'll be called after treeForAddon.

  treeForPublic(tree) {
    let mergedTrees = broccoliMerge(this.app.options.commonVendorTrees, { overwrite: true });
    let commonVendorTrees = new Concat(mergedTrees, {
      outputFile: 'assets/common-vendor.js'
    // removing the empty trees before merging
    return broccoliMerge([tree, commonVendorTrees].filter((row) => !!row));

We want to “lazy load” each domain(ember addon) when user click the menu

You can try ember-auto-import.

Hope this helps you.


@siva_abc your code splitting example worked great for me!

One thing that stumped me for a little while is calculateCacheKeyForTree needs to be imported. I hope you don’t mind but I’ve used my admin powers on this forum to edit it into your example.