How to Build and Deploy a Multi‑Mini‑Program Architecture with Taro

Background

Mini‑programs are proliferating, and cross‑platform frameworks such as mpvue, Chameleon, and Taro enable “write once, run everywhere”. Complex business scenarios require sharing core logic across multiple mini‑programs (e.g., 58 New House, Anjuke) while handling brand‑specific differences.

Challenges

Different teams use native, wepy, Taro, mpvue, making source‑level collaboration difficult.

Business and platform teams need minimal coupling.

Environment‑specific adaptations are required for each mini‑program.

Unified code management can increase bundle size if not optimized.

Platform‑specific capabilities (account, messaging) differ.

Both plugin and sub‑package integration approaches must be supported.

Overall Architecture

The solution builds on Taro 1.3 and adds a configuration layer and an adaptation layer, allowing a single source tree to be packaged into multiple mini‑programs. The architecture consists of four layers:

Configuration layer – handles environment variables, theme styles, and page configuration.

Source code layer – contains unchanged business logic.

Adaptation layer – abstracts platform‑specific APIs and provides a unified interface.

Packaging layer – works with the configuration layer to produce final bundles.

Configuration Layer

1) Build script configuration – add scripts in package.json using cross‑env to set WEAPPSOURCE for each target.

{</code><code>  "build:weapp": "taro build --type weapp",</code><code>  "build:wbweapp": "cross-env WEAPPSOURCE=wbweapp taro build --type weapp",</code><code>  "dev:wbweapp": "cross-env WEAPPSOURCE=wbweapp npm run build:weapp -- --watch"</code><code>}

2) Define compile‑time constants in config/index.js to drive conditional code removal.

config.defineConstants = {</code><code>  WEAPPSOURCE: JSON.stringify(process.env.WEAPPSOURCE),</code><code>  WBWEAPP: '"wbweapp"',</code><code>  AJKWEAPP: '"ajkweapp"'</code><code>};

3) Theme style handling – extract brand‑specific colors into separate Sass files and load the appropriate file based on WEAPPSOURCE.

const sassConfig = {</code><code>  wbweapp: '../wbweapp.scss',</code><code>  ajkweapp: '../ajkweapp.scss'</code><code>};</code><code>config.plugins.sass.resource = path.resolve(__dirname, sassConfig[process.env.WEAPPSOURCE]);

4) Page configuration – map each target to the pages it needs and inject the list via a compile‑time constant.

const pagesConfig = {</code><code>  wbweapp: ['pages/a'],</code><code>  ajkweapp: ['pages/b']</code><code>};</code><code>config.defineConstants = {</code><code>  PAGES: JSON.stringify(pagesConfig[process.env.WEAPPSOURCE])</code><code>};

In app.tsx the pages are set from the constant:

class App extends Component {</code><code>  config: Config = { pages: PAGES };</code><code>}

Adaptation Layer

1) Feature differentiation – use the compile‑time constant to include or exclude components.

return {(WEAPPSOURCE == WBWEAPP) && <TabBar/>}

When the condition is false, the component and its markup are removed during bundling.

2) Unified API wrapper – platform‑specific implementations are hidden behind a common function.

export const getCityInfo = () => {</code><code>  if (WEAPPSOURCE == WBWEAPP) {</code><code>    return WBIndex.WB.getCityInfo();</code><code>  } else if (WEAPPSOURCE == AJKWEAPP) {</code><code>    return AJKIndex.Common.getCityInfo();</code><code>  }</code><code>};

Packaging Process

The build performs two syntax transformations. The first handles generic JSX/TSX conversion. The second, driven by the target type, applies custom plugins such as babel-plugin-danger-remove-unused-import to drop unused imports and code paths, ensuring that only the necessary assets are bundled.

Integration Methods

Three ways to release the final mini‑programs:

Independent release – each mini‑program is built and deployed separately, providing its own APIs.

Plugin integration – the host mini‑program loads a plugin that exports a unified API object.

Sub‑package integration – the host mini‑program injects the business APIs into its global App object.

Plugin example:

// plugin/index.js</code><code>module.exports = { WB: {} };</code><code>// host mini‑program</code><code>const plugin = requirePlugin("xinfang");</code><code>plugin.WB = { getCityInfo: function() {} };

Sub‑package example: getApp().Common.getCityInfo = function() {}; For sub‑package integration, the business code is built into a separate output directory (configured via config.outputRoot) and then merged into the host repository using Git.

Practical Tips

Copy JSON configuration files (e.g., plugin/plugin.json) via config.copy.patterns.

Normalize navigation paths by prefixing them based on the environment variable, allowing seamless switching between plugin and sub‑package modes.

Problem‑Solving Summary

Cross‑team source collaboration is achieved by separating repositories and integrating via plugins or sub‑packages.

Business and platform teams are decoupled through a unified API layer.

Styling, configuration, and feature differences are handled via compile‑time constants and Sass resources.

Bundle size is optimized by conditional compilation and unused‑import removal.

Platform‑specific API differences are abstracted in the adaptation layer.

Both plugin and sub‑package integration are supported.

References

https://www.npmjs.com/package/cross-env

https://nervjs.github.io/taro/docs/config.html

https://webpack.js.org/plugins/define-plugin/

https://www.npmjs.com/package/uglifyjs-webpack-plugin

https://github.com/mishoo/UglifyJS2#compress-options