MT内部已经广泛使用，目前已开源
详情参考官网： https://ximing.github.io/mpbuild/ Github: https://github.com/ximing/mpbuild
背景
传统构建工具在小程序场景中存在适配限制。小程序的文件结构和运行机制与单页应用、多页应用不同，现有方案未覆盖部分工程化需求。
现有方案的限制
1. 微信开发者工具原生方案
现状： 多数小程序项目使用微信开发者工具的原生构建能力。
限制：
- 仅支持基础的 npm 包处理，未覆盖现代前端工程化所需的部分能力
- 不支持 TypeScript、Sass/Less 等预处理器
- 缺少代码分割和依赖优化能力
- 无法直接接入现有的前端工程化生态
2. 基于 Gulp 的解决方案
现状： 部分团队基于 Gulp 为小程序构建工作流。
可用能力：
- 实现简单，学习成本较低
- 可以针对 js、wxml、wxss、json 四种文件类型分别处理
- 能够复用部分开源处理插件
限制：
- 依赖分析不精确： 无法准确分析模块依赖关系，可能产生冗余代码
- 扩展受限： 难以适应复杂业务场景和技术演进
- 缺少同构支持： 需要将小程序同构到 Web 时，现有工作流无法复用
3. 基于 Webpack 插件的方案
现状： 一些团队通过 Webpack 插件适配小程序开发。
可用能力：
- 依赖分析能力
- loader 和 plugin 生态
- 代码分割和优化策略
限制：
- 构建模型不同： Webpack 以 bundle 为主要产物，小程序使用原生分包策略
- 适配成本较高： 需要配置和额外代码以处理小程序的特殊需求
- 可能增加启动开销： 过度 bundle 处理会影响小程序启动性能
mpbuild 的设计原则
1. 保留原生分包和文件结构
小程序的文件结构和运行机制决定了构建过程需要保留原生分包策略和文件语义。mpbuild 的处理原则包括：
- 保留小程序的原生分包策略，避免不必要的 bundle
- 保留文件语义，使构建产物的结构可读
- 在原有开发流程上增加工程化处理能力
2. 插件接口
mpbuild 使用插件处理具体转换逻辑：
- 核心负责文件处理流程
- 插件接口约定转换逻辑的接入方式
- 尽量复用社区已有生态，避免重复实现已有能力
3. 小程序与 Web 的代码复用
多端场景需要处理平台差异和构建差异：
- 相同业务逻辑可在小程序和 Web 端复用
- 可通过配置切换不同端的构建过程
- 项目可以逐步从小程序独立开发迁移到多端开发
实现能力
依赖分析
mpbuild 包含面向小程序的依赖分析：
- 通过 AST 静态分析识别模块依赖
- 支持识别
require()动态导入 - 分析图片、字体等静态资源的依赖关系
文件处理流程
文件处理流程包含以下优化：
- 增量构建只处理变更文件
- 多种文件类型可以并行处理
- 缓存中间结果以避免重复计算
前端工具集成
mpbuild 可以接入以下工具：
- JavaScript 工具：Babel、TypeScript、ESLint
- 样式工具：PostCSS、Less、Sass 等预处理器
- 代码质量工具：Prettier、ESLint、Stylelint
配置和开发辅助
按项目结构生成配置
- 根据项目结构推断配置
- 提供默认配置，减少重复配置
- 支持按需自定义，以处理复杂项目需求
构建过程反馈
- 提供错误提示和解决建议
- 提供构建性能分析，用于定位构建流程中的问题
多端和生态扩展
平台差异处理
mpbuild 为多端构建预留了以下机制：
- 使用抽象层隔离平台差异
- 不同平台使用各自的适配器
- 通过配置文件控制不同平台的构建逻辑
后续扩展
- 计划建设插件市场，提供插件发现和使用渠道
- 接收社区贡献
- 参与小程序工程化相关标准的讨论
结语
mpbuild 面向小程序的原生分包、依赖分析和工程化工具集成。它减少重复配置，并保留项目按需接入多端构建能力。实际使用时仍需结合项目的文件结构、运行平台和启动性能要求选择构建配置。
