[Bug] Some Deprecations seem to side-step the deprecation workflow

[mansona]

🐞 Describe the Bug

I'm trying to get some of my addons ready for Ember 4.0 so I came up with the idea to make an ember-try scenario that has an addon that uses registerDeprecationHandler to just throw an error https://github.com/mansona/ember-deprecation-error

This is useful because it allows me to see the deprecation error and message in the tests rather than the more confusing errors when the code has actually been removed in the ember-beta and ember-canary scenarios

The problem that I've been facing is that there have now been 2 deprecations that have slipped through this net and my ember-try scenario is passing but there are still deprecations being console.logged to the stdout of the test run.

We should work on specifics to solve these 2 deprecations from slipping through the net but I'm more generally concerned about potential addon authors (or app devs) that have been "doing the right thing" using tools like ember-deprecation-workflow but are in for a surprise when Ember 4.0 is released

🔬 Minimal Reproduction

I have 2 branches on 2 repos that show this issue: First example CI output: https://github.com/empress/ember-cli-showdown/runs/3581167377?check_suite_focus=true#step:6:28 with the following deprecation:

DEPRECATION: registerPlugin is deprecated, please pass plugins directly via `compile` and/or `precompile`. [deprecation id: template-compiler.registerPlugin]

I have pushed a branch https://github.com/empress/ember-cli-showdown/tree/raise-investigation that is pointing at the commit that has the above CI output so you can recreate it if you would like. You will notice that I added the ENV variable RAISE_ON_DEPRECATION on advice from @kategengler (after a discussion in Discord) but that has no effect: https://github.com/empress/ember-cli-showdown/blob/raise-investigation/config/ember-try.js#L144

---

The second example I have is the "Use of Ember global" deprecation, again not being caught in the registerDeprecationHandler but still outputting to he console during a test https://github.com/empress/field-guide/pull/43/checks?check_run_id=3620451872#step:6:88

I have also created a branch that points to the commit associated with that CI run so that we can use it as a reference: https://github.com/empress/field-guide/tree/deprecation-error

😕 Actual Behavior

Console logging the deprecations errors

🤔 Expected Behavior

Failing the CI with the deprecation errors

🌍 Environment

• Ember: ember-release (via ember-try)
• Node.js/npm: npm@7 - Node 12
• OS: ubuntu-latest Github Action
• Browser: Chrome (in CI)

➕ Additional Context

Add any other context about the problem here.

[mansona]

Here is another case where the global deprecation isn't being caught by tests: jelhan/ember-style-modifier#51

[bertdeblock]

Could this be a timing issue where the deprecation is triggered before the handler is registered?

[patocallaghan]

Just wondering if the issue I'm seeing is related to this? The two deprecations mentioned here template-compiler.registerPlugin and ember-global are still appearing in our Ember build/server logs even though we've tried to silence them using deprecation-workflow.js.

I'm also seeing these deprecations other not being silenced even though I've added them to the deprecation-workflow.js.

• has-block-and-has-block-params
• ember-glimmer.with-syntax
• attrs-arg-access

[mixonic]

@patocallaghan deprecation workflow does not handle deprecations from the template compiler. This is a technical limitation (happy to discuss elsewhere, but for now please note it is documented in the README and expected). Changing this would be an issue on ember-cli-deprecation-workflow, not here.

I'm not sure RAISE_ON_DEPRECATION is handled by template compilation either. I don't think it is, but regardless that would need to be explored and addressed on the ember-cli-htmlbars project.

I'm not sure how to triage this broad ticket.