Upgrade Ember with ember-cli-deprecation-workflow

Published on Sep 04, 2015

When upgrading (especially to Ember 1.13) the amount of deprecation warnings can be overwhelming.

ember-cli-deprecation-workflow helps you tame the warnings and tackle the deprecations on your terms.


Links

Code

$ ember install ember-cli-deprecation-workflow
//in console
deprecationWorkflow.flushDeprecations()
//deprecation-workflow.js
window.deprecationWorkflow = window.deprecationWorkflow || {};
window.deprecationWorkflow.config = {
  workflow: [
    { handler: "silence", matchMessage: "Ember.create is deprecated in favor of Object.create" },
    //...
  ]
}

Transcript

If you’ve been upgrading your Ember app lately you may have noticed something, something in the console, namely all this yellow stuff. These are deprecations, and depending on where you are in the process, there can be a lot of deprecations. I didn’t do anything special to create these. This was just making Ember 1.13.9. And as you can imagine, this is really hard to get anything useful out of this because there’s just so much, and a lot of these are being caused by libraries, such as say an old version of Ember data.

So how do we turn this deprecation spew, that is a term that the core team has been using, into something useful? ember-cli-deprecation-workflow. This is a tool that allows us to block out the deprecation spew piece by piece as we work through it. Let’s get started with it.

This is an Ember-cli-addon, so we can just type ember install ember-cli-deprecation-workflow. So it’s installed, and then we’ll restart our servers so that we can get the addon code running. And then in our server we’ll restart it. We will go to logs. We don’t have to scroll down through all 1000 warnings. And then we’ll call deprecationWorkflow.flushDeprecations. What that’ll do is it’ll give us some code that we can copy and then paste into a config file.

Then in our Ember app, we’ll create a file within our configuration folder called deprecation-workflow.js, and we’ll paste that code in. Then when you restart, you’ll see that there are no warnings. It’s blocked them all out. How does it do this?

So it has an array of handlers, and they’re set to silence by default. And then they have a matchMessage, and that can either be directly a string or a [02:08], and anything that matches that message will be silence. There are two other possible values for that handler. One is throw and the other is log. log is what it does automatically. Let’s see that in action.

So here’s just logging out every time it has that deprecation. So let’s try to fix this one. We’ll search for Ember.keys, the deprecated thing, and this is all we can find. So that leads us to believe that it happens in one of our dependencies. We can check that by putting a throw. And so when we do throw, it will explode the first time it gets there.

Unfortunately this stack is not great. What we’re going to do is we’re going to turn it back to silence, and we’re going to leave a note that’s saying that This is happening in a dependency. One of the great things about this addon is that it lets you make these notes in the code where the entire team can read them instead of having to pass down tribal knowledge from person to person, saying like oh, see that error? We don’t worry about that error. That sets a very bad precedent.

Here we can have this almost as a to-do list and then we can make notes on each one saying what needs to happen before it’s cleared up. This also means you don’t have to be as scared to upgrade. Conscientious teams would often hold off upgrading because they wanted to be able to fix all of the deprecations immediately, and that’s gotten more difficult towards the end of the 1.x cycle. Now you can upgrade and then set the ones that aren’t able to be fixed yet to silence and take care of that as your team has time.

So that’s ember-cli-deprecation-workflow. It’s a valuable tool in your upgrade process. Good luck and I’ll see you next week.

Subscribe to our mailing list