前言

为什么需要这样一个框架，以及这个框架带来的好处是什么？

从字面意思上理解：该框架可以用来同时管理多个小程序，并且可以抽离公用组件或业务逻辑供各个小程序使用。当你工作中面临这种同时维护多个小程序的业务场景时，可以考虑使用这种模式。灵感来自最近
webpack
的多项目打包构建

起步

首先你得先安装好
taro
脚手架，然后基于该脚手架生成一个
taro
项目

初始化taro项目

taro init miniApp

这是我选择的初始化配置，你当然也可以选择其它模版，只要编译工具选择
webpack
就可以，下面的步骤基本相同

打开项目安装依赖

pnpm install

这样一个基本的taro项目就生成好了，但这样只是生成了一个小程序，那我们如果有许多个小程序是不是还要按上面这些步骤继续生成，当然不需要，这样不仅费时间，而且难以维护。

下面我们就来把这个框架改造成支持同时管理多个小程序。

改造（支持多小程序）

此时的项目结构是这样的：

  • config
    下面是一些小程序以及
    webpack
    的配置
  • src
    下面是我们小程序的项目代码
  • project.config.json
    是当前小程序配置文件
  • ...

改造目录

在
src
目录下新增目录：
apps
、
common

  • apps
    ：小程序目录，存放各个小程序的代码
  • common
    ：公用目录，存放公用组件及业务逻辑代码

apps

这里每个小程序对应一个文件夹，里面存放对应小程序的代码

这里需要把根目录下的
project.config.json
放到小程序目录下，因为每个小程序都需要自己的配置文件

比如：nanjiu、nanjiu_notebook两个小程序

common

这里主要是存放公用代码：组件、业务、请求

修改配置

config/index.js


import path from 'path'
const app = process.env.APP

const config = {
  projectName: 'mini_app',
  date: '2024-1-21',
  designWidth: 750,
  deviceRatio: {
    640: 2.34 / 2,
    750: 1,
    828: 1.81 / 2
  },
  sourceRoot: `src/apps/${app}`, // 项目源码目录
  outputRoot: `${app.toUpperCase()}APP`,  // 打包产物目录
  alias: {
    '@/common': path.resolve(__dirname, '..', 'src/common'), // 别名配置
  },
// ....

module.exports = function (merge) {
  if (process.env.NODE_ENV === 'development') {
    return merge({}, config, require('./dev'))
  }
  return merge({}, config, require('./prod'))
}

这里需要注意的是
sourceRoot
，因为要支持多小程序，那么这里就不能固定写死了，我们可以在启动时通过传参来区分当前启动或打包哪个小程序。

自定义构建脚本

在项目根目录新建文件夹
build
存放构建脚本

// cli.js

const shell = require('shelljs')

const fs = require('fs')

const path = require('path')

const inquirer = require('inquirer')
const action = process.argv[2]

let app =  process.argv[3]

const runType = action == 'dev' ? '启动': '打包'
function start() {

// 处理配置文件

process.env.APP = app

console.log(`

标签: none

添加新评论