Run initializers and instance-initializers inside engines

[ef4]

This enables initializers and instance-initializers inside engines.

The only change necessary to get instance-initializers running is altering the canonical addon/engine.js to invoke ember-load-initializers (which is analogous to what happens in app/app.js).

Getting the initializers running required an extention to the Engine class. Applications run them when they're told to boot, but no equivalent step happens for child engines, so instead we run them the first time we build an engine instance.

[rwjblue]

Can you tweak this to something like the following:

const modulePrefix = 'ember-blog';
const Eng = Engine.extend({
  modulePrefix,
  Resolver
});

loadInitializers(Eng, modulePrefix);

Reading it top to bottom like this seems easier to my brain 😝

[ef4]

Agreed, I was just blindly copying the format of the app/app.js blueprint. This is much better.

[rwjblue]

Applications run them when they're told to boot, but no equivalent step happens for child engines

I do not think this is quite correct. We should be running initializers during init of the Engine instance (this is roughly what happens with Ember.Application also).

---

Can you another test that ensures all initializers are ran before instance initializers? I am also concerned about an initializer calling deferReadiness on the engine (which IMO we should not support but should provide a helpful error).

Can you also update the blueprints (here and here) to follow the recommendations in the README?

[ef4]

I do not think this is quite correct. We should be running initializers during init of the Engine instance (this is roughly what happens with Ember.Application also).

Application doesn't run them during init, it waits until domReady() or boot().

[rwjblue]

Application doesn't run them during init, it waits until domReady() or boot().

You are correct, but they are called as a byproduct of calling Ember.Application.create (there is a bit async there due to the domReady checks). Since we do not intend to support async like that, we should fire the initializers just after init is finished (perhaps on('init', function() { this.runInitializers(); })).

[rwjblue]

Anyways, I don't think that solution really ends up being different than this. And arguably this is clearer...

[dgeb]

I am fine with this approach to Engine init for now, with the understanding that we will refine it when we introduce async loading of engines.

[rwjblue]

Thanks @ef4!

[ef4]

Oh, one small nitpick: this change technically makes every engine need to put ember-load-initializers into dependencies. Which doesn't even work, due to the dreaded nested included issue.

But in practice every ember-cli app already has ember-load-initializers, so it seems OK.

[rwjblue]

Yes, and they can easily not include it if they don't need/want initializers.