which is actually good, because test-waiters needs to be resilient to:
copies of itself being loaded
copies of other libraries using the same waiter names
Adding embroider to the matrix helps verify that the problem is with auto-import having duplicate test-time dependencies, vs embroider fixing the problem and having only one copy of a dependency.
Why not use the try matrix, like in the blueprint?
try matrix already has/had embroider specified, but none of the test-apps were set up with maybeEmbroider -- it turns out as well that the ember-concurrency stuff isn't compatible (it's an old version, and I'm considering a separate PR to move all the thennable and generator tests into the main test app, but without using ember-concurrency, so that it's better declared what we're actually supporting, and more unit-testy, rather than e2e-y)
because debugging is easier this way -- ember-try messes with the local node_modules which makes getting back to a non-ember-try state a bit harder (sometimes pnpm i isn't enough).
because we want to be able to debug both classic and embroider quickly, it makes sense that someone would even have both running at the same time.
Tests against strictest embroider -- which we weren't doing before.
This is important because in the v2 addon conversion, I ran in to
which is actually good, because test-waiters needs to be resilient to:
Adding embroider to the matrix helps verify that the problem is with auto-import having duplicate test-time dependencies, vs embroider fixing the problem and having only one copy of a dependency.
Why not use the try matrix, like in the blueprint?
pnpm iisn't enough).