Migrate from ember-cli-mirage to miragejs

[hashicc]

Description

ember-cli-mirage is an old ember addon that relies on ember's legacy build magic. The advice from mainmatter's migration blog is to ember-mirage:

ember-cli-mirage doesn't work correctly with Vite. The recommendation is to move to ember-mirage. For guidance, you can check out ember-mirage migration document or watch the talk Modern take on ember-cli-mirage that is ready for Embroider and Vite by Nick Schot.

However, ember-mirage provides an even lighter wrapper around miragejs that mostly helps with setting up test helpers, and doesn't provide any build magic.

There are two things that ember-cli-mirage provided in terms of build magic (and ember-mirage would not do for us):

1. Include miragejs in the build (eg: import { createServer } from 'miragejs';)
2. Conditionally include our app's mirage handlers in the build when mirage is enabled

Both of these could be solved if api was a v2 addon. A v2 addon is statically analyzable from the app to the addon. So if something isn't used in the dependency graph it isn't included in the build. For v1 addons, the dependencies are included wholesale. There's a chicken/egg situation in moving the api addon to v2. We currently use some build magic to include sqlite web workers in the workers folder. In a v2 world the addon would be built to a dist folder and the consuming app would need to consume the dist folder. This skips the just-in-time build magic relationship addons currently have with their consuming apps. This will likely be easier once we use vite for main app's because vite has first-class support for splitting worker bundles. Getting rid of ember-cli-mirage is a blocking step in moving our main apps to vite, then api addon would migrate more easily to a v2 addon.

For 1. Because we have a classic v1 addon its dependencies are included wholesale. The route I took was to rely on ember-auto-import configuration within the api addon being able to see its consuming app's config and dynamically include miragejs and any dependency used by the handlers (manually listed).

For 2. Include app's mirage handlers in the build, this leans on an addition to a funnel already used by sqlite to exclude workers from the final build.

---

There are two things that ember-cli-mirage did to start mirage when enabled by config:

1. Inject code to start mirage when enabled in non-test scenarios
2. Provide test helper to start mirage in test scenarios

For 1., I used @embroider/macros which uses build time magic to include/exclude branches of code based on "macro conditions", a limited set of options that are set up at build time. This set up must be done per consuming app and is covered by the README updates..

For 2., a test helper was created based on ember-cli-mirage's test helper.

---

With the build, test and mirage helpers in place the files were moved to their new location, imports were updated and mostly everything else continues to work.

How to Test

1. By default mirage should be enabled for admin and desktop when using pnpm start (ember development). This can be checked easily from the vercel environments.
2. When doing a production build pnpm build for admin or desktop, the miragejs, @faker-js/faker dependencies should not be included. The easiest way to check for this is to do a grep for mirage or faker within dist and check results.
3. When ENABLE_MIRAGE=true is used, mirage should be included in the build and should be started automatically for admin and desktop
4. When ENABLE_MIRAGE=false is used, mirage should not be included in the build and should not be started automatically for admin and desktop
5. All tests should continue to pass using the test helper
6. From the browser dev console of a running ember app when mirage is expected to be booted require.entries['mir should autocomplete with with the miragejs dependency, and require.entries['api/mir should autocomplete with the api/mirage handler results.

Checklist

- [ ] I have added before and after screenshots for UI changes
- [ ] I have added JSON response output for API changes
- [ ] I have added steps to reproduce and test for bug fixes in the description

• I have commented on my code, particularly in hard-to-understand areas
• My changes generate no new warnings
  - [ ] I have added tests that prove my fix is effective or that my feature works
  - [ ] I have added a11y-tests label to run a11y audit tests if needed

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.
• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
• If applicable, I've documented the impact of any changes to security controls.
  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
boundary-ui	Ready	Preview	Comment	Dec 1, 2025 4:04pm
boundary-ui-desktop	Ready	Preview	Comment	Dec 1, 2025 4:04pm