Ember-cli upgrade process

Ember CLI
1

I’m curious about people’s techniques for upgrading ember-cli. The ember-cli docs say to do ‘ember init’ in my project folder, which is fine. However when the latest files get dropped in I have to deal with a bunch file overwrites to core project files (index.html, start-app.js, router.js, etc) with no option to do a merge. Of course I can always run ‘ember init’ in a new tmp project and then merge the file tree with my project file tree.

Just wondering if anyone’s found a better mechanism or tactic for upgrading ember-cli.

3 Likes
2

When you run ember init, you can hit the d key to get a diff of each modified file, which in my experience is sufficient to separate out the new, important stuff and the changes you’ve made under the previous version.

3

The upgrade process is definitely somewhat annoying/laborious, but the fact that it exists and helps you continue on the progression forward is pretty wonderful (I am likely biased though). I maintain many ember-cli applications (for work and personal projects alike), and the upgrade process generally takes 10-20 minutes for each app.

The process that I use is to open both my file editor and a terminal (side by side preferably). Then in the terminal start ember init. Review the diff (by pressing d when prompted) for each file. If it is a file that my project has not made modifications to, I just hit y to replace it. If the file has been modified, just review the diff and make the changes needed to match the new version (you would do this in your file editor). Then press n in the terminal to tell ember init to leave your source file alone (because you have already updated the file manually).

13 Likes
4

+1 This is exactly the same method I use.

5

I do the same but with liberal amounts of screenshots and emoji.

1 Like
6

It varies on the size of the application, we’re about 2-weeks into porting our application to ember-cli. We opted for creating a separate application and bringing over everyone piece by piece. Converting the entire app, of its size, all at once would have been an impossible task.

7

I agree (it definitely depends, but I think the OP was referring to upgrading an application from one ember-cli version to another (sounds like you are referring to migrating to ember-cli initially).

8

One of the things that bugs me about upgrading is that it always over-writes my app title in app/index.html. What should I do to avoid that? I’m thinking maybe doing that document.title trick on the application route, but I don’t know.

9

Press ‘n’ when it prompts you about this file. It will not overwrite a file unless you tell it to. As with my current practice (detailed above): I look at the diff and edit the files in a different editor window, then once that edited file is saved I tell ember-cli ‘n’ do not update that file (because it has already manually been updated).

2 Likes
10

Or perhaps create a remote branch with in it an empty ember init project. Update this project and overwrite all, push it. Then let Git merge this remote in your project. When you first create the remote branch and start ember init with the same version you started your project with Git merge will understand the change.

1 Like
11

I just wanted to add, that there is an e option which will open your $EDITOR to edit the diff directly. Delete the lines with a + that you don’t want to add and/or replace the - at the beginning of lines to be deleted with a (space) to not remove them from the final version of the file. Save and close the diff and you’re done.

12

I use vim-fugitive and :Gvsplit for every changed file (git status) after overwriting everything except the README.

13

Think it was mentioned but, not with step by step instructions. Assuming you’re using Git for version control, this is what you might want to use:

$ rm -rf node_modules bower_components dist tmp
$ npm install --save-dev ember-cli@0.1.4
$ npm install
$ bower install
$ ember init # Accept to overwrite all files
$ git add --interactive

Then, you’ll be able to either accept or reject every change. Check man git-add if you’re not familiar with the interactive mode. Once you’ve staged all wanted changes:

$ git commit -m "Upgrade to 0.1.4"
$ git checkout -- .
$ git clean -f -d # Clean up any leftovers

Hope that helps.

6 Likes
14

Similar to the git interactive, I’ve found the upgrading (with files overwritten) to be easy.

I’m likely the oddball using RubyMine for my JavaScript development, but frankly it’s great. It’s super convenient to roll through the diffs and keep or remove whatever you want. So far, just works.

Last upgrade to 0.1.9 produced a warning but that was unrelated to process.

15

I find it sad to hear that it takes this long even for an expert such as yourself. Let alone the rest of us who might be struggling just to grok what the changes mean and why they are being used. It seems every time I upgrade ember cli I have to block a good part of my day to dedicate to research. What new dependencies are being added? What’s in the change log? What add ons are going to break if I upgrade? Am I in a position to cleanly roll back if the upgrade goes wrong, etc, etc. This not a knock on Ember CLI, but just a testament of how immature the entire node.js npm ecosystem is as a whole, let alone the wild and woolly world of bower components.

If I recall correctly @stefan said last year at ember conf the goal was to spend “5 minutes in the morning” and proceed. So I think more progress on improving the upgrade process will be a welcome addition to an already great project.

Fortunately, it is a significant improvement over EAK and complex grunt files. Unfortunately dependency management is a still a hassle.

I just wonder if there would ever be a way to make the init process smarter. Still pretty brute force approach. I suspect the brute force approach is the safest and most reliable. Just wish it was more amenable to automation.

I think making a distinction between app configuration and ember CLI configuration and then merge these into a coherent package.json and bower.json would be nice. Once Ember CLI gets stable and 1.0 I think there should be very little reason for the the init process to touch app files and source.

Perhaps one approach would be that Ember CLI perform a “static analysis” of app/project code and show a report of deprecation warnings. Almost like a JSHint thing. Saying stuff like “hey you have a problem with xyz file on line 123, might want to look into that…”

At what point does Ember CLI behave more like a smart compiler, and we just trust that it does the right thing on our behalf?

At any rate, automagically merging is a hard problem and I suspect manually managing the changes and diffs will be the safest thing to do for the foreseeable future.

1 Like
16

I wonder if there’s room for some custom jshint rules or something of the sort, that looks for outdated idioms and warns about them.

The first example I can think of is a change to the unit test blueprint, where ok(model); was changed to ok(!!model);

That would abate a few of the concerns about upgrading, and would facilitate more dramatic changes to CLI blueprints in the future.

EDIT: D’oh. Just re-read this post:

17

Is there a way to have the diff’s displayed ignore whitespace? It’s a real problem on windows, because of the line endings, or if somebody uses different tab/space settings than the initial files. I’m not sure if the line ending issue is with my setup or not, but it makes it very hard to read. I end up overwriting everything and then using Source Tree to stage/unstage the changes. It’s much faster than using the command line to view the diffs.

18

I’m interested in the static analysis approach. I look forward to you contribution on this point.

19

Press '‘d’ for diff. Start editing your file, then save. press d again for an updated diff. once you’re satisfied, perss ‘n’ to keep the file you modified.

With this method, there is no extra file, or multiple text files or screenshots that’s necessary. You just go editing the existing files one by one, exactly how you want. GG

20

Always been curious- what’s the “h” option for in the update process?

1 Like