What did I break? I seem to have 2 different versions of the same dependency

Questions
#1

TL;DR I seem to have two miragejs modules and this causes some problems:

  1. webpack://__ember_auto_import__/./node_modules/miragejs/dist/mirage-esm.js?
  2. webpack://__ember_auto_import__/./node_modules/<my-dependency>/node_modules/miragejs/dist/mirage-esm.js?

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 miragejs itself.

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 Association from 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 miragejs modules.

#2

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.

#3

Thanks, Ed. Both consumers do ask for the same version of miragejs. I will check out the link.

#4

Perhaps there is a third consumer of miragejs that is preventing these two from getting hoisted together by npm/yarn?

#5

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.

#6

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.

#7

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.

#8

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.

#9

Thanks for the followup, it sounds like this situation is a potential ember-auto-import bug we could handle better.