I seem to have two
miragejs modules and this causes some problems:
About the dependencies: I have an Ember add-on whose dummy app uses
ember-cli-mirage which depends upon
miragejs. I also include my package as a dependency that depends upon
This discovery came about because I noticed a strange issue and started debugging…
While stepping through some Mirage code, I found the issue. Mirage does a check to see if a model’s property is an instance of Mirage’s
Association class and this check was failing, to my surprise. Here’s where things got weird (to me)…
The Mirage source was in
webpack://__ember_auto_import__/./node_modules/miragejs/dist/mirage-esm.js? whereas in my code I have a Mirage model with a property that’s an instance of
webpack://__ember_auto_import__/./node_modules/<my-dependency>/node_modules/miragejs/dist/mirage-esm.js? thus the check in the Mirage code fails.
I’m wondering why/how I end up with seemingly 2 different
Do both the consumers of miragejs ask for compatbile semver ranges? If there’s not one version of miragejs that satisfies both consumers, they will indeed each get their own separate copy.
One way to solve this without waiting for upstream changes in your dependencies is to use selective dependency resolutions to force both packages to use the same version of miragejs.
Thanks, Ed. Both consumers do ask for the same version of
miragejs. I will check out the link.
Perhaps there is a third consumer of miragejs that is preventing these two from getting hoisted together by npm/yarn?
Or maybe the upgrade history of this app caused them to be different in the past, even though they’re the same now, and if you regenerated yarn.lock or package-lock.json they would get combined.
Thanks for the replies. There are only the 2 consumers of Mirage. I tried regenerating the yarn lock file but with no luck. Running
yarn why reveals that there’s only one version of
miragejs hoisted from all dependencies.
Perhaps of interest, the new package I’m working with is a file-based dependency, e.g.,
"<my-dependency>": "file:../<path-to-package>" in my package manifest.
Hmm, I’m going to guess it’s the file-based dependency. It seems maybe
ember-auto-import isn’t resolving dependencies imported in that package the same way it resolves dependencies of the actual npm packages.
Ok, I seem to have solved my problem. I pushed my new package’s work-in-progress to GitHub and changed my package manifest to pull from there. Now I don’t see a fork in the Mirage dependencies.
Thanks for the followup, it sounds like this situation is a potential ember-auto-import bug we could handle better.