Tests only? about ember-cli-mirage HOT 9 OPEN

The if you were aware was more that you can use MSW now in mirage instead of pretender (pretender will still be compiled in until its actually removed from miragejs).

You might have missed this above but excludefilesfrombuild https://www.ember-cli-mirage.com/docs/advanced/environment-options#excludefilesfrombuild should do what you want, the method _shouldIncludeFiles https://github.com/miragejs/ember-cli-mirage/blob/master/packages/ember-cli-mirage/index.js#L123 is called from the treeFor hook

from ember-cli-mirage.

https://www.ember-cli-mirage.com/docs/advanced/environment-options#enabled

These configurations are the main reason I think this addon should go away or at least be really stripped down. Now that the changes have been made to call the mirage server create in your code instead of behind the scenes, you should have a lot more control over the process.

I still use this addon, but want to do a demo project using mirage and NOT using this addon, then adopt that pattern to my app and post accordingly.

from ember-cli-mirage.

These configurations are the main reason I think this addon should go away

yeah, with just this config, I'm not confident that the mirage assets are excluded from the dev build 🤔
like, omitted from the app/vendor/etc chunks.

I will have to test it out, and see what it does.

This at least sounds close

using mirage and NOT using this addon, then adopt that pattern to my app and post accordingly.

that sounds legit!
feels similar in spirit to my MSW demo: https://github.com/NullVoxPopuli/ember-msw-development/commits/main

How much work do you think native mirage is?
Depending on that, I wonder if we could codemod the transition to get the community off ec-mirage 🤔

from ember-cli-mirage.

I think this works the same, set it in your config if the environment is dev. https://www.ember-cli-mirage.com/docs/advanced/environment-options#excludefilesfrombuild

I dont think its a lot of work to remove this addon, and prob could be code modded. The method setupMirage is still valuable in a different form. It would either be example code that people would just copy, or one of the few surviving helpers that might continue to exist in this repo

Mirage is based on pretender, in case you werent aware though, I extracted the pretender stuff from mirage and you can now use pretender or msw (pretender will still be included til we actually remove the pretender from mirage proper)

from ember-cli-mirage.

actually, reading through the code, it seems enabled might not do what I want?

in that it's not used in the treeFor* hooks?: https://github.com/miragejs/ember-cli-mirage/blob/master/packages/ember-cli-mirage/index.js#L111

Reading the docs, it looks like where enabled is used, is just used for extra augmentations, rather than also removing code? https://ember-cli.com/api/classes/addon#method_included

am I understanding this correctly?
If so, would you accept a PR that removes mirage from the app tree?
here: https://github.com/miragejs/ember-cli-mirage/blob/master/packages/ember-cli-mirage/index.js#L110

from ember-cli-mirage.

Mirage is based on pretender, in case you werent aware though

oh I am. I hate pretender. lol.
It's such a DX travesty. 🙃

from ember-cli-mirage.

I just booted my app trying to disable mirage, and I confirm there are no mirage assets in the app-name.js yay!

from ember-cli-mirage.

but! @cah-brian-gantzler followup -- can we have an option to move everything, when included, in to the tests bundle?

from ember-cli-mirage.

While I understand what you are requesting, I am not sure what would need to be done to accomplish that. Always willing to learn more.

I, though, am hesitant to make any changes to this repo given that Im kinda of advocating that this repo should not be needed anymore. :)

Will try to make it a priority to get a write of how I think Mirage should be used directly (or find out what if actually needed in this repo to make it work).

You should be able to follow the call setupMirage in your tests to find where you create the server. setupMirage should take some parameters that should allow you to specify a different server config for each test if you wanted. Right now because its called indirectly, if very difficult to do that. setupMirage should also appear in your actual code (with a condition), if you want to use it during dev, and without the condition if you want to use it in prod. The parameters allowing you to specify a different mirage server config that are being using in the tests (if needed, if they all pass the same param you would have what you have now, one server config).

To do that I think the setupMirage should be wrapped in a helper (one for each server setup) and then you import the correct one for the test that is needed. Kinda like they are suggesting for the setup* test helpers https://github.com/emberjs/rfcs/blob/master/text/0637-customizable-test-setups.md

Just ideas, havent gotten the time to actually prove out what would not work and what to do to fix that.

from ember-cli-mirage.