You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current world, it is easy to set a Resolver to be used for an entire test-suite by using the setResolver method. This is fine in the vast majority of use cases, but with the advent of Engines, and particularly in-repo-engines, we need some additional flexibility as shown in this issue.
One approach that I suggest is to allow setting a resolver option that is passed into the test module like so:
Then, when constructing the container/registry for that test module, we'll use the passed in Resolver instead of the globally defined one that was set with setResolver.
This provides backwards compatibility while giving enough flexibility that the ember-engines addon could provide an additional wrapped to allow getting a proper resolver by engine-name. I imagine something like:
In the current world, it is easy to set a Resolver to be used for an entire test-suite by using the
setResolver
method. This is fine in the vast majority of use cases, but with the advent of Engines, and particularly in-repo-engines, we need some additional flexibility as shown in this issue.One approach that I suggest is to allow setting a
resolver
option that is passed into the test module like so:Then, when constructing the container/registry for that test module, we'll use the passed in Resolver instead of the globally defined one that was set with
setResolver
.This provides backwards compatibility while giving enough flexibility that the ember-engines addon could provide an additional wrapped to allow getting a proper resolver by engine-name. I imagine something like:
The text was updated successfully, but these errors were encountered: