This PR only updates the "main" JS implementation. It does not attempt to remove global Ember interactions from the template compilation deprecation catcher. https://github.com/mixonic/ember-cli-deprecation-workflow/pull/107 simply removed the template compilation catcher, which I would like to avoid doing.
This PR would require that users of deprecation workflow add setup(self) to their app.js or another appropriate location. Likely they might want to only call setup( if running in a dev build. It isn't clear exactly how to document/automate that. (Finally it is possible someone might want to run deprecation workflow in a production build when running tests. That should be left as an exercise to the consumer IMO). We can probably suggest using https://api.emberjs.com/ember/3.26/classes/@ember%2Fdebug/methods/runInDebug?anchor=runInDebug
It also isn't clear if the payload in addon/index.js will still be a no-op in production. Generally deprecation workflow today is pretty clever about not adding any weight (from the config file or from its JS) to production builds. We likely need a solution for this since the config file is obnoxious to ship to prod, but this PR doesn't address/change the config file anyway.
TODO:
[ ] Figure out a solution for setup( being added upon installation, or document it
[ ] Figure out how to continue to make the JS a no-op in production build, or show it already is
Adapting from https://github.com/mixonic/ember-cli-deprecation-workflow/pull/107, avoid referencing the
Ember
global.This PR only updates the "main" JS implementation. It does not attempt to remove global
Ember
interactions from the template compilation deprecation catcher. https://github.com/mixonic/ember-cli-deprecation-workflow/pull/107 simply removed the template compilation catcher, which I would like to avoid doing.This PR would require that users of deprecation workflow add
setup(self)
to theirapp.js
or another appropriate location. Likely they might want to only callsetup(
if running in a dev build. It isn't clear exactly how to document/automate that. (Finally it is possible someone might want to run deprecation workflow in a production build when running tests. That should be left as an exercise to the consumer IMO). We can probably suggest using https://api.emberjs.com/ember/3.26/classes/@ember%2Fdebug/methods/runInDebug?anchor=runInDebugIt also isn't clear if the payload in
addon/index.js
will still be a no-op in production. Generally deprecation workflow today is pretty clever about not adding any weight (from the config file or from its JS) to production builds. We likely need a solution for this since the config file is obnoxious to ship to prod, but this PR doesn't address/change the config file anyway.TODO:
setup(
being added upon installation, or document it