如何从Sencha 4.2的esm-all.js还原项目文件夹结构？

核心结论 #

Sencha 4.2完全支持将打包后的单一文件拆分为标准的Model/View/Store等模块化结构，之前的"无法实现"说法是对框架机制的误解——4.2采用的是自身的Ext.define类定义+Ext.Loader加载机制，而非ES6模块，但足以实现代码拆分与模块化开发。

具体实施步骤 #

1. 分析并提取业务代码

• 定位业务类：用正则匹配Ext.define\('([^']+)',，从21万行的esm-all.js中提取所有自定义业务类（排除Ext.*开头的框架原生类）。每个业务类的代码块从Ext.define起始，到对应的闭合大括号结束。
• 区分框架与业务代码：业务类一般带有自定义命名空间（如MyApp.model.User），框架类为Ext.panel.Panel这类原生命名空间，直接过滤即可。

2. 搭建标准项目目录

创建符合Sencha规范的目录结构：

APP_FOLDER/
├── app/
│   ├── Model/
│   ├── View/
│   ├── Store/
│   ├── Controller/
│   └── Application.js
├── resources/
└── index.html

• 类与目录映射：MyApp.model.User对应app/Model/User.js，MyApp.view.Main对应app/View/Main.js（类名的每个分段对应目录/文件名，首字母大写）。

3. 配置模块加载器

在index.html中引入Sencha 4.2的核心框架文件（不再使用打包的esm-all.js），并配置Ext.Loader：

// 启用Loader并配置命名空间路径
Ext.Loader.setConfig({
    enabled: true,
    paths: {
        'MyApp': 'app' // 自定义业务命名空间对应app目录
    }
});

// 启动应用
Ext.application({
    name: 'MyApp',
    appFolder: 'app',
    launch: function() {
        // 迁移原打包文件中的应用启动逻辑到此处
    }
});

4. 迁移业务类并处理依赖

• 每个提取的业务类单独放入对应目录的文件中，每个文件仅保留一个Ext.define定义。
• 显式声明依赖：在类的requires数组中列出依赖的其他业务类，确保Loader能正确加载依赖链，示例：

Ext.define('MyApp.view.Main', {
    extend: 'Ext.panel.Panel',
    requires: [
        'MyApp.controller.Main',
        'MyApp.store.Users'
    ],
    // 类的配置与方法
});

5. 调试与验证

• 用浏览器开发者工具的网络面板检查模块加载状态，若出现404错误，检查命名空间与目录路径的映射是否正确。
• 采用渐进式迁移：先迁移简单的Model/Store，验证功能正常后再迁移复杂的View/Controller，避免一次性全量迁移导致的问题。

推进建议 #

• 先小后大：从独立无依赖的小模块开始迁移，验证加载机制正常后再处理复杂模块。
• 备份原始文件：保留esm-all.js的备份，迁移过程中出现问题可快速回滚。
• 利用Sencha Cmd：用sencha generate app MyApp ./APP_FOLDER命令生成标准项目结构，减少手动建目录的工作量，后续还可通过Cmd重新打包拆分后的代码。
• 处理全局逻辑：原打包文件中的非类全局初始化代码，迁移到Application.js的launch方法或单独的初始化文件，通过Ext.require确保加载时机正确。

内容的提问来源于stack exchange，提问作者asd123ea