滴滴开源小程序框架Mpx下一代脚手架升级之路详解

在软件编程领域，Mpx脚手架的版本更新对开发者来说是一桩需要谨慎处理的事。这中间包含着旧版带来的便捷与升级所需的高额成本之间的冲突。今天，我们就来聊聊这个关于Mpx脚手架升级的话题。

-- 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 基础配置

旧版本的便利

@mpxjs/cli@2.x版本有不少亮点。它能让项目里的配置和编译代码对开发者完全透明。比如，一家电商的前端团队在做一个小程序时，就能根据需要随意调整这些文件。而且，还能在原有模板基础上进行二次开发，适应不同的业务需求。这样，开发者们在实际操作中拥有了更多自主权。另外，通过远程模板初始化项目，开发者对底层配置有了更广阔的掌控空间。

此外，这种做法对定制化开发非常有利。比如，一家小游戏公司，在制作游戏应用时，就是通过这种方法持续调整设置，以适应游戏的具体要求，这让它们的开发流程变得更加顺遂。

升级面临的高成本

各团队升级到mpxjs/cli@3.x版本并非易事。升级过程中，几乎必须对cli代码进行修改。随后，还需在各个业务项目中逐一进行手动升级。以某知名互联网企业为例，其旗下众多业务线均采用Mpx。要想完成此类升级，需众多开发人员协同合作，投入大量时间与精力进行修改和调试。而且，每个业务场景可能还需满足不同的适配条件，这无疑进一步增加了成本。这也使得许多团队在升级时显得犹豫不决。

基于Vuecli的技术栈

改造方案依托于@vue/cli技术体系，具有创新性。在处理在线业务的前端小程序以及跨平台Web业务时，采用这一技术体系能更有效地理解改造方案。比如在若干新闻媒体公司的小程序及Web项目开发过程中。若采用此技术体系，能更有效地结合小程序的快速展示与Web的丰富功能。

我们熟悉@vue/cli的插件化设计，这种设计赋予了它高度的灵活性和可定制性。这就像一个积木系统，各式各样的插件就像积木块，能够拼凑出多样的效果，满足各种使用需求。

功能拆分的意义

从跨平台的角度来看，@mpxjs/cli的功能划分有其合理性。它将功能拆分成9个插件，每个插件都有其特定职责。比如，针对不同的开发模式，会有相应的插件进行适配，这就像生产线上的各个工序。这样的设计有助于提升开发效率。

针对开发跨平台应用的团队，这种设计十分人性化。以一家同时打造小程序和网页的旅行社为例，各类插件能够针对小程序与网页的各自特点进行优化，使得应用在各个平台上都能便捷地部署与运行。

编译构建配置的拆解

编译构建过程中，配置的拆分环节尤为关键。在VueCLI3.x版本中，其插件式架构通过检查项目是否安装了特定插件来决定是否启用相关功能。然而，由于Mpx的独特性，比如支持跨端开发、云函数等，因此，编译构建的基础配置被独立出来，形成了一个名为vue-cli–mpx的插件，并被设置为默认插件。

// 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.config.js
module.exports = {  pluginOptions: {    mpx: {      plugin: {// mpx-plugin 相关的配置      },      loader: {// mpx-loader 相关的配置      }    }  },  configureWebpack() {},  chainWebpack() {// 自定义的 webpack 配置  }}

插件开发过程中，平台的重要性不言而喻。以@vue/cli为例，它内含的配置适合用于web应用，但在小程序开发中却派不上用场。借助平台暴露功能，在构建阶段，开发者能够依据平台标识来选择激活哪些插件。比如，在进行工具类小程序开发时，开发团队就能利用这一标识来挑选出适合自己小程序平台的插件，从而避免不必要的配置干扰。

想要升级Mpx脚手架的团队面临着一个复杂的选择。他们是否具备足够的资源和实力去完成这一升级？希望读者们能对这篇文章给予点赞、转发，并在评论区分享你们的观点。