Help needed - struggling to find/resolve a deprecation

I am having trouble tracking down a deprecation that’s preventing me from upgrading from 3.28 to 4.1.

I don’t see the deprecation warning when Embroider is disabled.

When I enable Embroider, I see the following warning:

[Warning] DEPRECATION: Usage of the Ember Global is deprecated. You should import the Ember module or the specific API instead. [deprecation id: ember-global] See https://deprecations.emberjs.com/v3.x/#toc_ember-global for more details. (vendor.js, line 36989)
    http://localhost:4200/assets/vendor.js:37105:17
    raiseOnDeprecation@http://localhost:4200/assets/vendor.js:36999:13
    http://localhost:4200/assets/vendor.js:37105:17
    invoke@http://localhost:4200/assets/vendor.js:37117:23
    deprecate@http://localhost:4200/assets/vendor.js:37073:28
    get@http://localhost:4200/assets/vendor.js:473:53
    eval code
    eval@[native code]
    ./node_modules/@embroider/util/ember-private-api.js@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:269:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/@embroider/util/index.js@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:280:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./helpers/ensure-safe-component.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:414:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/ember-headlessui/components/menu/item-element.hbs@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:40:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/ember-headlessui/components/menu/item-element.js@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:929:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/menu/item-element.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:249:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/ember-headlessui/components/menu/item.hbs@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:51:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/ember-headlessui/components/menu/item.js@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:940:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/menu/item.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:260:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/ember-headlessui/components/menu/items.hbs@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:62:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/ember-headlessui/components/menu/items.js@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:951:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/menu/items.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:271:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/ember-headlessui/components/menu.hbs@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:18:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./node_modules/ember-headlessui/components/menu.js@http://localhost:4200/assets/chunk.db035c1dbb051775798b.js:907:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/menu.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:227:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/page/navigation/solutions-menu.hbs@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:106:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/page/navigation/solutions-menu.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:348:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/page/navigation.hbs@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:73:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/page/navigation.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:315:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/page/header.hbs@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:51:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/page/header.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:293:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/page/index.hbs@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:62:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46
    eval code
    eval@[native code]
    ./components/page/index.js@http://localhost:4200/assets/chunk.aff63185560f92485a33.js:304:5
    __webpack_require__@http://localhost:4200/assets/chunk.b3178629548c49aae97e.js:31:46

When I run ember-try on the latest release, the first error I see is:

TypeError: Cannot read properties of undefined (reading '__loader')
                at eval (webpack://solomon-website/./node_modules/@embroider/util/ember-private-api.js?:17:26)
                at Module../node_modules/@embroider/util/ember-private-api.js (http://localhost:7357/assets/chunk.a5da01a59a0698c12dc4.js:236:1)
                at __webpack_require__ (http://localhost:7357/assets/chunk.ad013453f4fd41c7a43b.js:350:42)
                at eval (webpack://solomon-website/./node_modules/@embroider/util/index.js?:10:76)
                at Module../node_modules/@embroider/util/index.js (http://localhost:7357/assets/chunk.a5da01a59a0698c12dc4.js:247:1)
                at __webpack_require__ (http://localhost:7357/assets/chunk.ad013453f4fd41c7a43b.js:350:42)
                at eval (webpack://solomon-website/./helpers/ensure-safe-component.js?:5:86)
                at Module../helpers/ensure-safe-component.js (http://localhost:7357/assets/chunk.e40d78334092e7083666.js:414:1)
                at __webpack_require__ (http://localhost:7357/assets/chunk.ad013453f4fd41c7a43b.js:350:42)
                at eval (webpack://solomon-website/./node_modules/ember-headlessui/components/menu/item-element.hbs?:6:91)

When I search through the project, I can see several places where Ember.__loader is called. The only place I can find where Ember Global might come into play is did-update.js in @ember/render-modifiers which ember-headlessui depends on. However, that’s only targeting older versions of Ember:

const untrack = (function () {
  if (macroCondition(dependencySatisfies('ember-source', '> 3.27.0-beta.1'))) {
    // ember-source@3.27 shipped "real modules" by default, so we can just use
    // importSync to get @glimmer/validator directly
    return importSync('@glimmer/validator').untrack;
  } else if (macroCondition(dependencySatisfies('ember-source', '>= 3.22.0-alpha.1'))) {
    // we can access `window.Ember` here because it wasn't deprecated until at least 3.27
    // eslint-disable-next-line no-undef
    return Ember.__loader.require('@glimmer/validator').untrack;
  } else {
    // nothing needed here, we do not call `untrack` in this case
  }
})();

I’m not really sure where to go next so I’m reaching out here to see if someone with more experience can help steer me towards an answer?

Thanks! :pray:t3:

It’s possible that dependencySatisfies is giving you an unexpected answer. You should be able to see this spot in the build output and see whether dependencySatisfies became a true or a false.

If it’s wrong it could be because of:

  • a caching bug we’re still tracking down (rm -rf $TMPDIR/embroider)
  • or because in some monorepo situations NPM gives incorrect peerDependencies and dependencySatisfies is following the true NPM behavior. In this case you’d see that within @ember/render-modifiers directory that node -e "console.log(require('ember-source/package.json').version)" returns a version that isn’t the one your app actually uses.
1 Like

Many thanks @ef4, I really appreciate your help. Where should I be looking for the build output? I’ve tried building in debug mode but can’t find a reference to dependencySatisfies anywhere?

Am I supposed to log it out, as shown here: @embroider/macros' dependencySatisfies does not understand canary versions · Issue #1066 · embroider-build/embroider · GitHub

I mean that the code you pasted above from @ember/render-modifiers ends up somewhere in your app’s dist folder, and at that point the dependencySatisfies() will get replaced with either true or false. You can see which it is, and that would confirm if the macro is going the wrong way.

Hi @ef4, I’ve found myself battling against @ember/render-modifiers and dependencySatisfies again. Can I ask for your guidance?

My app is consuming an addon that uses @ember/render-modifiers.

The addon is my own and I am using npm link during development.

When doing so, I get the following error from glimmer: Error: Invalid modifier manager compatibility specified. I’m guessing from this discussion that it’s because dependencySatisfied can’t “see” which version of ember-source I am using (which is 4.1 in both app and addon). I am unable to confirm this, because I’ve been unable to get VSCode to debug the app.

I’ve tried adding Ember 4.1 as a peer dependency and an override in the addon. I also tried adding it as an override in the app, and a combination of both. Nothing gets be past the error.

The above isn’t a problem when I npm i the addon instead of symlinking, which is what I am doing. I am able to get on with life but wondered how to address this, in case others are facing the issue?

Is it a bug? If so, who should it be reported to?

Many thanks :+1:t2:

is your addon using render modifiers >= 2.0.3? Looks like there was a bugfix related to this in that release: Release Release 2.0.3 · emberjs/ember-render-modifiers · GitHub

Thanks @dknutsen, I spotted that.

The app and the addon both have @2.0.4 as a dev dependency.

Is it a bug? If so, who should it be reported to?

It’s a bug in both yarn and NPM and they seem uninterested in making it work correctly. (Maybe Yarn 3 gets it right, I haven’t followed closely, but Yarn 1 definitely doesn’t and Yarn 2… had adoption problems.)

peerDependencies are a really important concept. It’s important that an addon that needs things from ember-source will get the same copy of ember-source that the app is using, which is what peerDependencies achieve.

But yarn and NPM don’t implement peerDependencies correctly when you use linking (or workspaces).

In a monorepo setting, you can use pnpm with its dependenciesMeta.*.injected option to correctly share peerDependencies between several local packages.

In a symlinking setting, you need to link the peerDependencies manually. For example, if your app has a symlink pointing at your addon, your addon should also have a symlink in node_modules/ember-source pointing back at the app’s copy of ember-source.

As you’re testing these things, also be aware of potentially cache invalidation problems and delete $TMPDIR/embroider to be safe.

1 Like

I will add: why are we bothering to try to follow what Node does here, since it causes so much pain?

The answer is mostly down to tools like typescript. We could make our build discover dependencies however we want, but if that’s different from the Node default we can’t make typescript understand it natively.

What I hope is that typescript and other tools will eventually adopt something like import maps as a standard, in which case we’ll be free to not follow Node’s very badly designed dependency resolution system.

Thank you @ef4 , that’s really clear. I appreciate your time and feedback :+1:t2: