ember-cli-mirage in legacy app

Question

We have application that used Pretender to provide fixtures for tests. Now we're trying to migrate to ember-cli-mirage . We cannot migrate all the fixtures at once. So what is basically happening there is that we are starting our own Pretender server and ember-cli-mirage is starting it's own. Whic renders following warning:

You created a second Pretender instance while there was already one running. Running two Pretender servers at once will lead to unexpected results and will be removed entirely in a future major version.Please call .shutdown() on your instances when you no longer need them to respond.

Since it is just a warning, it should not be an issue for the transient period. Problem is that once Mirage is loaded into our application, old Pretender routes stops responding. I guess that's what "... will lead to unexpected results" is referring to.

Any chance to run ember-cli-mirage alongside manually created Pretender routes? Or just to use Mirage server and inject those routes there?

Answer 1

I would use Mirage's server and then load up your Pretender routes inside of it. (Mirage's server is really just an object that new s up a Pretender instance). If folks see mirage folder they'd probably expect the routes to be defined there. Also, Mirage cleans up its Pretender instance during testing.

In mirage/config.js you could import your existing Pretender routes and call them there. Mirage has sugar on top of Pretender but you can always access the underlying pretender instance via this.pretender within the config function:

// mirage/config.js
import setupYourOldRoutes from 'somewhere';

export default function() {
  this.get('users'); // new Mirage shorthand

  setupYourOldRoutes(this.pretender);
}

So setupYourOldRoutes could be a function that takes a pretender instance and then defines all your existing route handlers using it.

Answer 2

Based on @samselikoff answer I found a solution for my case. We already have one central point, that is handling creation of pretender instance. So the fix was just to pass Mirage's Pretender instead of creating new one:

// somewhere.js
export default function () {
  // initPretender: function () {
  //   this.pretender = new Pretender();
  // }
  initPretender: function (pretender) {
    this.pretender = pretender;
  },
  getPretender: function () {
    return this.pretender;
  }
}

// mirage/config.js
import pretenderWrapper from 'somewhere';

export default function() {
  this.get('users'); // new Mirage shorthand

  pretenderWrapper.initPretender(this.pretender);
}

Tricky part was to make sure that initPretender() is called before any of our legacy code tries to call getPretender() . I think usually that is not a trouble. In our case we patched tests/helpers/start-app.js so that some fixtures were injected in every test. And that caused calling getPretender() too early.