ember-cli / ember-cli-deprecation-workflow

MIT License
165 stars 43 forks source link

Introduce setup step #117

Closed mixonic closed 2 years ago

mixonic commented 3 years ago

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 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:

mixonic commented 3 years ago

I think the limitations of this approach are less than ideal. I spiked out an alternative approach in https://github.com/mixonic/ember-cli-deprecation-workflow/pull/118