[Embroider] dependencySatisfies gives wrong answer for 'ember-source'

Hey,

I have a similar problem to Help needed - struggling to find/resolve a deprecation : I’m trying to get rid of the ember.global deprecation, and there’s a window.Ember usage in the ember-private-api.js file of the @embroider/util package:

if (
  macroCondition(
    dependencySatisfies('ember-source', '>=3.27.0-canary || >=3.27.0-beta')
  )
) {
  // new enough ember has a real module we can import
  runtime = importSync('@glimmer/runtime');
} else {
  // older ember has its own internal loader
  runtime = window.Ember.__loader.require('@glimmer/runtime');
}

The project uses version 3.28.6 of ember-source so the else branch shouldn’t be executed but for some reason it still does, triggering the deprecation.

Having read what @ef4 said on the other thread, I was looking for some other dependency that might pull in ember-source but there are lots, as a lot of add-ons have ember-source as a devDependency.

However, if I’m not mistaken, if Project A has a devDependency on Package B, and Package C is a devDependency of Package B, if I (yarn) install Project A, Package C will not be installed so as long as some add-on doesn’t have a (non-dev) dependency on ember-source, there’ll only ever be one ember-source in the whole of node_modules. Which is what I see when running yarn why ember-source.

So to be able to go on with this, I’d need to understand what dependencySatisfies actually checks.

Reading the source code it uses the package cache and Ed mentioned there is an outstanding bug, so I cleared the cache before building the app but it didn’t help.

Unfortunately putting breakpoints in Embroider code or logging out stuff didn’t get me very far so far so maybe understanding how a package dependency is resolved (specifically the pkg = packageCache.resolve(packageName, us); line in the implementation of dependencySatisfies) can unblock me faster.

Thank you!

5 posts - 2 participants

Read full topic