Replace ember-cli-mirage with direct miragejs usage

[Turbo87]

ember-cli-mirage does not appear to be actively maintained anymore and is blocking a couple of other dependency updates. While the maintenance situation for https://github.com/miragejs/miragejs does look much better, it at least doesn't integrate as closely with Ember.js.

This PR replaces ember-cli-mirage with direct usage of the more generic miragejs library to hopefully unblock these other dependency updates.

Note that this PR also removes the "default" mirage scenario, which was previously used when ember serve was run. Keeping it would've meant putting all of the mirage code in the app bundle, risking that the code is also bundled into production builds. Instead, I've moved the mirage code into tests/mirage/, which should be sufficient to only have it bundled into our testing code.

I personally use pnpm start:live most of the time, and if I'm working on pages that need authentication, then I set up a corresponding scenario in the test suite, which I will later need anyway to write the corresponding tests.

[Turbo87]

aaaaand I forgot about the e2e test suite, which apparently would need the mirage stuff to be in the app bundle... 😩

@eth3lbert any ideas?

[eth3lbert]

aaaaand I forgot about the e2e test suite, which apparently would need the mirage stuff to be in the app bundle... 😩

@eth3lbert any ideas?

haha, this makes me think of the pain I experienced while initiating e2e tests.

---

I played around a bit and was able to get it running (though it's not correct yet) by doing the following:

• Changed all @/mirage/... to @/tests/mirage/... in e2e/fixtures/mirage.ts.
• Due to "Error: Cannot find module '@ember/debug'". Change the following

import { assert } from `@ember/debug`;

to

import { importSync } from '@embrodier/macros';

...
_adjust(hash, includes) {
    let versions = this.schema.versions.where({ crateId: hash.id });
    let assert = importSync('@ember/debug').assert;
    assert(`crate \`${hash.name}\` has no associated versions`, versions.length !== 0);
...

in tests/mirage/serializers/crate.js.

• Changed the Webserver.command in playwright.config to something like pnpm exec ember serve. (Need to further set up fixtures to be able to proxy to mirage).

Let me know if you need me to help fix all this with a more concrete solution.

[eth3lbert]

After digging a little bit more, it seems we might still need an initializer to start the mirage server since it runs in-browser 🤔

---

From the mirage comparison section, MSW, which provides both in-browser and Node.js solutions, might be a better fit. This would make it work more nicely with Playwright and also seems to be more actively maintained compared to mirage recently. However, transitioning would require a significant amount of work.

[Turbo87]

Let me know if you need me to help fix all this with a more concrete solution.

I wouldn't say no to that :D

From the mirage comparison section, MSW, which provides both in-browser and Node.js solutions, might be a better fit. This would make it work more nicely with Playwright and also seems to be more actively maintained compared to mirage recently. However, transitioning would require a significant amount of work.

yeah, I looked into msw a couple of months ago. another alternative would be the network mocking built into playwright, but that obviously won't work with the other test suite.

I guess whether it's worth porting to e.g. msw depends on our needs in the future. If we migrate to a different frontend solution that supports server-side rendering then things become more complicated to test anyway. I think I saw you have experience with Svelte? how is testing handled in that ecosystem, in general and with SSR in particular?

[eth3lbert]

yeah, I looked into msw a couple of months ago. another alternative would be the network mocking built into playwright, but that obviously won't work with the other test suite.

Yeah, exactly. And it would also lead us to maintain two codebases for just mocking data.

I guess whether it's worth porting to e.g. msw depends on our needs in the future. If we migrate to a different frontend solution that supports server-side rendering then things become more complicated to test anyway. I think I saw you have experience with Svelte? how is testing handled in that ecosystem, in general and with SSR in particular?

In general, we would be testing with Vitest. SvelteKit's official guide also has a brief section on how to use it for testing ¹. It also supports a wide range of frameworks ², which makes it a good candidate for a testing framework. Vitest can mock APIs with multiple methods but also shows how to use MSW for mocking requests³.

For SSR, I haven't had much experience testing SSR with SvelteKit, so I won't delve too deeply into that part. However, MSW still seems like a good candidate. Based on the Next.js example ⁴, I believe it should be relatively easy to maintain both browser and SSR tests.

Footnotes

1. https://svelte.dev/docs/svelte/testing#Unit-and-integration-testing-using-Vitest ↩

2. https://vitest.dev/guide/#examples ↩

3. https://vitest.dev/guide/mocking.html#requests ↩

4. https://github.com/vercel/next.js/tree/canary/examples/with-msw ↩

[Turbo87]

thanks! sounds like the msw route is the most promising then. do you think it's still worth it to try to land this PR here, or should we directly migrate to msw instead?

[eth3lbert]

Since we're going to change tomsw anyway, I think we should just directly migrate to it. Sorry for having put so much work on this PR. I think we could leave this open for a while, hoping that someone who knows better than us could leave some useful comments or suggestions before we complete the migration.

---

For modeling/faker, there's https://github.com/mswjs/data for msw.