我正在获取一个用 ExtJS 4.1.2 编写的现有应用程序。这是一个非常大的代码库。 4.1.2 应用程序是在没有 CMD 的情况下构建的——源代码直接添加到 index.html。
没有太多ExtJS背景，我有以下两个问题：
1) 先升级到 5.x 再从 5.x 升级到 6.x 有意义吗？还是直接从 4.1.2 升级到 6.x 安全吗？
2) 应该创建一个新项目并手动复制它，还是理论上我可以更新源代码以指向新的 extjs 库，然后再兜售修复所有损坏或不再兼容的客户端代码？
我没有过多关注 ExtJS 的历史，所以我不确定使用这个框架升级两个主要版本是否可行。
如果 CMD 没有在现有应用程序中使用，最好的方法是什么？
【问题讨论】：
标签： javascript extjs
我在生产中使用 Ext.js，我们目前正在进行类似的升级。我们在 4.1.1。这是我们所做的。
1) 先升级到 5.x 再从 5.x 升级到 6.x 有意义吗？还是直接从 4.1.2 升级到 6.x 安全吗？
我们选择先升级到 5.x，然后再升级到 6.x。这背后的原因是因为 6.x 被认为是不稳定的（当时），我们需要处理的错误更少。最大的飞跃将从 4.1.2 迁移到 5.x。从 5 移动到 6 很容易。 5.x 包含新功能和对 API 的更改。 6.x 主要是合并 sencha touch 和桌面的幕后技术债务，这很重要，因为现在您可以拥有一个用于移动和桌面的应用程序。您可能可以直接移动到 6，因为它比 beta 时稳定得多。
2) 应该创建一个新项目并手动复制它，还是理论上我可以更新源代码以指向新的 extjs 库，然后再兜售修复所有损坏或不再兼容的客户端代码？
我们选择了第二个。我们替换了整个 extjs 库，并测试了所有客户端代码，然后修复了它。它进展得很顺利。我们确实受益于使用 sencha 架构师。 Sencha 架构师保存的 javascript 代码是 json 元数据文件。当您要升级时，它可以进行自动检查。在架构师项目之外，我们还有很多与您所拥有的代码类似的代码，并且只有几个问题。这是一个 50-50 的分裂。
评估升级可行性的一种方法是代码与 Ext.Js 的紧密程度。我们让一个开发人员编写了一个迷你框架，它扩展了核心 Ext 类并覆盖了许多用于存储和视图的核心方法。它还有一个复杂的插件框架，触及 Ext.Js 内部。覆盖这些方法会使代码在升级过程中变得非常脆弱。可能我们 60% 的努力都用于修复该框架。还有其他页面与 Ext.Js 密切相关，迁移也需要付出很多努力。更简单的代码，例如它只是创建了一个带有一些侦听器的小部件，不需要太多更改。
据我了解，Sencha CMD 是该框架的官方打包器、压缩器和依赖管理器。当您使用 Sencha CMD 升级时，它只是替换了主库，并且对修复实际的 javascript 没有多大作用。 Sencha 架构师可以让您在节省时间方面获得巨大的收益。
【讨论】：