从 Wepy 到 UniApp 变形记 _生活百科

作者：vivo 互联网前端团队-Wan Anwen、Hu Feng、Feng Wei、Xie Tao

进入互联网“下半场”，靠“人海战术”的研发模式已经不再具备竞争力，如何通过技术升级提升研发效能？前端通过Babel等编译技术发展实现了工程化体系升级，如何进一步通过编译技术赋能前端开发？或许我们 wepy 到uniapp 编译的转换实践，能给你带来启发。
一、背景随着小程序的出现，借助微信的生态体系和海量用户，使服务以更加便捷方式的触达用户需求。基于此背景，团队很早布局智能导购小程序（为 vivo 各个线下门店导购提供服务的用户运营工具）的开发。
早期的小程序开发工程体系还不够健全，和现在的前端的工程体系相差较大，表现在对模块化，组件化以及高级JavaScript 语法特性的支撑上。所以团队在做技术选型时，希望克服原生小程序工程体系上的不足，经过对比最后选择了腾讯出品的 wepy 作为整体的开发框架。
在项目的从0到1阶段，wepy 确实帮助我们实现了快速的业务迭代，满足线下门店导购的需求。但随着时间的推移，在技术上，社区逐步沉淀出以 uniapp 为代表的 Vue 栈体系和以 Taro 为代表的 React 栈跨端的体系，wepy 目前的社区活跃度比较低。另外随着业务进入稳定阶段，除少量的 wepy 小程序，H5 项目和新的小程序都是基于 Vue 和 uniapp 来构建，团队也是希望统一技术栈，实现更好的跨端开发能力，降低开发和维护成本，提升研发效率。
二、思考随着团队决定将智能导购小程序从 wepy 迁移到 uniapp 的架构体系，我们就需要思考，如何进行项目的平稳的迁移，同时兼顾效率和质量？通过对当前的项目状态和技术背景进行分析，团队梳理出2个原则3种迁移思路。
2.1 渐进式迁移核心出发点，保证项目的平稳过渡，给团队更多的时间，在迭代中逐步的进行架构迁移。希望以此来降低迁移中的风险和不可控的点。基于此，我们思考两个方案：
方案一融合两套架构体系
在目前的项目中引入和 uniapp 的项目体系，一个项目融合了 wepy 和 uniapp 的代码工程化管理，逐步的将 wepy 的代码改成 uniapp 的代码，待迁移完成删除 wepy 的目录。这种方案实现起来不是很复杂，但是缺点是管理起来比较复杂，两套工程化管理机制，底层的编译机制，各种入口的配置文件等，管理起来比较麻烦。另外团队每个人都需要消化 wepy 到 uniapp 的领域知识迁移，不仅仅是项目的迁移也是知识体系的迁移。
方案二设计 wepy-webpack-loader
以 uniapp 为工程体系基础，核心思路是将现有 wepy 代码融入到 uniapp 的体系中来。我们都知道 uniapp 的底层依赖于 Vue 的 cli 的技术体系，最底层通过 webpack 实现对 Vue 单组件文件和其他资源文件的 bundle 。
基于此，我们可以开发一个 wepy 的 webpack 的 loader，wepy-loader 类似于 vue-loader 的能力，通过该 loader 对 wepy 文件进行编译打包，然后最终输出小程序代码。想法很简单，但我们想要实现 wepy-loader工作量还是比较大的，需要对 wepy 的底层编译器进一步进行分析拆解，分析 wepy 的依赖关系，区分是组件编译还是 page 编译等，且 wepy 底层编译器的代码比较复杂，实现成本较高。
2.2 整体性迁移构建一个编译器实现 wepy 到 uniapp 的自动代码转换。
通过对 wepy 和 uniapp 整体技术方案的梳理，加深了对两套架构差异性的认知和理解，尤其 wepy 上层语法和 Vue 的组件开发的代码上的差异性。基于团队对编译的认知，我们认为借助 babel 等成熟编译技术是有能力实现这个转换的过程，另外，通过编译技术会极大的提升整体的迁移的效率。
2.3 方案对比