Tracking remaining usage of the Ember global

[sandydoo]

With #19357 landing, there are a few deprecation notices being thrown even in brand new apps on 3.27-beta-1+.

Here’s a list:

• PR: Improve semver checks for the modules polyfill embroider-build/embroider#785
  In compiled templates built with Embroider.
  const createTemplateFactory = Ember.HTMLBars.template;

• PR: Remove usage of the Ember global embroider-build/embroider#784
  Before app boot, by ember-inflector from Ember Data
  Checks for Ember.ENV.EXTEND_PROTOTYPE in ember-inflector/make-configurable.js.

• PR: [BUGFIX beta] Remove Namespace processing #19509
  On didBecomeReady
Object.keys is being called on the internal app context in findNamespaces, which includes the Ember “global”. tryIsNamespace then accesses the Ember object.

Steps to reproduce

Run ember new with ember-cli@3.27.0-beta.1. Inspect the console.

Relevant versions

ember-cli: 3.27.0-beta.1
ember-source: 3.27.0-beta.3
ember-data: 3.27.0-beta.0
ember-cli-htmlbars: 5.7.1
@embroider/compat: 0.39.1
@embroider/core: 0.39.1
@embroider/webpack: 0.39.1

[pzuraq]

@sandydoo can you confirm that the first issue is still a problem? That is specifically caused by ember-cli-htmlbars, since it is the addon responsible for compiling templates, and should have been resolved by this PR: ember-cli/ember-cli-htmlbars#683

If that's still an issue, we definitely need to take a look into it.

[sandydoo]

@pzuraq, I did some more testing.
So the first issue only happens in Embroider builds. I think the line const createTemplateFactory = Ember.HTMLBars.template; is Webpack doing its thing, simplifying import { createTemplateFactory } from '@ember/template-factory';. I assume there is some way to tell Webpack not to do this?

To be fixed by embroider-build/embroider#785

[sandydoo]

The second issue is coming from @embroider/compat. I’ll take it up over there.

What about the last one?

[pzuraq]

I thought we tried to get rid of the Namespace stuff, I'm unsure why we had to keep it in the end. It's odd that tests pass too, even with it. I'll dig in soon.

[simonihmig]

I am seeing a huge number of false positives triggering this deprecation. I understand this is related to not having the latest version of https://github.com/ember-cli/babel-plugin-ember-modules-api-polyfill (which is a dependency of ember-cli-babel). But this is very easy to get into, when you are not updating your lock file, or have other addons that still depend on older versions where things like npx yarn-deduplicate won't fix this.

Just wanted to mention this here, as we can expect a lot of users will run into this...

[rwjblue]

@simonihmig - Yes, true. Folks not doing relatively routine lock file maintenance have no way to update to get our fixes. I'm not 100% sure what we can do about it though. 🤔

[pzuraq]

@sandydoo the final issue should have been fixed by #19509, we removed the namespace processing entirely. That fix should be backported to beta in the next release.

[MelSumner]

@pzuraq do you consider this issue resolved?

[sandydoo]

@MelSumner, technically, yes, but the Ember-specific fix (#19509) never made it to 3.27. So with the Ember global deprecation enabled in 3.27 (#19457), you now end up with a wall of deprecation notices even in brand new apps. That’s why I was waiting for a release before closing.

[pzuraq]

@sandydoo that bugfix was backported to 3.27: https://github.com/emberjs/ember.js/commits/v3.27.0

Are you still seeing this issue?

[sandydoo]

@sandydoo that bugfix was backported to 3.27: v3.27.0 (commits)
Are you still seeing this issue?

@pzuraq, you’re totally right! My bad, @MelSumner! Thanks, everyone!