After years of Ember development, it seems I’m still confused about the recommended way to upgrade Ember. My main confusion is about compatibility between the different line items in
package.json. I don’t use
ember-data, so I really just care about updating
ember-source. But since a default Ember CLI app has a few other packages, it’s unclear what I need to update.
ember-cli-update, but without reading the source code, it’s not really clear what it does. At this point in time, I tried updating to 3.11 and discovered that it doesn’t check for available updates of
ember-source, it checks for available updates of
ember-cli! This was kind of unexpected, but I’m assuming that after upgrading
ember-cli, it goes and overlays the default
ember new blueprint and expects the user to resolve conflicts and then run
npm install?. Because of this confusion, it doesn’t really seem like a viable solution.
Starting this post to hear from other’s experience upgrading Ember.js and how they go about it. Maybe the right solution is to really consider every line item in package.json individually, just like I would with any other Node app, and resolve incompatibilities as they arise?
I think ember-cli-update is by far the easiest solution.
If your concern is that you didn’t get ember-source 3.11, that’s because ember-cli 3.11 hasn’t released yet. Because ember-cli has to curate the set of other packages (which already must be released), ember-cli gets released last. It will presumably be released imminently.
It works this way because the version of ember-source (and everything else) in the blueprints is controlled by ember-cli. It needs to be that way for
ember new to be a thing.
ember-cli-update gives a good three-way diff between the blueprint you’re coming from, the blueprint you’re going to, and your own actual app. This is nice because whatever standard things you’re using and didn’t customize (including all the default dependencies in package.json) just automatically upgrade with no intervention. Whereas you’ll get a diff to resolve if you customized something and then the underlying blueprint also changed – which can save you a lot of debugging.
If you want the most curated, low-risk solution, wait for ember-cli 3.11 and run ember-cli-update. If you don’t want to wait, it’s also totally fine to start upgrading things yourself (particularly ember-source, which is not very tightly coupled) and it will almost certainly work, but you will on occasion hit a problem and realize some other package needs updating too.
I’ve experienced this confusion too. I’ve wondered if there could be a way to completely isolate ember-cli dependencies within package.json or another manifest format to better distinguish application and tooling dependencies.
I completely agree. I used to update our ember project manually. In typical Internet fashion I complained aloud without trying to fix it (“General Workflow” slide). ember-cli-update has helped greatly reduce busywork with upgrades. With ember-cli-update, I have it installed globally and then follow these steps:
- Resolve irrelevant file changes like updates to the README.md. (
git checkout -- README.md)
- Resolve any unexpected changes manually
- commit and PR
Huh, did not know this; I’ll have to try it on the next upgrade.