Mpx 开源之路:多项重要功能升级,解决小程序开发平台适配痛点

2024-06-23
来源:网络整理

介绍

Mpx在开源路上已经走了五年,目前支撑滴滴内部全方位小程序业务拓展,是滴滴开源委员会孵化的精品项目。

从 2022 年至今,我们对 Mpx 框架进行了多项重要的功能升级,包括合并 API 开发规范、分包异步构建支持、单元测试能力建设,以及今天要重点介绍的 @/cli 脚手架升级等,希望能够为小程序开发者用户带来更新更好的开发能力和体验。

小程序技术自2017年发布以来,凭借跨平台、简单快捷、用户体验极佳等特点,受到企业和个人开发者的青睐。以微信、支付宝为代表的各大厂商均推出了自己的小程序平台,但各家技术标准并不统一,小程序开发的平台适配成为开发过程中的痛点之一。

企业和个人开发者开始考虑如何让一套代码在多个小程序平台、跨网页端运行,降低成本、提高效率。在小程序技术发展的这几年,开源社区也涌现出了Taro、Mpx等致力于提升开发者效率和体验的小程序框架。

其中Mpx是滴滴开源的增强型跨端小程序框架,在单文件组件、语法增强、工程化等方面提供了良好的开发体验,并基于响应式数据渲染机制、包大小优化,以及同构一份源码输出所有小程序平台及网页环境的跨端能力,拥有极致的应用性能,因此在业界获得了不少开发者用户的好评。

Mpx 开源五年,目前支持滴滴内部小程序全线业务开发,是滴滴开源委员会孵化的精品项目。2022 年以来,我们对 Mpx 框架进行了多项重要功能升级,包括组合 API 开发规范、分包异步构建支持、单元测试能力建设,以及今天要重点介绍的 @/cli 脚手架升级等,希望为小程序开发者用户带来更新更好的开发能力和体验。

作为滴滴小程序开发最基础的工具套件,@/cli 脚手架能力的改造基于滴滴实际业务开发场景,以及原有@/cli@2.x 遇到的问题和痛点。整个脚手架工具重新设计升级至 3.x,为滴滴生态开发者提供简单易用、即用、标准化、可扩展性更强的脚手架能力。如何基于新版@/cli@3.x 搭建符合业务要求的脚手架,点击文章下方原文可参考文档指南。

1.

脚手架@/cli@2.x与滴滴业务场景的双重痛点

在Mpx脚手架升级之前,原有的脚手架@/cli@2.x在滴滴小程序业务场景和自身的架构方向上遇到了一些挑战和痛点。

痛点一:/cli@2.x 本身的痛点

在升级Mpx脚手架@/cli@3.x之前,@/cli@2.x会将初始化项目中所有的配置文件和编译后的构建代码暴露给开发者,开发者可以根据自己实际的项目开发需求修改这些文件,同时也可以将这套原有的模板文件扩展为符合自己业务场景的模板。

具体来说,基于模板配置初始化一个项目的整个工作流程是:

-- mpx-project |-- src // 项目源码 |-- config // 项目配置文件   |-- index.js // 配置入口文件   |-- mpxLoader.conf.js // mpx-loader 配置   |-- mpxPlugin.conf.js // mpx webpack-plugin 配置   |-- user.conf.js // 用户的 prompts 选择信息 |-- build // 编译构建配置 |-- build.js // 构建编译脚本 |-- getPlugins.js // webpack plugins |-- getRules.js // webpack module rule   |-- getWebpackConf.js // webpack 配置生成辅助函数   |-- utils.js // 工具函数   |-- webpack.base.conf.js // webpack 基础配置

基于远程模板初始化项目最大的好处是,项目所有底层配置都完全暴露给开发者,开发者可以随意修改相应配置。但是 2.x 模板对于用户和开发者都存在痛点。

对于用户:

对于开发人员:

痛点二:滴滴业务场景痛点

在实际的小程序业务场景开发中,滴滴线上业务场景和其他业务团队都遇到过痛点。从线上业务前端负责的业务来看,业务开发与迭代有三大特点:

基于业务迭代的三大特点,不同的业务场景在小程序的产品形态上也增加了:包括独立小程序;宿主&分包小程序;跨端输出Web及小程序插件等。面对复杂的业务场景,目前的@/cli2.x能力捉襟见肘,已无法再基于mpx-灵活扩展符合自身业务场景的模板。

与此同时,滴滴其他业务团队也有很多定制化的开发需求,各个团队也基于Mpx小程序维护着符合自身业务开发场景的脚手架工具+远程模板。但这种模式带来的问题是各个业务团队与@/cli2.x的联系割裂,根本没办法感知@/cli2.x的任何功能更新。如果各个团队想跟进升级,基本都需要修改cli代码,然后在各个业务项目中手动升级,成本非常高。

Mpx根据以上实际业务场景发展以及@/cli2.x本身遇到的问题和痛点,重新设计并迭代了解决方案@/cli3.x。

2.

插件化改造解决方案五大特点解读

我们整体的改造方案是基于@vue/cli技术栈的,后面会以线上业务前端小程序&跨Web业务场景为例,更好的向Mpx开发者讲解具体的改造方案,在此之前我们先来了解一下@vue/cli的插件架构:

@vue/cli@3.x 以上版本相比 2.x 版本架构发生了较大变化,由基于模板的脚手架变成了基于插件的脚手架,整个插件架构简单总结如下:

1.@vue/cli 提供vue cli命令,负责首选项设置、模板生成、vue-cli-依赖管理,例如vue、vue add

2、@vue/cli——作为整个@vue/cli插件体系的内部核心插件,提供npm注册服务,内置一些配置,并提供vue-cli-的导入、加载及配置更新服务。

以上就是@vue/cli生态中最核心的两个部分,二者分工明确,各司其职。另外@vue/cli生态中很重要的一点就是vue-cli-,各个插件主要完成模板生成和生产编译构建配置。根据@vue/cli设计的规范,开发一个vue-cli需要遵循相关的约定进行开发:

1、@vue/cli约定插件如果想要生成模板,需要提供入口文件;

2.@vue/cli-约定插件配置更新需要放在插件入口文件中完成,同时插件名也需要包含vue-cli-前缀,因为@vue/cli-会根据名称来加载相关插件。

具体来说,在线业务前端的纯 Web 端技术栈为 Vue,因此在脚手架的选型上也采用 Vue 提供的脚手架。在线业务前端不同品类、不同业务的所有项目基本都是以脚手架的形式进行开发的,这意味着脚手架提供的能力需要具备足够的可扩展性,同时脚手架本身也需要具备足够的收敛性,以支撑各品类、各业务方向的快速迭代。

因此在线上业务前端业务快速迭代的过程中,我们始终在不断调研并实践社区中好的技术方向和工具。@vue/cli@3.0 发布后,我们也对其进行了升级改造,利用@vue/cli@3.0 的插件化设计,将纯 Web 方向的业务场景、目录结构、依赖、技术衔接、基础工程搭建整合成一个业务的融合体,将原来的迭代方式转换为业务和插件的迭代。

从模板维护迁移到插件化设计的@vue/cli@3.0脚手架之后,已经很好的支持了产品开发过程中多品类、多业务场景的迭代。我们不需要再维护单独的底层脚手架工具,而是拥抱开源,使用@vue/cli的底层能力,只需要专注于维护业务和对应的插件功能即可。

在小程序业务场景中,我们也遇到了和之前在 Web 端多品类、多业务方向迭代时遇到的相同问题。我们也借鉴了@vue/cli 的能力和架构设计来支撑小程序的业务拓展。核心思想是使用@vue/cli 作为@/cli 的底层引擎,汇聚 Mpx 在核心依赖管理、模板、构建配置方面的能力,并充分利用@vue/cli 提供的插件机制,构建和扩展上层的插件集。

微信小程序开发框架的逻辑_微信的产品逻辑框架_微信开源框架

图为@/cli插件化改造后的架构设计

特点一:底层能力

我们分别使用@vue/cli和@vue/cli-作为@mpx/cli和@mpx/cli-的底层能力,采用插件式的架构设计,同时也灵活满足了Mpx针对差异化场景迭代的定制化改造。上层插件满足vue-cli-plug-in开发的规范,最终底层能力还是依赖@vue/cli和@vue/cli-才能发挥作用。

特点2:上层插件可拆分

我们将原本庞大而全面的模板拆分成插件,从Mpx想要解决的问题出发,从四个角度考虑:基于微信小程序的跨Web开发、跨平台(ali、swan、tt、dd)小程序开发、利用云函数的微信小程序开发、微信小程序插件模式开发。一个项目可能只需要某一种开发模式,比如微信小程序插件模式开发,或者小程序和Web平台混合开发等。不同的开发模式对应不同的目录结构,不同的编译构建配置。

基于这种情况以及@/cli要解决的问题,我们从跨平台的角度进行功能拆分,最终分解为如下9个插件:

这些拆解后的插件将功能相关的项目模板以及编译构建配置进行了聚合,借助@vue/cli的API,可以按需生成项目开发所需的模板,比如项目需要某个功能,那么在生成项目时就会生成vue-cli--mpx-提供的对应模板文件,如果不需要,那么在项目中就不会出现相关的文件配置。

值得一提的是编译构建配置是如何分解的:在@vue/cli@3.x的插件化架构设计中,决定是否使用某个插件的依据是判断这个插件是否被你的项目安装。相比于模板化架构,最大的不同在于模板化架构需要在最终生成的模板配置中保存一些环境配置文件,用于编译构建运行时判断是否开启某些功能。而插件化架构基本不再需要这些环境配置文件,因为如果你想使用某个插件的功能,只需要安装它即可。

因此按照这样的设计规范,我们将 unit-test 等非常独立的功能抽离成了可插拔的插件,安装后即可启用。上述功能的一个特点就是完全和平台解耦,因此在拆解过程中可以拆得比较彻底。但由于 Mpx 项目的特殊性,既要支持基于微信小程序的跨端、Web 开发,又要支持针对小程序的云功能、小程序插件模式的开发,而不同开发模式的编译构建配置有些不同。可以用下面的集合图来表示它们之间的关系:

不同的插件组合使用可以满足不同场景的需求。在不同的平台开发模式下,对于mpx的编译构建都有一个基础的配置,跟平台关系不大,所以把这部分配置提取出来变成了一个插件:vue-cli--mpx,并且这个插件也被设置为@/cli的默认插件。无论任何项目开发模式,都会默认安装这个插件。

// vue-cli-plugin-mpxmodule.exports = function (api, options, webpackConfig) { ...
webpackConfig.module .rule('json') .test(/\.json$/) .resourceQuery(/asScript/) .type('javascript/auto')
webpackConfig.module .rule('wxs-pre-loader') .test(/\.(wxs|qs|sjs|filter\.js)$/) .pre() .use('mpx-wxs-pre-loader') .loader(MpxWebpackPlugin.wxsPreLoader().loader)
webpackConfig.resolve.extensions .add('.mpx') .add('.wxml') .add('.ts') .add('.js')
webpackConfig.resolve.modules.add('node_modules') ...}

小程序开发模式中,vue-cli--mpx-mp会在vue-cli--mpx

在mpx-web基础上扩展配置,满足小程序的编译构建。在跨web开发模式下,vue-cli--mpx-web会在vue-cli--mpx和@vue/cli的基础上扩展配置,满足web端的开发、编译构建。

特性三:增强Web平台编译构建能力

在@/cli@2.x版本中,web端编译构建的配置比较基础,常用功能如热更新、MPA多页应用等都需要用户手动重新搭建一套。@vue/cli@3.x针对vue项目而生,为web应用提供了非常完善的编译构建打包配置。

所以@/cli@3.x版本中一个很重要的任务就是复用@vue/cli的能力,弥补Mpx项目在跨web项目编译构建方面的不足。

因此关于mpx跨web编译构建的部分也被抽取出来作为一个插件:vue-cli--mpx-web,这个插件的工作就是将@vue/cli提供的web编译构建能力适配到mpx项目上,通过这种方式来增强mpx跨web项目的编译构建能力。

这也意味着@vue/cli提供的能力基本可以在Mpx跨web项目中使用了。

特点四:项目配置具有扩展能力

如果您要配置和扩展@/cli@2.x版本的项目,您基本上需要执行以下两个步骤:

这也是文章开头提到的基于模板的大型全面的文件组织方法。

在最新的@/cli@3.x版本中,所有项目配置扩展都集中到vue..js文件中,减少了开发人员需要了解项目结构的心智负担。

// vue.config.js
module.exports = { pluginOptions: { mpx: { plugin: {// mpx-plugin 相关的配置 }, loader: {// mpx-loader 相关的配置 } } }, configureWebpack() {}, chainWebpack() {// 自定义的 webpack 配置 }}

特点5:目录结构更简单

经过此插件改造后,项目结构变得更加简单,开发者只需要关注src源码目录和vue..js配置文件即可:

-- mpx-project |--src |--vue.config.js

特点六:基于平台维度构建配置

虽然最新版本的@/cli 是基于@vue/cli 插件架构进行升级的,但是由于 MPX 项目开发的特殊性,不同插件之间的协作还是有一些约定的。例如@vue/cli 内置了一些配置,由于@vue/cli 是专门针对 Web 应用的,所以这些配置会在所有的编译构建过程中生效,但是其中有些配置对于小程序开发来说并不是必须的。

针对这种情况,为了避免不同模式下配置的相互污染。Web端的编译构建依然基于@vue/cli提供的能力,以适配mpx的Web开发。小程序端的编译构建配置则利用@vue/cli内部暴露的一些方法,跳过一些小程序开发非必须的配置,最终满足小程序的构建配置。因此在每一个插件的开发中,需要暴露该插件适用的平台,以便在实际构建过程中,通过平台标识来判断对应哪些插件会生效。

module.export.platform = 'mp' // 可选值:'web'

3.

拥抱开源,与社区共建

目前,@/cli最新版本已在滴滴内部各业务方向的小程序及跨端产品开发中逐步投入使用。

在这次@/cli重构升级工作中,我们并没有将所有底层能力代码从头编写,而是选择拥抱开源,依托@vue/cli提供的底层插件架构与模板能力,结合Mpx的技术架构(比如底层作为编译构建工具使用,Vue作为全Web的渲染框架)和实际业务场景进行扩展开发,在降低成本、提高效率的同时,也能充分实现重构的既定目标。

经过本次插件化改造,我们验证了@/cli@2.x 遇到的几个痛点在新的架构模式下得到了很好的解决:

此插件设计更好地统一了基于Mpx开发小程序的基础能力,建立了官方能力与实际业务开发能力的对接,可以满足不同团队的定制化需求。也希望社区用户在享受脚手架新版本带来的便利的同时,能够积极参与到新版本脚手架插件生态的共建发展中来,欢迎大家加入Mpx用户群进行共建交流。

推荐

分享