Requiring service dependency declaration in engine.js is fragile

[cdeng]

Was seeing a couple of instances where forgetting to declare services in engine dependencies caused production issues. There isn't a check that ensures services invoked in engines are properly provided by the host application. So if the service is missed in the engine.js list, the service will not be provided by the app and might cause issues.

I was thinking if there is a way that ember-engine checks and ensures the app provides services required automatically without requiring an explicit list of service dependencies, or at least checks services declared in engine.js and throws errors if any service is missed during the build time. Any thoughts?

[rwjblue]

The "request" (what the addon/engine.js specifies) and "passing" contexts (what the app says that it provides to engines) are both independent, and I can't quite tell which side you are referring to here.

I definitely think it would be reasonable to add an option to addon/engine.js that would throw an error if it requests a service that is not passed in by the host, we could even entertain changing the default value in 0.9...

[cdeng]

Having an option that ensures the service contracts between the host and engine is helpful for the part of the contract. Besides that, I was wondering if we can come up with a way that eliminates or automates the process of specifying services in addon/engine.js based on what services that addon is needed/invoked? I think eliminating the needs or validating the explicit declaration of services in engine.js would help to prevent cases where devs forgot declaring the services in engine.js.

[rwjblue]

Having an option that ensures the service contracts between the host and engine is helpful for the part of the contract.

Sounds good, happy to help folks with a PR to do this.

Besides that, I was wondering if we can come up with a way that eliminates or automates the process of specifying services in addon/engine.js based on what services that addon is needed/invoked?

I've discussed this a bit with a few coworkers (@aghassemi). I'm not 100% opposed (and in fact I think @aghassemi has a spike that functions properly), but we have to be pretty careful here. The goal of ember-engines is to provide a level of isolation between the engine and the host application and a setting that effectively lets the engine access any arbitrary service from the host app would absolutely break any isolation that we have here.

[elwayman02]

I think the ideal from my perspective is at minimum something that warns the developer if the app is not providing all of the services the engine has specified as dependencies. Combined with linting to ensure that the engine doesn't use any external services it hasn't declared as dependencies, this would make use of engines a lot more robust and eliminate the common pitfalls of having to specify the dependencies in two places (engine and app).

Too often we see developers use new app-level services in their engines and fail to define them in dependencies, either for the engine's config or for on the consumption side.

That said, I'm not sure what the concern is with allowing the engine to declare any arbitrary service as a dependency. If an engine says it needs foo as a dependency from the app, in what scenario would we not want the app to include foo in its config? Is that not considered an incorrect consumption of the engine at that point? In what way do we believe that would violate the isolation principles? What is the practical risk here?