Remove the testConfig function about ember-cli-mirage HOT 5 CLOSED

On the deprecation PR #2375 @kevinansfield asked about this.

I created this issue for other people to find the answer better than looking through comments in PRs

from ember-cli-mirage.

I assume you are still using the old function that defines the set of routes in config.js. So you have a file in the mirage directory named config.js with an export default of the dev routes and also an exported function testConfig in the same file. The default function mocks new features for ember s and ember t and then the routes in testConfig() mock all the other routes for tests. Is that correct?

You could do this to config.js, this has always worked in ember-cli-mirage (although with a different way to test isTesting before embroider) and I suspect why he removed the test config from the docs. With this you could have as many alternate routes as you wanted.

function testConfig() { // no longer need to export it
}

export default function() {
  // your routes defined here

  if (macroCondition(isTesting()) {
     this.config({ routes: testConfig});
   }
}

Using this.config you are able to import whatever routes you want conditionally

However in 2.x the routes only function is deprecated, and you should convert to the mirageJS makeServer function. This way your config will work much like the mirageJS Docs.

I moved the routes that were in the default export to their own file dev-routes.js (still export default), and the test routes to their own file test-routes.js (export default in that file). Not needed but nice organization and shows what your can do now that you are in more control. The file config.js should now look like this.

import {
  discoverEmberDataModels,
} from 'ember-cli-mirage';
import { createServer } from 'miragejs';
import { isTesting, macroCondition } from '@embroider/macros';

import devRoutes from './dev-routes';
import testRoutes from './test-routes';

export default function (config) {
  let finalConfig = {
    ...config,
    models: { ...discoverEmberDataModels(), ...config.models },
    routes,
  };

  return createServer(finalConfig);
}

function routes() {
  this.config({ routes: devRoutes });
  if (macroCondition(isTesting()) {
     this.config({ routes: testRoutes});
  }
}

You are in much more control now, and could import more routes for whatever reasons you wanted. You could also move the import of test-routes.js into the if so that it is only imported when in the test environment. You would use the embroider macro importSync https://www.npmjs.com/package/@embroider/macros. Just the raw JS import may work as well.

Let me know if you have any questions.

from ember-cli-mirage.

@kevinansfield although I opened this issue, could you close it when your questions are answered. Thanks

from ember-cli-mirage.

Thanks @cah-briangantzler! I've managed to switch over to using createServer() and dropped use of the testConfig export.

Only thing that ended up being different was the routes() function, I found I had to call the exported functions from the external files like so:

function routes() {
    if (macroCondition(isTesting())) {
        testRoutes.call(this);
    } else {
        devRoutes.call(this);
    }
}

from ember-cli-mirage.

What you are doing is probably the better way. MirageJS provides a method this.loadConfig https://github.com/miragejs/miragejs/blob/master/lib/server.js#L410 that does the same thing, but with a side effect updating the timing.

There should probably be something added in the MIrageJS docs detailing how to add additional imported routes.

Glad to hear you were able to work around it.

from ember-cli-mirage.