Micro‑Module Framework for Frontend Code Reuse and Efficient Deployment

Sun Ling‑Shan and Wang Xiao‑Long joined Qunar Travel in 2019, working in the Front‑End Service Platform team on after‑sale and travel‑mall related back‑ends.

The rapid growth of business logic has caused front‑end projects to become increasingly large, with many similar or identical modules across different systems. Improving code reuse, enabling cross‑technology‑stack module sharing, and accelerating deployment have become critical goals.

Analyzing mainstream reuse solutions revealed the strengths and limitations of npm packages, Webpack 5 Module Federation, micro‑frontend frameworks such as qiankun, and low‑code approaches. A comparative table summarizes their applicable scenarios and existing problems.

Based on these findings, the design goals for the micro‑module framework are: low intrusion (no changes to existing code or build process), dynamic loading of the latest module version, rapid deployment with one‑click rollback, independent development of modules, and comprehensive module documentation powered by dumi.

The overall architecture consists of a module publishing pipeline that runs rollup and Babel plugins to compile and bundle the module, then deploys the assets to a CDN. A Node‑based service with MySQL stores version information, provides version‑control APIs, and serves module metadata. Host applications only need to install a base plugin to fetch and render modules.

The base plugin leverages native ES Module support in browsers. For example:

<script type="module">
import react from 'http://www.xxx.com/react.js';
// ...other imports and initialization...
</script>

Modules are developed as ordinary static‑asset projects that include source code and dumi documentation. Custom Babel plugins transform code to ESM format and generate a version file containing a hash fingerprint. The version file is stored in the database and mirrored on the CDN.

Each module contains a JSON configuration file. During publishing, a hash of the bundled output is compared with the stored hash; only when the hash changes is the version number incremented and synchronized to the database. The final version file collection enables browsers to retrieve the correct static resources for each module.

Monitoring covers module loading, version fetching, and rendering. If the Node service becomes unavailable, the base plugin automatically falls back to the CDN to ensure uninterrupted operation.

Integration methods differ for React and non‑React hosts. In a React project, developers run npm install @qnpm/unitter and use:

import React from "react";
import { MicroModule } from "@qnpm/unitter";

export default class Test extends React.Component {
  render() {
    return (
);
  }
}

For non‑React applications, a global configuration script is injected:

<script>
  window.UnitterConfig = {
    commonConfig: {
      versionsUrl: "",
      qzzPath: "",
      vendorDomain: ""
    },
    modulesConfig: [{
      name: "TestModule",
      props: {},
      el: document.getElementById("unitter-test-module")
    }]
  };
</script>

Two major issues were encountered: (1) React version incompatibility between the micro‑module (using React 18) and the host application, solved by dynamically loading a dedicated React version within the base plugin; (2) long full‑project build times and occasional memory overflow. An incremental build strategy was introduced via a Git pre‑commit script that detects changed module directories, writes them to an updates file, and limits the build scope, reducing total packaging time from ~11 minutes to under 3 minutes.

Benefits include a >70 % reduction in development effort when refactoring legacy code into micro‑modules, and dramatically faster deployment and rollback (single 3‑minute deployment versus n × 15‑minute npm deployments, and 30‑second rollbacks). A single deployment updates all hosts that consume the module.

Future work focuses on mobile‑browser compatibility, polyfills for legacy browsers lacking import‑map support, and performance optimization by aggregating frequently used dependency bundles based on runtime usage statistics.

In summary, the micro‑module approach decomposes complex business logic into small, maintainable units, enabling rapid iteration, independent maintenance, and efficient release cycles for frequently updated front‑end features.