A cross-terminal cross-platform multi-framework fusion modular integrated system and method

Abstract

The application is suitable for the technical field of front-end engineering, and provides a modular integrated system and method for cross-terminal and cross-platform multi-framework fusion, which comprises a main engineering module, sub-engineering modules independently developed based on different front-end frameworks, a plug-in fusion module, a cross-terminal compatible layer and a build release module. The plug-in fusion module merges the sub-engineering business code, global styles, route configurations and common dependencies into the main engineering according to the subpackage directory, namespace and predefined protocol in the compilation phase. The cross-terminal compatible layer uniformly encapsulates the API differences of multiple platforms through the API layer, the adapter layer and the API implementation layer. The build release module is packaged according to the target platform. The method comprises compiling the sub-engineering on demand by the main engineering, plug-in fusion, abstract syntax tree conversion, shaking tree filtering and independent or fused release. The application is used for embedding in WeChat, Alipay, Douyin applet, H5 and native APP, and supports independent development, independent release and dynamic fusion of multiple teams.

Description

Technical Field

[0001] This invention belongs to the field of front-end engineering technology improvement, specifically involving a modular integration system and method for cross-platform, cross-terminal, and multi-framework fusion; it is particularly suitable for cross-platform development scenarios of mini-programs, H5, and native apps. This invention can be applied to various product forms such as WeChat mini-programs, Alipay mini-programs, Douyin mini-programs, independent H5 pages, internal app embedded modules, and third-party app embedded modules. It supports multiple teams using different front-end frameworks for independent development and release, and can dynamically integrate them into a unified application as needed. Background Technology

[0002] With the rapid development of multi-platform products such as mini-programs, H5, and native apps, front-end projects often need to provide consistent or similar business capabilities across different platforms and operating environments. In related technologies, many projects use a single framework for development; for example, all functional modules are developed using the Wepy framework and maintained within the same project, supporting only the WeChat mini-program platform. This approach has the following problems: First, the Wepy framework is no longer maintained, and it suffers from difficulties in abstracting and reusing identical components on the same page, insufficient support for third-party components or libraries, and the continued execution of component code and lifecycle even when components are hidden. Second, different modules developed by different teams can only be maintained in one project, easily leading to code and release conflicts. Third, feature updates usually require a full release, making independent module releases impossible. Fourth, cross-platform capabilities are weak, making it difficult to support the reuse and embedding of functions described by existing technologies in multiple mini-program platforms and native apps.

[0003] While micro-frontend architecture can address the issues of technology stack lock-in and collaboration coupling in web applications to some extent, it is primarily designed for web applications and is not suitable for mini-program scenarios. It struggles to solve specific problems related to mini-program sub-packages, route registration, platform API differences, and native app interactions. Therefore, a modular integration solution is needed that supports collaborative development across multiple teams, frameworks, and platforms, and can dynamically aggregate during the compilation phase and uniformly schedule at runtime. Summary of the Invention

[0004] The purpose of this invention is to provide a modular integration system and method that supports multiple teams to independently develop and release using different front-end frameworks, while also supporting dynamic fusion into a unified application. This aims to solve the technical problems of existing technologies such as technology stack locking, collaboration coupling, release blocking, and weak cross-platform capabilities.

[0005] To address the aforementioned technical problems, this invention provides a modular integration system that integrates multiple frameworks across different platforms and terminals. The modular integration system includes a main project module, several sub-project modules, a plug-in integration module, a cross-platform compatibility layer, and a build and release module. The main project module provides the basic framework and unified entry point for application operation. It pre-registers the namespaces and identifiers of each sub-project module. This main project module can serve as the main project for a mini-program, an H5 main project, or an embedded main project for an app, providing basic configurations, common dependencies, a global routing table, application entry files, build scripts, and runtime environment initialization logic. By pre-registering namespaces and identifiers, different sub-project modules can have unique routing prefixes, component identifiers, style scopes, and message channels after integration, avoiding naming and routing conflicts between different teams and different framework modules. It provides a unified operational foundation and unified management entry point for multi-framework integration, enabling each sub-project module to be accessed, run, and published in a plug-in manner.

[0006] Several sub-project modules are developed independently based on different front-end frameworks. Each sub-project module has independent routing configuration and dependency management, and exists as an independent sub-package or independent module. The front-end frameworks include the Wepy framework, the Taro framework, and the native mini-program framework. For example, the mini-program team can use the Wepy framework or the native mini-program framework to develop historical function modules, and use the Taro framework to develop new function modules; the intelligent operations team can use the Taro framework to implement marketing and promotion function modules; and the APP team can use H5 to develop fulfillment details and order placement modules. Each sub-project module can be independently developed, debugged, compiled, and released by different teams, or it can be integrated into the main project module as needed. This removes the limitations of a single framework on the team's technology selection, reduces code coupling and release blocking caused by multiple teams developing in the same project, and supports incremental technology stack upgrades.

[0007] The plug-in fusion module, connected to the main project module and each of the sub-project modules, is used to merge the business code, global styles, routing configurations, and shared dependencies of multiple sub-project modules into the main project module during the compilation phase. The business code is merged according to sub-package directories, the routing configurations are dynamically merged into the routing table of the main project module according to a predefined protocol format, and the global styles are merged according to modular namespaces. The plug-in fusion module can be implemented by building plugins, compilation scripts, or independent processes. During the development and debugging phase, it integrates sub-project modules into the main project module's startup and runtime environment as needed, and during the packaging phase, it packages the code integrated into the main project module together. This achieves automatic fusion of multi-framework code during the compilation phase, enabling modules developed by different frameworks and teams to run as a unified application while maintaining the relative independence and maintainability of each sub-project module.

[0008] The cross-platform compatibility layer is connected to the main project module and each of the sub-project modules. It encapsulates the differences in APIs across multiple platforms and provides a unified interface for each sub-project module to call. The cross-platform compatibility layer includes an API layer, an adapter layer, and an API implementation layer. The adapter layer routes the API layer's call requests to the corresponding API implementation layer through runtime environment checks. The API layer provides a unified API that business modules can directly call. The adapter layer detects the current runtime environment and selects the corresponding API instance based on the runtime environment, maintaining consistency in API method names across different runtime environments. The API implementation layer receives API call messages and executes the corresponding platform's API logic. This allows each sub-project module to call corresponding capabilities across different mini-program platforms, H5 environments, and APP environments without needing to worry about underlying platform differences, simply through the unified API, thereby improving code reusability and cross-platform compatibility.

[0009] The build and release module is connected to the output of the plug-in fusion module and is used to package the fused code into a multi-platform application. The multi-platform application includes at least one of WeChat Mini Program, Alipay Mini Program, Douyin Mini Program, H5 page, and native APP embedded module. It supports packaging and releasing the fused application separately according to the target platform, and also supports independent release of sub-project modules, meeting the release needs of multiple platforms and multiple scenarios.

[0010] A further technical solution of the present invention is: the plug-in fusion module is also configured with a change monitoring unit; the change monitoring unit is used to monitor the business code changes of the sub-project module and the configuration change events of the main project module in real time during the development and debugging phase; when a business code change in the sub-project is detected, incremental compilation is performed and the compilation result is automatically merged into the main project module to achieve incremental hot loading; when a configuration change in the main project is detected, all sub-project modules are recompiled. When merging multiple sub-project modules, the plug-in fusion module registers the routing configuration of each sub-project module into the routing table of the main project module according to a predefined protocol and format, and loads them as independent packages. This improves the efficiency of multi-project collaborative development during the development phase, reduces manual merging operations, ensures that changes to sub-projects are reflected in the main project's runtime environment in a timely manner, and avoids compilation omissions caused by configuration changes.

[0011] A further technical solution of the present invention is: the adapter layer of the cross-platform compatibility layer routes the call request to the corresponding runtime environment API through runtime environment checks. The runtime environment API includes browser API, APIs of various mini-program platforms, and JSSDK API that interacts with the native APP through JSBridge. The adapter layer identifies the operating environment, including H5 environment, mini-program environment, and APP environment; it calls the browser's native API in the H5 environment; it calls the corresponding mini-program platform's native API in the mini-program environment; and it uses WSF in the APP environment. The JSSDK and PostMessage protocol facilitate interaction with the native app via JSBridge. It uniformly encapsulates API differences across different runtime environments, enabling business code to be reused across H5, various mini-program platforms, and the native app, and allowing for the invocation of more complete native capabilities within the internal app.

[0012] A further technical solution of the present invention is that: each of the sub-project modules is organized in a monorepo pattern, and each sub-project module can be compiled and packaged independently, or it can be compiled and packaged as a whole with the main project module; the sub-project modules support component sharing, route jump interaction and standardized event message communication. Each sub-project module is configured with an independent namespace and a unique identifier. The routing configurations of each sub-project module are isolated using namespaces and unique identifiers to avoid routing conflicts. Event message communication between the sub-project modules adopts a unified standard message body format, and message transmission is completed in the form of event notifications. While maintaining the independence of sub-projects, unified management and reuse of components, dependencies, routes, and messages are achieved, reducing the cost of repetitive development.

[0013] A further technical solution of the present invention is: the H5 module packaged and generated by the building and publishing module can be embedded in an internal APP or a third-party APP through a unified JSSDK, and the native API can be called through JSBridge in the internal APP, and the browser API can be called in the third-party APP or independent H5 environment. The build and release module is also equipped with a code tree shaking unit; the code tree shaking unit is used to filter out business code that does not need to be executed on the current target platform according to the target platform configuration, thereby reducing the size of the packaged product. This enables the same H5 module to adapt to various scenarios such as independent access, internal APP embedding, and third-party APP embedding, and reduces the product size and improves loading performance by filtering code by platform.

[0014] Another objective of this invention is to provide a modular integration method for cross-platform, multi-framework convergence, wherein the modular integration method is used in the aforementioned modular integration system and includes the following steps: S1. The main project module starts and compiles one or more sub-project modules independently developed based on different front-end frameworks in parallel as needed. Each of the sub-project modules exists as an independent sub-package or independent module. This allows the main project to compile only the required sub-projects according to the current development or release requirements, reducing unnecessary compilation and improving build efficiency. S2. By calling the plug-in fusion module, the business code, global styles, routing configurations, and shared dependencies of the sub-project modules completed during the compilation phase are automatically merged into the main project module. The routing configurations are dynamically merged into the routing table of the main project module according to a predefined protocol format. This automatically completes the fusion of multiple sub-project codes into the main project, avoiding manual copying and modification, and ensuring that the fusion process is standardized and reliable. S3. During the compilation phase, the code of multiple frameworks is integrated through the parsing and transformation of the abstract syntax tree, and cross-platform compatible intermediate code is generated; it is compatible with the code forms of different frameworks such as Wepy, Taro, and native mini-programs, and converts them into target code that can run on the target platform. S4. Based on the target platform's environment variables, filter out code unrelated to the target platform using a tree-shaking mechanism, and package it into an application that can run independently or be embedded; generate adaptation artifacts for different target platforms such as WeChat Mini Programs, Alipay Mini Programs, Douyin Mini Programs, H5, and APP embedding, reduce irrelevant code, and improve running efficiency; S5. Depending on the release requirements, select whether to release the sub-project module independently or integrate it with the main project module for unified release; supports both independent module release and overall integrated release modes to solve the problem of full release required for function updates.

[0015] A further technical solution of the present invention is as follows: In step S2, the business code of the sub-project is merged into the main project according to the sub-package directory, the global styles are merged according to the modular namespace, and shared dependencies are merged into the same dependency. This ensures that each sub-project module maintains sub-package isolation, style isolation, and dependency reuse in the main project, avoiding conflicts and reducing the output size.

[0016] A further technical solution of the present invention is as follows: In step S3, the fusion of multi-framework code is achieved through the following methods: lexical and syntactic analysis of the source code is performed using babel-parser to generate an abstract syntax tree; the abstract syntax tree is modified and transformed using babel-types; and the transformed abstract syntax tree is generated into target code for the corresponding platform using babel-generate. This uses a unified compilation pipeline to process source code from different frameworks, achieving code conversion and cross-platform adaptation during the compilation phase.

[0017] A further technical solution of the present invention is: in step S4, the environment variables include a platform identifier and an environment identifier, and the cross-platform compatibility layer selects the code for the corresponding platform to be packaged based on the platform identifier and the environment identifier during packaging. This enables the same set of source code to automatically select the corresponding implementation according to the target platform and environment, improving the efficiency of multi-platform deployment.

[0018] A further technical solution of the present invention is as follows: In step S5, when the sub-project and the main project are integrated and released in a unified manner, the packaged mini-programs for each platform are directly released to their respective mini-program platforms, or released as online H5 pages through a continuous integration and continuous deployment pipeline for integration by internal or external apps. This streamlines the entire process from development, integration, packaging to release, supporting multiple delivery formats such as mini-programs and H5.

[0019] The beneficial effects of this invention are as follows: Independent module development, compared to the entire team developing under the same project, reduces the conflict merging rate by approximately 80%; multiple projects reduce the coupling of common modules such as routing and configuration, significantly improving team collaboration efficiency; in terms of architecture upgrades, the cycle has been reduced from 3-6 months requiring overall architecture reconstruction to a weekly iteration cycle that allows for incremental upgrades based on modules; this multi-framework integrated modular solution makes modular standards clearer, the modular integration process is executed by plugin scripts, and the merging process requires no manual operation, resulting in strong reliability and stability; enhanced cross-platform and cross-terminal support capabilities, supporting WeChat Mini Programs, Alipay Mini Programs, Douyin Mini Programs, independent H5 modules, and embedding within or outside apps; improved code reusability, reduced maintenance costs, and the ability to reuse over 80% of the business code in the project across different platforms and terminals, greatly improving development efficiency. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the overall architecture of the modular integrated system that integrates multiple frameworks across different platforms, as provided in this embodiment of the invention.

[0021] Figure 2 This is a schematic diagram of the compilation and fusion process of the main project and sub-projects provided in the embodiments of the present invention.

[0022] Figure 3 This is a schematic diagram of the cross-platform compatibility layer calling logic provided in an embodiment of the present invention.

[0023] Figure 4 This is a flowchart of a modular integration method for cross-platform and multi-framework fusion provided in an embodiment of the present invention. Detailed Implementation

[0024] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0025] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0026] like Figure 1 As shown, the modular integration system for cross-platform and multi-framework integration provided in this embodiment includes a main project module, several sub-project modules, a plug-in integration module, a cross-platform compatibility layer, and a build and release module. The system supports applications such as Douyin, Alipay, WeChat, and independent H5 platforms, and can output Douyin mini-programs, Alipay mini-programs, WeChat mini-programs, and H5 modules, which can be used by internal APP modules and third-party embedded applications. The plug-in integration layer can integrate sub-projects of different frameworks such as Wepy, Taro, and native projects, and achieves unified API calls through the cross-platform compatibility layer. The main project serves as the underlying foundation, providing the basic framework for application operation and a unified entry point.

[0027] The main project module provides the basic framework and entry point for application operation. It pre-registers the namespaces and identifiers for each sub-project module. Specifically, the main project module can be the core repository of a brand's mini-program, pre-configuring the namespaces for each sub-project. For example, the Wepy historical function module corresponds to the first namespace, the Taro marketing module to the second, the native service details and order placement module to the third, and the H5 fulfillment details module to the fourth. Each namespace has a unique identifier used to distinguish routes, components, styles, event messages, and dependencies. The main project module also maintains a global routing table, global configuration, common dependencies, and the application entry point. When the main project starts, sub-projects can be compiled in parallel as needed; only the main project can be compiled, or all required sub-projects can be compiled together. This provides a unified access foundation for each sub-project module, enabling multiple framework modules to run collaboratively within the same application.

[0028] Sub-project modules are developed independently based on different front-end frameworks. For example, the mini-program team uses the Wepy framework or the mini-program's native framework to develop historical function modules, and the Taro framework to develop new functional modules; the intelligent operations team uses the Taro framework to implement marketing and promotion function modules; and the APP team uses H5 to develop fulfillment details and order placement modules, which are applied to the APP and provide third-party integration. Each sub-project module has independent routing configuration and dependency management, and exists as an independent sub-package or independent module. Each sub-project module can be run and packaged individually or as a whole. Sub-project modules are combined into the main project using the monorepo pattern. Sub-project modules support component sharing, route navigation interaction, and event message communication. When components or dependencies are shared, the shared component becomes a shared dependency of the entire large project, and each sub-project can depend on it independently, but they will be merged into a single dependency during the actual packaging process. When routing navigation interaction occurs, the route registry and navigation of each project follow standardized protocols and formats, which can be directly merged or interacted through standardized protocols. When event message communication occurs, event and message communication follows a standard message body format, mainly communicating through notifications. Enables parallel development by multiple teams, independent releases, and on-demand integration, reducing code and release conflicts.

[0029] The plug-in fusion module connects with the main project module and each sub-project module, merging business code, global styles, routing configurations, and shared dependencies from multiple sub-project modules into the main project module during the compilation phase. Specifically, each project is integrated into the main project's runtime environment as needed during the debugging phase via the plug-in. The plug-in packages the code integrated into the main project during the packaging phase, with each project treated as an independent sub-package within the main project. During project fusion, after the main project starts, sub-projects are compiled in parallel as needed. After both the main project and sub-projects have been compiled, the plug-in script merges the sub-project code into the main project. Business code is merged according to sub-package directories; for example, different sub-projects are merged into their corresponding sub-package directories under the main project's artifact directory. Global styles are merged and can be isolated based on modular namespaces. Sub-project routes are merged into the main project, registered in the main project's routing table according to a predefined protocol format during merging. Shared dependencies are merged, and CSS styles are merged according to modular namespaces. Simultaneously, the main project and sub-projects initiate their own change notifications to incrementally update the compilation results when new code is saved. After development is complete, the code integrated into the main project's artifacts will be packaged together and finally submitted to various mini-program platforms, or published as an online H5 webpage via internal CI / CD for integration into internal or external apps. When the main project starts, multiple sub-project processes will be launched to monitor changes to the sub-project's business code. Simultaneously, the main project will monitor configuration changes to incrementally update the compiled code of the sub-projects when they change, automatically merging them into the main project; when the configuration changes, all projects will be recompiled. This automatically completes the compile-time merging of multi-framework code, reducing manual merging operations and improving merging reliability and development efficiency.

[0030] The plug-in fusion module is equipped with a change monitoring unit. During the development and debugging phase, this unit monitors for business code changes in sub-project modules and configuration changes in the main project module in real time. When a business code change in a sub-project is detected, incremental compilation is performed, and the compilation results are automatically merged into the main project module, achieving incremental hot reloading. When a configuration change in the main project is detected, all sub-project modules are recompiled. When merging multiple sub-project modules, the routing configuration of each sub-project module is registered in the main project module's routing table according to a predefined protocol and format, and loaded as an independent sub-package. For example, the sub-project routing configuration can use a configuration object containing fields such as namespace, module identifier, route path, page component path, sub-package, and applicable platform. After reading the routing configuration of each sub-project, the plug-in script verifies the uniqueness of the namespace and identifier, inserts it into the main project's global routing table, and adds the corresponding sub-package in the main project's sub-package configuration. This achieves incremental compilation and hot reloading during the development phase, avoiding a full compilation for every modification and improving development and debugging efficiency.

[0031] The cross-platform compatibility layer connects to the main project module and each sub-project module, encapsulating API differences across multiple platforms and providing a unified interface for each sub-project module to call. For example... Figure 2 As shown, the cross-platform compatibility layer includes an API layer, an adapter layer, and an API implementation layer. The API layer provides a unified API for direct calls from business modules; for example, the unified API can be denoted as wsf-api, and it supports multiple runtime environments and platforms. The adapter layer detects the current runtime environment and selects the corresponding API instance based on that environment, maintaining consistency in API method names across different runtime environments. The adapter layer routes API layer call requests to the corresponding API implementation layer through runtime environment checks. Runtime environment checks can be distinguished using environment variables injected during initialization and the User Agent (UA). In an H5 environment, the request is routed to the browser API; in a mini-program environment, it is routed to the corresponding mini-program API; and in an APP environment, it is routed to WSF-JSSDK. The API implementation layer receives API call messages and executes the corresponding platform's API logic, such as WeChat mini-program API, Alipay mini-program API, Douyin mini-program API, iOS / Android API, etc. In an APP environment, WSF-JSSDK can use JSBridge to enable interaction between H5 and native modules, while also including the business capabilities provided by the APP, and communicates with the API implementation layer via the postmessage protocol. This eliminates the need for business modules to write differentiated calling code for each platform, reducing cross-platform adaptation costs and improving code reusability.

[0032] Specifically, the cross-platform compatibility layer integrates the API of the JSSDK, extending the compatibility capabilities of various frameworks across different platforms and systems, and implementing some internal functionalities. This API distinguishes different platforms and environments through environment variables and user agents injected during initialization; simultaneously, the compatibility layer selects the appropriate platform code to package based on different environment variables during packaging. It packages into mini-programs for different platforms as needed, such as WeChat, Alipay, and Douyin mini-programs, which can be directly published to each mini-program platform. When packaged as H5, it can be accessed independently or integrated into internal apps or third-party apps using the provided JSSDK. When the H5 module runs on different systems, the JSSDK's support level varies, and it will execute the corresponding environment's API. For example, as an independent H5 module or running in a third-party app for scanning and positioning, it will directly call the browser API; however, within the internal app, the JSSDK will interact with the app via JSBridge to call the app's APIs, supporting more comprehensive and powerful capabilities. The interaction between the app and the JSSDK is encapsulated in a standard WebView, which is used by all internal apps. Different subsystems can be distinguished by different platforms, with corresponding routes and packaging modules configured. Unnecessary functional code for the current platform will be filtered through platform configuration filtering and a tree-shaking mechanism during the packaging process. This enables a single codebase to run adaptively across multiple platforms and environments, while also supporting independent H5 pages, third-party embeddings, and native calls to internal APP capabilities.

[0033] The build and release module connects to the output of the plug-in fusion module, packaging the fused code into multi-platform applications. These applications include at least one of the following: WeChat Mini Programs, Alipay Mini Programs, Douyin Mini Programs, H5 pages, and native app embedded modules. The build and release module can be configured with various build scripts, such as build commands for WeChat Mini Programs, Alipay Mini Programs, Douyin Mini Programs, H5 pages, React Native, QQ Mini Programs, JD.com Mini Programs, and Quick Apps. In development mode, corresponding watch build commands can be executed to implement watch compilation. Test scripts can be executed during testing, and lint scripts can be executed during code inspection. After project merging, the main project and sub-projects can be compiled and packaged together using scripts. The build and release module also includes a code tree shaking unit. This unit filters out unnecessary business code for the target platform based on the target platform configuration, reducing the size of the packaged output. For example, when the target platform is a WeChat mini-program, it filters out code specific to Alipay mini-programs, code specific to Douyin mini-programs, and some code specific to H5; when the target platform is H5, it filters out mini-program-specific components and API implementations. This enables refined packaging and publishing by platform, environment, and functional module, reducing package size and improving loading and runtime efficiency.

[0034] The H5 modules generated by the build and release module can be embedded into internal or third-party apps using a unified JSSDK. Within the internal app, native APIs are called via JSBridge; in third-party apps or independent H5 environments, browser APIs are called. This allows the same H5 module to be accessed as a standalone webpage, embedded within an internal app, or embedded in a third-party app. Its function is to improve the reusability and integration flexibility of H5 modules, and reduce the cost of repetitive development across multiple platforms.

[0035] like Figure 4 As shown, this embodiment also provides a modular integration method for cross-platform, multi-framework integration, which is used in the aforementioned modular integration system. The method includes the following steps: Step S1: The main project module starts, compiling one or more sub-project modules independently developed based on different front-end frameworks in parallel as needed. Each sub-project module exists as an independent sub-package or independent module. For example, when the main project starts, it can be selected to compile only the main project, or simultaneously compile one or more of the following sub-projects: Wepy historical features, Taro marketing, and native service details. Compiling on demand reduces build time and improves the efficiency of parallel development by multiple teams.

[0036] Step S2 involves merging the business code, global styles, routing configurations, and shared dependencies of the sub-project modules completed during the compilation phase into the main project module by calling the plug-in fusion module. The routing configurations are dynamically merged into the main project module's routing table according to a predefined protocol format. Specifically, business code is merged according to sub-package directories, global styles are merged according to modular namespaces, and shared dependencies are merged into a single dependency. For example, the business code of the Wepy sub-project is merged into the first sub-package directory of the main project, the business code of the Taro sub-project is merged into the second sub-package directory, and the business code of the native sub-project is merged into the third sub-package directory. The routing configurations are written into the main project's routing table according to a protocol format that includes fields such as namespace, unique identifier, path, component, and platform. This achieves automatic and standardized fusion of multiple sub-projects within the main project, avoiding routing and style conflicts.

[0037] Step S3 involves fusing multi-framework code through abstract syntax tree (AST) parsing and transformation during the compilation phase, generating cross-platform compatible intermediate code. Specifically, babel-parser performs lexical and syntactic analysis on the source code to generate an AST; babel-types modifies and transforms the AST; and babel-generate generates the target code for the corresponding platform from the transformed AST. The compilation during the project fusion phase does not package the project; packaging is only performed after development is complete, involving compression and unpacking of the entire output. This unified compilation pipeline ensures compatibility with different front-end framework source codes, generating cross-platform compatible intermediate code and laying the foundation for subsequent platform-specific packaging.

[0038] Step S4 involves filtering out code unrelated to the target platform using a tree-shaking mechanism based on the target platform's environment variables, and packaging the application into a standalone or embedded application. Environment variables include platform identifiers and environment identifiers. The cross-platform compatibility layer selects the appropriate platform code to package based on these identifiers during packaging. For example, the platform identifier can represent WeChat, Alipay, Douyin, H5, APP, etc., while the environment identifier can represent development, testing, production, etc. The tree-shaking mechanism can delete business logic code, component code, and API implementation code that are not needed for the current target platform based on platform configuration and reference relationships. This generates artifacts adapted to different target platforms, reducing artifact size and improving runtime performance.

[0039] Step S5: Based on the release requirements, choose to release the sub-project module independently or integrate it with the main project module for unified release. When releasing the sub-project integrated with the main project, the packaged mini-programs for each platform are directly released to their respective mini-program platforms, or released as online H5 pages through a continuous integration and continuous deployment pipeline for integration by internal or external apps. For example, WeChat mini-programs are released to the WeChat platform, Alipay mini-programs to the Alipay platform, and Douyin mini-programs to the Douyin platform; H5 pages can be released to the online server via CICD for integration by internal apps through a unified Webview and JSSDK, or for integration by third-party apps through the JSSDK. Supporting both independent and integrated release modes solves the problem of requiring a full release for feature updates, improving release flexibility and iteration efficiency.

[0040] In practical project implementation, when the main project starts, multiple sub-project processes can be launched to monitor changes to the sub-project's business code, while the main project simultaneously monitors for configuration changes. When a sub-project changes, its compiled code is incrementally updated and automatically merged into the main project; when the configuration changes, all projects are recompiled. After both the main project and sub-projects have been compiled, the plugin script merges the sub-project code into the main project, including business code, global styles, sub-project routes, and shared dependencies. After merging, both the main project and sub-projects initiate their respective change notifications to incrementally update the compilation results when new code is saved. After development is complete, the code integrated into the main project's artifact directory is packaged together and finally submitted to various mini-program platforms or published as an online H5 webpage via internal CICD. This forms a complete closed loop from independent development, real-time monitoring, incremental compilation, automatic integration, to multi-platform deployment.

[0041] In this embodiment, the specific working process of the cross-platform compatibility layer is as follows: the business module calls the unified API provided by the API layer; the adapter layer performs a runtime environment check; if the current environment is H5, the browser API is called; if the current environment is a mini-program, the corresponding mini-program API is called, such as WeChat mini-program API, Alipay mini-program API, and Douyin mini-program API; if the current environment is an APP, the iOS / Android native API is called via JSBridge through WSF-JSSDK and the postmessage protocol. The adapter layer keeps the method names consistent across all environments, so that the upper-layer business code does not need to be modified. This shields the differences between multi-platform APIs, enabling one-time development and multi-platform operation.

[0042] In this embodiment, the sub-project sharing and interaction logic is as follows: Different sub-projects are combined into a main project using the monorepo pattern. These sub-projects can be run and packaged individually or as a whole. Inter-project interactions mainly include component sharing, route navigation, and event message communication. Shared components serve as shared dependencies for the entire main project; each sub-project can depend on them independently, but they will be merged into a single dependency during the actual packaging process. Route registry entries and navigation in each project follow standardized protocols and formats, allowing for direct merging or interaction via standardized protocols. Event and message communication follows standard message body formats, primarily communicating through notifications. This approach maintains the independence of sub-projects while enabling cross-project resource reuse and communication.

[0043] In this embodiment, the specific process of project integration and compilation packaging is as follows: When the main project starts, sub-projects are compiled in parallel as needed. This can be done by compiling only the main project or compiling all sub-projects that need development together. After both the main project and sub-projects are compiled, the plugin script merges the sub-project code into the main project. Business code is merged according to the sub-package directory, global styles are merged, sub-project routes are merged into the main project, shared dependencies are merged, and CSS styles are merged according to the modular namespace. Simultaneously, the main project and sub-projects initiate their respective change notifications to incrementally update the compilation results when new code is saved. After development is complete, the code integrated into the main project's artifact directory is packaged together and finally submitted to various mini-program platforms, or published as an online H5 webpage via internal CICD for integration into internal or external apps. When the main project starts, multiple sub-project processes are started to monitor changes in the sub-project's business code, while the main project monitors for configuration changes. This allows for incremental updates to the sub-project's compiled code when a sub-project changes, automatically merging it into the main project. When the configuration changes, all projects are recompiled. This achieves automated integration and multi-platform deployment of multiple framework modules.

[0044] In this embodiment, the compilation phase can be performed as follows: lexical and syntactic analysis is conducted using babel-parser to parse the source code into an abstract syntax tree (AST); babel-types is used to perform a series of modifications, transformations, and operations on the AST; babel-generate is used to generate the target code for the corresponding platform from the transformed AST. The compilation during the project integration phase does not involve project packaging; packaging is only performed after development is complete by compressing and unpacking the entire output. This achieves unified conversion of source code from different frameworks and cross-platform code generation.

[0045] In this embodiment, the cross-platform compatibility layer can be as follows: Figure 2The architecture is divided into three layers: the API layer, the API adapter, and the API implementation layer. The API layer contains the APIs directly called by the actual business modules and supports multiple runtime environments and platforms. The adapter layer's main function is to call APIs from different platforms and environments through different object instances, maintaining consistency in method names across instances. It triggers API communication between various environments through browser objects, mini-program objects, and the WSF-JSSDK. The WSF-JSSDK internally uses JS-Bridge to implement interaction between H5 and native modules, and also includes business capabilities provided by the app. The API implementation layer's main function is to receive API call messages from different environments and complete the implementation. This layered architecture achieves unified APIs, environment adaptation, and platform implementation decoupling.

[0046] In this embodiment, the merged output and monitoring logs after the main project starts can be as follows: Figure 3 As shown, incremental updates are achieved by monitoring changes to sub-project files, triggering successful compilation, and merging the results into the main project. After project merging, the compilation and packaging scripts include build and dev commands for multiple platforms, such as `build:weapp`, `build:swan`, `build:alipay`, `build:tt`, `build:h5`, `build:rn`, `build:qq`, `build:jd`, and `build:quickapp`, as well as their corresponding `dev:weapp`, `dev:swan`, `dev:alipay`, `dev:tt`, `dev:h5`, `dev:rn`, `dev:qq`, `dev:jd`, and `dev:quickapp`. This scripted approach enables multi-platform compilation, debugging, and packaging, improving the level of engineering and automation.

[0047] This invention utilizes techniques such as main project scheduling, plug-in fusion, cross-platform compatibility layers, and build / release modules to dynamically aggregate sub-project modules based on different frameworks during the compilation phase, generating applications that support multi-platform operation. Compared to existing technologies, this invention supports parallel execution of different frameworks such as Wepy, Taro, and native WeChat Mini Programs; supports independent development and release of different frameworks and modules; supports dynamic aggregation and release for different scenarios; supports building a fusion architecture of a centralized main project and multiple sub-projects; supports compile-time fusion and runtime scheduling of multi-framework code through a plug-in mechanism; and supports unified encapsulation of multi-platform API differences through a cross-platform compatibility layer. This invention is fully disclosed, and those skilled in the art can implement this modular integration system and method for cross-platform, cross-platform, and multi-framework fusion based on the above description.

[0048] Example 1 This embodiment provides a modular integration system that integrates multiple frameworks across different platforms and is applied to the front-end engineering project of a certain brand's business. The project's business scenario is as follows: the mini-program team maintains the existing Wepy business modules, the intelligent operation team develops the marketing and promotion module using the Taro framework, and the APP team develops the fulfillment details and order placement business modules using the mini-program's native framework. The business needs to output WeChat mini-programs, Alipay mini-programs, Douyin mini-programs, and H5 modules simultaneously. The H5 module needs to support embedding within the brand's internal APP as well as embedding in third-party customer APPs.

[0049] like Figure 1 As shown, the modular integration system includes a main project module, a sub-project module, a plug-in fusion module, a cross-platform compatibility layer, and a build and release module.

[0050] The main project module serves as the project foundation, and three sub-project namespaces are pre-registered: wepy history (Wepy history business sub-project), taro marketing (Taro marketing sub-project), native order (native order fulfillment sub-project); each sub-project is assigned a unique identifier; the main project maintains the global entry file, global configuration file, and overall routing table.

[0051] There are a total of 3 sub-project modules: 1)wepy The history sub-project: Develops historical business pages based on the discontinued Wepy framework, with independent route configuration and npm dependencies; 2) taro The marketing sub-project: Develops a marketing and promotion module based on the Taro framework; 3) native The `order` sub-project uses native WeChat Mini Program syntax to write fulfillment details and order placement pages. The three sub-projects are organized in a unified manner using the monorepo pattern; each sub-project can be executed, compiled, packaged, and output independent artifacts independently; the sub-projects share a common business component package, which is a common dependency and is merged into a single copy during the packaging stage; page navigation between sub-projects follows a unified routing protocol; and business message interaction uses standardized message body event notifications.

[0052] The plug-in fusion module connects the main project with all sub-projects and has a built-in change monitoring unit. During the development and debugging phase, the main project starts and compiles the three sub-projects in parallel as needed according to the configuration. During compilation, the plug-in fusion module collects the compilation artifacts of the sub-projects: business code is copied to the main project's sub-package directory; the routing configurations of each sub-project are merged into the main project's global routes after adding a namespace prefix; namespace selectors are added to the global CSS styles to achieve style isolation; and third-party dependencies shared by multiple sub-projects are deduplicated and merged.

[0053] Change the continuous listening file of the listening unit: when wepy If the code of the business page in the history sub-project is modified, only that sub-project will be incrementally compiled, and the compiled artifacts will be automatically merged into the main project, enabling hot updates of the developer page. If the global platform configuration file of the main project is modified, all three sub-projects will be recompiled completely. After the sub-projects are merged, they are all treated as independent packages of the mini-program, complying with the mini-program's package loading rules.

[0054] The cross-platform compatibility layer is divided into an API layer, an adapter layer, and an API implementation layer. All business code within the business sub-project calls the API layer and exposes a unified WSF externally. For API interfaces, business logic code does not need to determine the current running platform. The adapter layer reads the User Agent (UA) and injects environment variables to identify the running environment (H5 / Mini Program / APP). If a WeChat Mini Program environment is detected, the route will call the WeChat Mini Program API. If it's an Alipay mini-program, the route calls the Alipay mini-program API; If it is a Douyin mini-program, the route calls the Douyin mini-program API; If it runs in a standalone H5 page or within a WebView of a third-party app, then the browser's native API is called; If the H5 module runs within a WebView of a brand's internal app, the adapter calls WSF. The JSSDK communicates bidirectionally with the native app via the JSBridge postmessage protocol, enabling the app to access its native capabilities.

[0055] The build and release module receives the fusion output from the plug-in fusion module and has a built-in code tree shaking unit. When packaging, the platform environment variables are passed in, and the code tree shaking unit removes business code and API implementation code that are not relevant to the current platform, thereby reducing the package size.

[0056] When the environment variable is set to WeChat Mini Program, the output will be the WeChat Mini Program project package; when the environment variable is set to Alipay Mini Program, the output will be the Alipay Mini Program package; when the environment variable is set to Douyin Mini Program, the output will be the Douyin Mini Program package; when the environment variable is set to H5 platform, the output will be the H5 static resource package.

[0057] H5 static resource packages can be deployed and accessed independently, or they can be loaded via WebView by a brand's internal app or a third-party app, along with WSF. The JSSDK enables interaction between H5 and native apps; internal app scenarios use JSBridge to call native capabilities; third-party apps and independent H5 scenarios call browser APIs.

[0058] Example 2 This embodiment provides a modular integration method for cross-terminal, cross-platform, and multi-framework fusion, using the modular integration system in Embodiment 1, and includes the following steps.

[0059] Step S1: Start the main project module, read the configuration file, and mark that wepy needs to be enabled for this debugging session. history, taro marketing, native The main project starts the compilation process of the three sub-projects in parallel, compiling Wepy, Taro, and the native sub-project of the mini-program respectively; the compilation processes of the sub-projects are independent of each other; in this embodiment, the three sub-projects are all treated as independent sub-packages.

[0060] In step S2, the plug-in fusion module collects the compiled artifacts of the three sub-projects, copies the business code into the main project according to the sub-package directory, adds a namespace prefix to the routing configuration of each sub-project, and merges it into the global routing table of the main project; adds a namespace selector to the global CSS style; and performs deduplication and merging on the shared dependency packages of each sub-project.

[0061] Step S3: During compilation, perform AST (Abstract Syntax Tree) transformation on the source code of each sub-project using Babel. Parser parses source code to generate an abstract syntax tree; Babel Types performs rewriting transformations on abstract syntax tree nodes, smoothing out the syntax differences between Wepy, Taro, and native mini-programs; Babel The generate stage outputs intermediate target code adapted to the target platform; this stage only performs source code fusion and conversion, and does not perform final packaging operations such as compression and unpacking.

[0062] Step S4: Set environment variables, with the target platform being WeChat Mini Program; build and publish module code tree units based on the WeChat Mini Program platform identifier, filtering out Alipay Mini Program, Douyin Mini Program, H5 irrelevant business code, and irrelevant API implementation code; the cross-platform compatibility layer only retains the API implementation logic corresponding to WeChat Mini Program; package, compress, and unpack to generate a WeChat Mini Program project package.

[0063] S5, during the release phase, there are two options: Option 1, Taro The marketing module needs an urgent iteration, specifically for Taro. Option 1: The marketing sub-project can be packaged and released independently, without needing to release the main project and the other two sub-projects. Option 2: All business modules need to be updated as a whole, and all sub-projects are merged with the main project and then packaged together. WeChat Mini Program artifacts are directly uploaded and submitted to the WeChat Mini Program platform. If the environment variable is set to H5, H5 static resources are packaged and output, and deployed to a static server via the CICD pipeline for independent access or integration into the APP.

[0064] Example 3 This embodiment is a local debugging scenario, using the system of Embodiment 1.

[0065] Business developers only need to debug Taro The marketing module does not require debugging of historical Wepy sub-projects or native order placement projects.

[0066] Step S1: Start the main project, and configure the configuration file to only enable Taro. The marketing sub-project only starts the compilation process of the main project and the Taro marketing sub-project, while the other two sub-projects do not start compilation, thus saving computing power on the development computer.

[0067] Step S2 S3, the plug-in fusion module only merges Taro The marketing sub-project artifacts are transferred to the main project, the AST source code is converted, and the fusion and debugging artifacts are generated.

[0068] The developer modified the Taro marketing module page code, changing the listener unit to capture the code changes; this only applies to Taro. The marketing sub-project is compiled incrementally, the artifacts are automatically merged, and the pages are hot-loaded and updated, without the need to compile the other two sub-projects.

[0069] When a developer modifies the platform configuration of the main project, it triggers a recompilation of all sub-projects.

[0070] Those skilled in the art should understand that the present invention is not limited to the specific embodiments described above. Various modifications and transformations can be made without departing from the core concept of the present invention. For example, the number of sub-projects can be increased or decreased to support more front-end frameworks; more mini-program platforms can be supported; and environment variables can be added to differentiate between test environments and production environments. The above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A modular integrated system that integrates multiple frameworks across different platforms and terminals, characterized in that, The modular integration system includes a main project module, several sub-project modules, a plug-in fusion module, a cross-platform compatibility layer, and a build and release module. The main project module is used to provide the basic framework for application operation and a unified entry point. The main project module has pre-registered the namespaces and identifiers of each sub-project module. The aforementioned sub-project modules are developed independently based on different front-end frameworks. Each sub-project module has independent routing configuration and dependency management, and exists as an independent sub-package or independent module. The front-end frameworks include the Wepy framework, the Taro framework, and the native WeChat Mini Program framework. The plug-in fusion module is connected to the main project module and each of the sub-project modules. It is used to merge the business code, global styles, routing configurations and common dependencies of multiple sub-project modules into the main project module during the compilation stage. The business code is merged according to the sub-package directory, the routing configuration is dynamically merged into the routing table of the main project module according to the predefined protocol format, and the global styles are merged according to the modular namespace. The cross-platform compatibility layer is connected to the main project module and each of the sub-project modules respectively. It is used to encapsulate the differences of APIs across multiple platforms and provide a unified interface for each of the sub-project modules to call. The cross-platform compatibility layer includes an API layer, an adapter layer and an API implementation layer. The adapter layer routes the call requests of the API layer to the corresponding API implementation layer through runtime environment checks. The API layer is used to provide a unified API that can be directly called by business modules; the adapter layer is used to detect the current running environment, select the corresponding API instance according to the running environment, and keep the API method names consistent in different running environments; the API implementation layer is used to receive API call messages and complete the API logic execution of the corresponding platform. The build and release module is connected to the output end of the plug-in fusion module and is used to package the fused code into a multi-terminal application. The multi-terminal application includes at least one of WeChat mini-program, Alipay mini-program, Douyin mini-program, H5 page and native APP embedded module.

2. The modular integrated system according to claim 1, characterized in that, The plug-in fusion module is also configured with a change monitoring unit; the change monitoring unit is used to monitor the business code changes of the sub-project modules and the configuration change events of the main project module in real time during the development and debugging phase. When a business code change in the sub-project is detected, incremental compilation is performed and the compilation result is automatically merged into the main project module to achieve incremental hot loading; when a configuration change in the main project is detected, all sub-project modules are recompiled. When merging the multiple sub-project modules, the routing configuration of each sub-project module is registered in the routing table of the main project module according to a predefined protocol and format, and loaded in an independent package manner.

3. The modular integrated system according to claim 1, characterized in that, The adapter layer of the cross-platform compatibility layer routes the call request to the corresponding runtime environment API through runtime environment checks. The runtime environment API includes browser API, APIs of various mini-program platforms, and JSSDK API that interacts with the native APP through JSBridge. The adapter layer identifies the operating environment, including H5 environment, mini-program environment, and APP environment; it calls the browser's native API in the H5 environment; it calls the corresponding mini-program platform's native API in the mini-program environment; and it uses WSF in the APP environment. The JSSDK and postmessage protocol enable interaction with native apps via JSBridge.

4. The modular integrated system according to claim 1, characterized in that, Each sub-project module is organized in the monorepo pattern. Each sub-project module can be compiled and packaged independently, or it can be compiled and packaged as a whole with the main project module. The sub-project modules support component sharing, route jump interaction, and standardized event message communication. Each of the sub-project modules is configured with an independent namespace and a unique identifier. The routing configurations of each sub-project module are isolated through the namespace and the unique identifier to avoid routing conflicts. Event message communication between the sub-project modules adopts a unified standard message body format and completes message transmission in the form of event notification.

5. The modular integrated system according to claim 1, characterized in that, The H5 module generated by the build and release module can be embedded in an internal APP or a third-party APP through a unified JSSDK. In the internal APP, it calls the native API through JSBridge, and in the third-party APP or independent H5 environment, it calls the browser API. The build and release module is also configured with a code tree shaking unit; the code tree shaking unit is used to filter out business code that does not need to be executed on the current target platform according to the target platform configuration, thereby reducing the size of the packaged product.

6. A modular integration method for cross-platform, multi-framework fusion, characterized in that, The modular integration method is used in the modular integration system according to claims 1-5, and includes the following steps: S1. The main project module starts and compiles one or more sub-project modules independently developed based on different front-end frameworks in parallel as needed. Each of the sub-project modules exists as an independent sub-package or independent module. S2. By calling the plug-in fusion module, the business code, global style, routing configuration and shared dependent resources of the sub-project module completed in the compilation stage are merged into the main project module, wherein the routing configuration is dynamically merged into the routing table of the main project module according to a predefined protocol format; S3. During the compilation phase, the integration of multi-framework code is achieved through abstract syntax tree parsing and transformation, and cross-platform compatible intermediate code is generated. S4. Based on the environment variables of the target platform, filter out code that is not related to the target platform through a tree-shaking mechanism, and package it to generate an application that can run independently or be embedded. S5. Depending on the release requirements, select to release the sub-project module independently or integrate it with the main project module for unified release.

7. The modular integration method according to claim 6, characterized in that, In step S2, the business code of the sub-project is merged into the main project according to the sub-package directory, the global style is merged according to the modular namespace, and the shared dependencies are merged into the same dependency.

8. The modular integration method according to claim 6, characterized in that, In step S3, the fusion of multi-framework code is achieved in the following way: lexical and syntactic analysis of the source code is performed by babel-parser to generate an abstract syntax tree; the abstract syntax tree is modified and transformed by babel-types; and the transformed abstract syntax tree is generated into target code for the corresponding platform by babel-generate.

9. The modular integration method according to claim 7, characterized in that, In step S4, the environment variables include platform identifier and environment identifier. When packaging, the cross-platform compatibility layer selects the code for the corresponding platform based on the platform identifier and the environment identifier.

10. The modular integration method according to claim 8, characterized in that, In step S5, when the sub-project and the main project are integrated and released in a unified manner, the packaged mini-programs generated for each platform are directly released to the corresponding mini-program platforms, or released as online H5 pages through the continuous integration and continuous deployment pipeline for internal or external APP integration.

Images