小程序工程化思考

和传统工程化对比

下图列出传统前端工程化关注的内容（from umi）。

小程序的工程化空间受运行时和框架能力限制，下面按能力逐项比较：

1. 框架：可选方案包括 kbone、taro、remax/r2m、mpvue、mpx 等。以优选业务覆盖的移动设备为准，这些方案存在体验问题或已停止维护，因此仍基于原生框架开发。小程序不提供直接操作视图的底层 API、组件层级管理和模板递归，并限制包大小与路由模型；这些限制也影响了框架方案的可行性。
2. TypeScript：缺少适用于小程序的统一规范，原生 TypeScript 支持难以覆盖复杂场景。
3. 样式（CSS）：由于缺少视图层接口，样式方案选择有限。微信提供 @import 等模块化能力；受包大小限制，可使用 PostCSS 加变量插件或 CSS 变量管理样式。
4. JavaScript 编译、模块打包和压缩：这是可投入建设的部分。webpack 不适用于小程序，可采用基于 Babel 的 mpbuild，或基于 esbuild/SWC 的 mpe。
5. 路由管理和请求库：实现受小程序框架提供的方案限制，可定制空间较小。
6. 资源加载方式：资源固定为小程序主包和子包。新版基础库提供动态加载能力，但存在两个限制：
   1. 基础库版本不满足要求的小程序无法使用。
   2. 仍需在构建时集成资源，不能像传统微前端架构那样从远端加载代码。
7. 数据流：可以建设，但小程序没有 Context 能力，方案的使用方式难以与传统前端框架对齐。
8. 代码风格：使用 ESLint、Prettier 等工具约束。
9. 文档能力和通用组件开发能力：需要投入建设。
10. 测试：需要结合投入产出决定覆盖范围，业务团队通常不会优先投入。 对比可见，小程序中可直接复用传统工程化思路的部分有限，工程投入应更多放在业务集成和业务领域能力上。

小程序框架对比传统前端框架缺少什么

演进视角看小程序当下成熟度对比

2021 增补