bug: Engine support

Engines, and likely nested addon, the following throws since this.app is undefined: https://github.com/bgentry/ember-apollo-client/blob/master/index.js#L20

What I think should happen is it should walk up the parent hierarchy until it finds a parent that implements the apollo config that it’s looking for. In the case of an engine, it would likely mean the engine’s index.js would have the config hanging off it. Otherwise, it would continue up to the host app which might implement the config.

A quick fix would be to read the config off the host app (which is currently implied by today’s implementation by replacing this.app with something like this._findHost(). That’s currently what I’m doing on my fork: https://github.com/jasonmit/ember-apollo-client/blob/master/index.js#L21-L22

Thoughts? I can implement either fix but would like to gather consensus first.

[jasonmit]

Things get hairy when you start to consider what happens when both the host and an engine depend on ember-apollo-client, or two engines do — it would be great to lean on the solutions for those scenarios already implemented in auto-import.

Totally agree @dfreeman. Currently ember-auto-import doesn’t have a solve for bundling intelligently.

Lets move forward with ember-auto-import with the assumption it will one day be smarter around bundling. It should in the meantime eliminate the module resolution issue. I don’t personally care if it’s in the host vendor or engine’s vendor file. It will just be an edge case that can be solved with documentation in the meantime.

I can work on the switch to ember-auto-import if you’re on board.

[jasonmit]

Resolved in 2.0.0-beta.1, thanks!