Upgrading an ExtJS application from 4.1.2 to 6.x

Question

I'm acquiring an existing application written in ExtJS 4.1.2. It's a very large code base. The 4.1.2 application was built without CMD -- the sources are added directly to index.html.

Without having much of an ExtJS background, I have the following two questions:

1) Does it make sense to upgrade to 5.x first and then go from 5.x to 6.x? Or is it safe to go directly from 4.1.2 to 6.x?

2) Should a new project be created and manually copied over, or can I just update the sources, in theory, to point to the new extjs lib, and back peddle fixing all client code that's broken or no longer compatible?

I haven't followed the history of ExtJS much, so I'm not sure if upgrading two major revisions is even feasible with this framework.

What's the best approach if CMD isn't being used in the existing app?

Answer 1

I am using Ext.js in production, and we are currently doing a similar upgrade. We are on 4.1.1. Here is what we have done.

1) Does it make sense to upgrade to 5.x first and then go from 5.x to 6.x? Or is it safe to go directly from 4.1.2 to 6.x?

We chose to upgrade to 5.x then 6.x. The reasoning behind this is because 6.x was not considered stable(at the time), and we would have less bugs to deal with. The biggest jump is going to be moving from 4.1.2 to 5.x. Moving to 6 from 5 is easy. 5.x included new features and changes to the API. 6.x is mostly behind the scenes technical debt that merged sencha touch and desktop, which is signficant because now you can have one app for mobile and desktop. You could probably move directly to 6 since it is much more stable than when it was in beta.

2) Should a new project be created and manually copied over, or can I just update the sources, in theory, to point to the new extjs lib, and back peddle fixing all client code that's broken or no longer compatible?

We chose to go with the second one. We replaced the entire extjs lib, and tested all client code then fixed it. It has gone pretty smoothly. We did have the benefit of using sencha architect. Sencha architect keeps the javascript code is json meta data files. When you want to upgrade, it can do automated checks. We also had a lot of code outside of of architect projects that is similar to what you have, and there have only been a couple problems. It was a 50-50 split.

One way to assess the feasibility of the upgrade is how closely intertwined the code is with Ext.Js. We had a developer write a mini-framework that extended core Ext classes and overrode a lot of the core methods for stores and views. It also had a convoluted plugin framework that touched the Ext.Js internals. Overriding those methods made the code very fragile during the upgrade. Probably 60% of our effort went into fixing that framework. There were other pages that was closely intertwined with Ext.Js that took a lot of effort to migrate as well. Code that was much simpler, for example it just created a widget with some listeners, did not need many changes.

As I understand it, Sencha CMD is the official packager, minifier, and dependency manager for the framework. When you upgrade with Sencha CMD, it just replaces the main library, and it doesn't do much for fixing the actual javascript. Sencha architect is where you get a lot of bang for the buck in terms of time saving.