deprecate trackRequests and testConfig

[cah-brian-gantzler]

Deprecated the trackRequests environment variable. This is passed on to pretender. This can now be a variable in the final config. While its in the code, I could not find it documented in MirageJS

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

  return createServer(finalConfig);
}

testConfig was a property that could be passed into startMirage that added some additional routes maybe? It was never documented and not sure exactly what it does. Deprecating it in case someone is using it (hopefully they will write an issue and let us know how).

[cah-brian-gantzler]

The error that all the tests fail on is what I get locally. Its the embroider/macros problem I believe

[acorncom]

@cah-brian-gantzler noticed you were aiming to deprecate testConfig. I can understand the reasoning, but thought I'd mention that it was documented years ago (see https://www.ember-cli-mirage.com/versions/v0.1.x/server-configuration/#testConfig). I found it documented up until https://www.ember-cli-mirage.com/versions/v1.1.6/docs/api/modules/server~Server#testConfig at which point the server docs stopped getting generated for some reason.

For those of us who did use it the way it was documented in the past, do you have any suggestions on ways to go about ending up with a similar approach in the new world of miragejs?

[acorncom]

You got me curious, so I dug a little further. Doesn't look like it's well documented, but Server still allows testConfig to be specified as an option in the core miragejs library as well: https://github.com/miragejs/miragejs/blob/f68581a1b56c4d3e5efcee94641fa761fd3add60/lib/server.js#L252

So might be worth considering it as intimate api but not yet getting rid of it?

[cah-brian-gantzler]

TestConfig was imported here https://github.com/miragejs/ember-cli-mirage/blob/v2.4.0/app/initializers/ember-cli-mirage.js#L5 (note that this is in the app folder, would like to remove all this) and then registered with the container here https://github.com/miragejs/ember-cli-mirage/blob/v2.4.0/app/initializers/ember-cli-mirage.js#L24.

It was then looked up from the container here when mirage was started here https://github.com/miragejs/ember-cli-mirage/blob/v2.4.0/addon/start-mirage.js#L32 and then just merged into the routes here https://github.com/miragejs/ember-cli-mirage/blob/v2.4.0/addon/start-mirage.js#L93

The documentation you found says that this is only supposed to be included when running in test mode, but I dont see an if that implements that.

Given that testConfig was already defined in the config file, and you now have control of the code in the default function, you should be able to do something like this.

import { isTesting, macroCondition } from '@embroider/macros';

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

  return createServer(finalConfig);
}

function routes() {
       this.get('/invoice-masters/:id');

       if (macroCondition(isTesting()) {
           this.config( {routes: testRoutes} );
           // this also should work if you prefer to call directly
           // testRoutes.bind(this);
       }
       
}

// This could be included here or imported from another file if you wish
// Would have had to re-export it here the old way
function testRoutes() {
     this.get('/invoice/:id');
}

This puts everything in one place under your control and removes a lot of the magic.

[acorncom]

The documentation you found says that this is only supposed to be included when running in test mode, but I dont see an if that implements that.

This seems to be the area of interest within Mirage: https://github.com/miragejs/miragejs/blob/f68581a1b56c4d3e5efcee94641fa761fd3add60/lib/server.js#L287-L319