Proposal to change of Mirage Setup

[cah-brian-gantzler]

Currently Mirage is setup in tests via the setupMirage helper which takes the hooks from the tests. In the the host app it is also can be started from an environment config variable enabled. You can also call startMirage directly in the tests or the host app.

I purpose that setupMirage be called in the following way. The path is just an example, will have to work out where it is actually exposed

import makeServer from 'app/mirage/config';  


setupMirage{hooks, { makeServer: makeServer } );

This options parameter would also be added to the startMirage function.

Why would we do this?

1. While this would require importing the config of the server into every test, it would make embroider very happy that a statically analyzable config was imported.
2. This would open the way to different sets of tests having a different server configured specifically for them. This would also allow the server being defined within the test file itself should the test need a very specific defined server.
3. Starting mirage in the application would require calling startMirage. This would allow embroider to better determine when to include the mirage files.

Deprecation of the config lookup

If we deprecated the old way and required this, it would benefit in the following ways

1. Behaves much better in an embroider world.
2. Would be able to remove the enabled config and allow embroider to tree-shake the mirage files from the tests and the app
3. Would be able to remove the application initializer that is currently looking up the config.

Any other suggestions or concerns before I work on a PR?

[kpfefferle]

One additional advantage to note is that this approach would make it easier to load a config that exists outside of the application. We have a couple of applications that share a Mirage setup, and explicitly importing makeServer like this would make it trivial to import that config from a shared package.

[cah-brian-gantzler]

Being able to have your mirage config in a separate addon within the company for sharing would be a good thing. Nice point.

Thats just importing config though, since ember-cli-mirage still looks up the mirage models, factories, etc. and discoverEmberDataModels, there are still possible embroider issues.

We may need to look at explicit imports for all those things instead of the ember magic of looking them up (would make embroider happy and statical analyzable).

This would be a good first step.

[cah-brian-gantzler]

As it turns out, this param is already in startMirage, its just having setupMirage pass it

[cah-brian-gantzler]

I thought I was going to have to update several pieces of the start up code, as it turns out it was all there, just missing giving setupMirage the ability to pass the options to startMirage. Was so easy a fix not sure why I didnt see it earlier