Cross‑Team Multi‑Mini‑Program Development Solution Based on Taro

Background – With the rapid growth of mini‑programs, cross‑platform frameworks like mpvue, Chameleon, and Taro have become mainstream. However, complex business scenarios (e.g., 58 New‑House business across WeChat, Baidu, and other platforms) still face challenges such as differing team stacks, brand skins, and platform‑specific APIs.

Challenges – The article lists six pain points: (a) different teams using native, wepy, Taro, etc.; (b) tight coupling between business and platform teams; (c) need for environment‑specific implementations; (d) code bloat; (e) platform‑specific capabilities (account, messaging); (f) multiple integration approaches (plugin, sub‑package).

Overall Architecture – Built on Taro 1.3, the solution adds four layers on top of the standard Taro stack: configuration layer, source layer, adaptation layer, and packaging layer.

1. Configuration Layer

• Build scripts – Add environment‑specific scripts in package.json :

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

• Define constants – Use Webpack’s DefinePlugin to expose compile‑time variables:

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

• Sass theme handling – Map each mini‑program to its own SCSS file:

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

• Page selection – Configure which pages belong to which mini‑program:

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

In app.tsx the pages are injected at compile time:

class App extends Component {
    config: Config = {
        pages: PAGES,
    };
}

2. Adaptation Layer

• Feature toggles – Conditional rendering removes unused code during bundling:

import TabBar from '../components/tabbar';
export default class _C extends Component {
    render() {
        return {(WEAPPSOURCE == WBWEAPP) &&
};
    }
}

• Unified API – Platform‑specific implementations are wrapped behind a common function:

export const getCityInfo = () => {
    if (WEAPP_SOURCE == WBWEAPP) {
        city_info = WBIndex.WB.getCityInfo();
    } else if (WEAPP_SOURCE == AJKWEAPP) {
        city_info = AJKIndex.Common.getCityInfo();
    }
};

• Plugin integration – Platform mini‑program injects its APIs into a shared plugin object:

module.exports = { WB: {} };

const plugin = requirePlugin("xinfang");
plugin.WB = { getCityInfo: function() {} };

• Sub‑package integration – APIs are attached directly to the App instance (e.g., getApp().Common.getCityInfo = function() {} ).

3. Packaging Layer

The build process parses app.tsx , performs two rounds of syntax transformation, and uses babel-plugin-danger-remove-unused-import to drop dead code. Conditional compilation ensures that only the code required for the target mini‑program is emitted, keeping the final bundle size optimal.

4. Integration Methods

Three deployment strategies are supported:

Plugin integration – the business mini‑program is loaded as a plugin inside the platform mini‑program.

Sub‑package integration – the business code is packaged as a sub‑package and referenced via a unified API.

Independent mini‑program – the business code runs as a standalone mini‑program with its own APIs.

Practical Experience

Key lessons include handling JSON configuration files via config.copy.patterns , normalising navigation paths in the adaptation layer, and using conditional compilation to minimise bundle size.

Problem Solving Summary

Cross‑team source collaboration is achieved by separate repositories and plugin/sub‑package integration.

Decoupling is realised through a unified API layer.

Differentiated development (styles, configs, features) is handled by the configuration and adaptation layers.

Optimal bundle size is ensured by conditional compilation and dead‑code elimination.

Platform API differences are abstracted in the adaptation layer.

Both plugin and sub‑package integration are supported.

Conclusion & Future Planning

The presented solution enables rapid rollout and iteration of the New‑House business across multiple mini‑programs, and the same approach can be extended to other platforms (Baidu, H5). Future work aims to define a universal API standard to further simplify cross‑team development.