Upgrading Ember from 1.13 to 2.8.0

Jen Weber
Ember-ish
Published in
4 min readOct 28, 2016

Adventures in Brute Force Debugging, aka Should Have Read the Docs

Yo, this is a really old article that hasn’t been updated! If you want to get the latest, real way to update your app, check out Everything you need to know to upgrade your Ember.js app

I love Ember. I really do. But working in an app that was created pre 1.0 and has lots of aysnc, sometimes I hit vague errors that are impervious to Googling. Here’s the latest wall I hit and how I solved it.

The problem: after following through with deprecation recommendations for Ember Data, the app explodes with “find is not a method on object user” and nothing renders. Comment out that line in the route model hook, and it says the same thing for every single call to Ember Data. And the Ember inspector’s Data tab doesn’t even load.

The solution: ember-load-initializers was missing from app.js and my bower packages. What I should have done to upgrade my app was use the CLI, run init, and used the diff to catch any missing parts. And, I should have read the CLI docs instead of following the first Google search result for “upgrade Ember”. Facepalm. Thanks to Nathan Hammond for setting me straight on the right way to upgrade an Ember app.

The debugging path and error details:

My app was version 1.13. The Ember Guides and release notes say that “If your app runs on Ember 1.13 without raising deprecations, it should run on 2.0.” And one of my coworkers had already cleaned up deprecations, so it should be smooth sailing, right?

So, I changed Ember and Ember Data to 2.8 in package.json and bower, then installed. The app ran with a deprecation error:

WARNING: Please remove ember-data from bower.json. As of Ember Data 2.3.0, only the NPM package is needed. If you need an earlier version of ember-data (< 2.3.0), you can leave this unchanged for now, but we strongly suggest you upgrade your version of Ember Data as soon as possible

After I removed ember-data from bower.json, nothing worked at all. Any attempt to access the store in model hooks was met with something like “find is not a method on object user.” I was tempted to just leave ember-data in bower.json and move on, but I suspected that I wasn’t accessing Ember Data itself properly and it would haunt me in the future. Thus began epic brute force debugging, since my error was so vague.

Step 1, fruitless Google searches.

Step 2 check the Guides to make sure nothing had changed about how I was supposed to access and return objects in the route’s model hook. Try a few other methods like findRecord and query. Same error.

Step 3, run a search of the whole codebase for “ember-data” to see if my colleagues had done something funky to it. Nope.

Step 4, check the top of files for the line import DS from ‘ember-data’. No problems there.

Step 5, become skeptical at the services injections, and comment them all out. No dice.

Step 6, ask for help on the Ember Community chat, where I was advised to run ember init and look at the diff on the files. This seemed like a crazy amount of code to go through in my console, and I really didn’t know what I was looking for, so I gave up pretty quickly. But we’ll come back to this later.

Step 7, beg a coworker for help and talk out my remaining ideas. He is skeptical of outdated addons and suggests that maybe something is requiring this zombie bower.js ember-data package or causing a namespace clash. Comment things out. Clear bower/npm cache and reinstall. No luck.

Step 8, running out of ideas. Decide to create a new 2.8 Ember repo and then compare core files side-by-side until I find out what’s different in the boilerplate.

And that’s where I found it. In app.js:

import loadInitializers from ‘ember-load-initializers’;

and just before the export,

loadInitializers(App, config.modulePrefix);

At some point, these lines were in that file but unneeded in 1.13. And without them, Ember Data was utterly wrecked in my upgraded app. I added those lines in and installed the load initializers addon, and we were back in business.

At the time, I didn’t know what the load initializer was, but it was A Thing That Looked Important and adding it in was faster than trying to figure out what it was.

After I solved the problem, I asked for some insight in the Ember Community chat (again) about what I should have done to avoid this pain. And it turns out that using Ember CLI’s init and diff is the recommended path, not just a debugging approach.

Lesson learned. I’m excited to get started with Ember Fastboot, Liquid Fire, and all the other awesome things that are only available in 2+.

--

--

Jen Weber
Ember-ish

Huge fan of Ember.js, open source, HTML, and accessible, inclusive web apps. www.jenweber.me