A front-end multi-module development method and system based on module federation

Abstract

The application discloses a front-end multi-module development method and system based on module federation. The method comprises the following steps: extracting necessary instances, public components and public methods in a front-end project to a public basic module, and constructing the public basic module as a module federation product; decoupling other functional modules, configuring module coding and module federation construction entry in a construction configuration file; centrally managing a remote module list and configuration information through a project configuration module; executing a construction command to call a project construction module to independently package each module and update the project configuration module; when an application is started, a project loading module loads the public basic module and a remote functional module according to the project configuration module. Compared with the existing Module Federation scheme with application granularity, the application realizes independent construction, configuration management and runtime flexible loading at the module level, avoids dependence on repeated and redundant logic, supports module plug-and-play and version switching, and thus improves development efficiency, construction performance and expandability.

Description

Technical Field

[0001] This invention relates to software development, and more specifically to a front-end multi-module development method and system based on module federation. Background Technology

[0002] As front-end projects grow in scale, monolithic applications are increasingly revealing problems such as low build efficiency, redundant dependencies, and severe module coupling. To address this, the industry commonly adopts micro-frontend architectures or npm packages to improve development efficiency and module reusability. Micro-frontend architectures typically break down the front-end system into multiple sub-applications at the application level, integrating and scheduling them through a main application. While this approach allows for independent development and deployment of sub-applications, it often requires maintaining multiple sets of application logic, leading to resource redundancy, dependency conflicts, and difficulties in version management at the module level. Building npm packages focuses on encapsulating some functionalities as dependencies for cross-project sharing. However, this approach is only suitable for a small number of independent components and struggles to cover large-scale business logic. Furthermore, updates to npm packages require rebuilding the dependent projects, preventing immediate changes.

[0003] Meanwhile, existing Module Federation-based solutions are application-level, meaning different sub-applications are built as federated artifacts and then remotely loaded by the main application, such as the publicly available solutions CN117806623A and CN119127259A. Although they adopt the Module Federation architecture, this model still perpetuates the complexity of application-level splitting and cannot solve the needs for flexible loading and version control at the module level. From a developer's perspective, application-level micro-frontend solutions require maintaining multiple projects simultaneously, which is more mentally taxing than maintaining a single project.

[0004] Therefore, how to achieve independent building, configuration management, and flexible runtime loading at the module level within a single project in front-end development, thereby ensuring shared public dependencies while reducing development complexity, avoiding redundant building, and supporting plug-and-play and version switching of modules, is a valuable technical problem. Summary of the Invention

[0005] This disclosure provides a front-end multi-module development method and system based on module federation.

[0006] Firstly, this disclosure provides a front-end multi-module development method based on module federation, including:

[0007] The necessary instances, common components, and common methods in the front-end project are extracted into a common basic module. The necessary instances, common components, and common methods are exposed through module federation configuration, and the common basic module is constructed as a module federation artifact.

[0008] Decouple other functional modules, modify the references of each functional module to consume the common basic module, and generate an entry file for each functional module.

[0009] Configure a unique code and module federation build entry point for each functional module in the build configuration file, and use the shared dependency mechanism to avoid repeatedly loading public dependencies;

[0010] Include the project loading module in the project's HTML entry file, and add a project configuration file as the project configuration module in the project root directory. The project configuration module includes a list of remote modules and the loading order and configuration information of each remote module.

[0011] Execute the build command, call the project build module to independently package the common basic module and each functional module, generate independent build artifacts, and update the project configuration module according to the module list of this build;

[0012] Based on the project configuration module, the entire build artifact or a single module artifact is deployed.

[0013] Optionally, the step of executing the build command, calling the project build module to independently package the common basic module and each functional module to generate independent build artifacts, and updating the project configuration module according to the module list of this build, further includes:

[0014] The command parameters determine whether to execute in development mode, build mode, or preview mode.

[0015] Read the build configuration file in the project directory and merge it with the internal build configuration to generate a complete build configuration;

[0016] Parse the command parameters to determine the list of modules to be built, and generate the corresponding array of build configuration objects;

[0017] Set an independent output path for each build configuration object, configure the module federated build plugin, set the default consumed public base module, and configure shared dependencies and public items;

[0018] Generate a build configuration without an entry file to copy static resource files, and write the module information for this build to the remote module list of the project configuration module;

[0019] The build tool is invoked to execute the array of build configuration objects, obtain multiple build instances, and update the project configuration module.

[0020] Optionally, after deployment is complete, the project's loading process may also include:

[0021] After the application page has finished loading, the project loading module is triggered to call the preset initialization method;

[0022] The initialization method obtains and parses the project configuration file, and registers the parsing result globally;

[0023] A module federation runtime instance is created based on the project configuration file, and a list of remote modules is registered in this instance;

[0024] The runtime instance loads the common infrastructure module and executes the module loading and application startup process exposed by the common infrastructure module.

[0025] Optionally, when the execution of the build command is in development mode, it further includes:

[0026] Generate the build artifacts of each functional module in memory;

[0027] Access requests for the constructed artifacts are proxied through a local service proxy;

[0028] The system monitors changes to the module's source code based on a hot update middleware and rebuilds only the affected module when a change is detected.

[0029] Inject the updated module content into the running instance without reloading the entire application.

[0030] Optionally, remote modules can be added, replaced, or deleted without rebuilding by modifying the list of remote modules in the project configuration module, and the changes will take effect immediately after the page is refreshed.

[0031] Optionally, the project configuration module supports specifying a target version number for a remote module and obtaining the corresponding build artifact based on the version number when loading the remote module.

[0032] Optionally, the project loading module supports switching the target version of the remote module at runtime and reloading the remote module without rebuilding.

[0033] Secondly, this disclosure provides a front-end multi-module development system based on module federation, including:

[0034] The project build module is used to read the build configuration file and merge it with the internal build configuration. Based on the merged build configuration, it independently packages the common basic modules and each functional module, outputs the build artifacts to the corresponding directory, and updates the project configuration module according to the list of modules built this time.

[0035] The project configuration module is used to store project parameters, a list of remote modules, and the loading order and configuration information of each remote module, and is updated during the build or deployment process;

[0036] The project loading module is used to read the contents of the project configuration module when the application starts, create a module federation runtime instance and register the list of remote modules, load the public base module and execute the module loading and application startup process exposed by the public base module.

[0037] Thirdly, this disclosure provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0038] The memory stores the instructions that the computer executes;

[0039] The processor executes computer-executable instructions stored in memory to implement the methods of this disclosure.

[0040] Fourthly, this disclosure provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods of this disclosure.

[0041] The beneficial effects of this disclosure are that, compared with the prior art, this disclosure has the following advantages:

[0042] 1) Unlike existing micro-frontend frameworks, this application does not require splitting the project into multiple sub-applications. Instead, it allows for the development and building of local modules and the loading of remote modules directly within a single project. By leveraging the shared dependency mechanism of module federation, it avoids repeated dependency loading and redundant code, reduces operational complexity, and improves frontend loading performance and user experience.

[0043] 2) This application eliminates the complex npm package building and publishing process. Remote modules are loaded and updated instantly via HTTP, and developers only need to upload the new version for it to take effect immediately. The project configuration module centrally manages remote module information, supports adding, deleting, modifying, and switching versions of modules without rebuilding, achieving plug-and-play functionality and flexible iteration.

[0044] 3) Regarding application building and deployment, the method and system proposed in this application abandon the traditional project entry file and adopt a project loading module as a universal project entry point. Only an HTML file and a project configuration module are needed. By importing the project loading module and configuring the remote module list, application deployment can be completed without a build process.

[0045] 4) This application innovatively introduces Module Federation to the module level, enabling the independent construction and management of functional modules within a single project. This avoids repetitive logic and complex integration at the sub-application level, and reduces the difficulty of understanding and maintaining the system. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0047] Figure 1 A schematic diagram illustrating a front-end multi-module development method based on module federation, provided for embodiments of this disclosure;

[0048] Figure 2 This is a schematic diagram of a front-end multi-module development, execution, and build process provided in an embodiment of the present disclosure;

[0049] Figure 3 This is a schematic diagram of a front-end multi-module development, execution, and loading process provided in an embodiment of the present disclosure;

[0050] Figure 4 A schematic diagram of a front-end multi-module development system based on module federation is provided for embodiments of this disclosure;

[0051] Figure 5 A schematic diagram of the construction product of a front-end multi-module development method provided in an embodiment of this disclosure;

[0052] Figure 6 This is a functional block diagram of a multi-module development system provided in an embodiment of the present disclosure;

[0053] Figure 7 This is a schematic diagram illustrating the development and deployment of a multi-module front-end system, as provided in an embodiment of this disclosure.

[0054] The accompanying drawings have illustrated specific embodiments of this disclosure, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this disclosure to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0055] The present disclosure will be further described below with reference to the accompanying drawings. The following embodiments are only used to illustrate the technical solutions of the present disclosure more clearly, and should not be used to limit the scope of protection of the present disclosure.

[0056] Figure 1 This diagram illustrates a front-end multi-module development method based on module federation, as provided in an embodiment of this disclosure. See also... Figure 1 The following is a detailed discussion of each step in conjunction with this embodiment.

[0057] S100. Extract the necessary instances, public components, and public methods from the front-end project to a public basic module, expose the necessary instances, public components, and public methods through module federation configuration, and construct the public basic module as a module federation artifact.

[0058] In this embodiment, in order to achieve decoupling and sharing of the front-end multi-module system, it is first necessary to extract the necessary instances, common components and common methods in the front-end project to the common basic module.

[0059] Specifically, front-end projects typically contain multiple business function modules. These modules often depend on the same technology stack (e.g., Vue instances), the same UI component libraries (e.g., Element-UI or Ant Design Vue), and common utility functions (e.g., request encapsulation and configuration retrieval methods). If these instances and methods are kept separately in each module, it will not only cause code redundancy but also lead to dependency conflicts and version inconsistencies between different modules.

[0060] Therefore, this embodiment extracts the above content and encapsulates it into a common basic module (e.g., named fksCore), and creates a Vue instance constructor, registers global components, and exposes necessary utility methods and properties within it.

[0061] At the build level, based on the Module Federation configuration mechanism, the Vue instance, common components, and methods are exposed through the `exposes` field, allowing other functional modules to directly reference them at runtime. Simultaneously, shared dependencies are declared through the `shared` field, ensuring that this common base module is the sole provider and preventing subsequent modules from repeatedly loading the same dependencies.

[0062] Once built, this common foundation module is packaged into an independent module federation artifact, which can be uploaded to a CDN service for remote loading. In TypeScript projects, corresponding type files can also be generated and further built into an npm dependency package to support type hints and API documentation, allowing developers to call it from other modules as if it were a local library.

[0063] S200. Decouple the other functional modules, modify the references of each functional module to consume the common basic module, and generate the respective entry file for each functional module.

[0064] In this embodiment, in order to enable independent development and reuse of each functional module, it is necessary to decouple the functional modules in the front-end project.

[0065] Specifically, since the Vue instances, common components, and general methods were extracted to a common base module (such as fksCore) in the previous steps, this step modifies the source code of other functional modules, changing the code paths that originally directly referenced common resources to consume them from the fksCore module. For example, the original syntax of `import{getConfig} from '@ / utils'` in a certain functional module is replaced with `import{getConfig} from 'fksCore / utils'` after the modification, thus ensuring that all functional modules obtain dependencies uniformly through the common base module.

[0066] After modifying the reference paths, a separate entry file needs to be generated for each functional module. This entry file adopts a conventional structure (such as plugin.ts) and is used to declare the routes required by the module, extended lifecycle hooks, supplementary configuration information, etc. For example, the entry file of the login module can declare the login page route, the entry file of the layout module can register global layout components and their related lifecycle callbacks, and the entry file of the component module can expose common components and component meta-information.

[0067] This entry file will be loaded sequentially during application initialization. Its exposed content will be read by the common basic module and dynamically merged into the global application instance, thereby enabling each functional module to extend the application.

[0068] S300: Configure a unique code and module federation build entry point for each functional module in the build configuration file, and use the shared dependency mechanism to avoid repeatedly loading public dependencies.

[0069] In this embodiment, in order to support the independent construction and operation of multiple modules, it is necessary to configure a unique code and module federation entry for each functional module in the project's build configuration file.

[0070] Specifically, a unified build configuration file (e.g., fawkes.config.js or fawkes.config.ts) can be maintained in the project root directory. This configuration file assigns a unique identifier to each functional module (e.g., fksLogin, fksLayout, fksComponent) and specifies the entry file path for that module (e.g., the aforementioned plugin.ts file). In this way, the build tool can identify each module and generate the corresponding build artifacts when executing build commands.

[0071] Meanwhile, the dependency sharing mechanism provided by Module Federation is utilized in the build configuration. Shared dependencies are declared through the `shared` field, ensuring that the same dependency (such as Vue, UI library, state management library, etc.) is loaded only once. For example, when multiple functional modules depend on Vue, duplicate Vue code will be automatically removed during the build process, and the Vue instance already loaded in the common base module will be used directly at runtime. This avoids the build size bloat and runtime conflicts caused by duplicate dependency loading.

[0072] S400. Introduce the project loading module in the project's HTML entry file, and add a project configuration file as the project configuration module in the project root directory. The project configuration module includes a list of remote modules and the loading order and configuration information of each remote module.

[0073] In this embodiment, in order to achieve unified loading and management of multi-module projects at runtime, a project loading module needs to be introduced at the project entry level, and a project configuration file needs to be added to the project root directory as a project configuration module.

[0074] Specifically, add a reference to the project's loading module in the project's index.html file, for example, via... <script src=" / runtime-framework.js">< / script> This approach ensures that the module is loaded first when the application starts. The project loading module is mainly responsible for reading the project configuration file, initializing the runtime environment, and dynamically loading remote modules according to the configuration.

[0075] Simultaneously, a project configuration file (such as site.local.json or site.config.json) is created and maintained in the project root directory. This file serves as the carrier of the project configuration module, recording the key parameters required for the entire project to run. This includes a list of remote modules (remoteModules) and the loading order and configuration information of each remote module. For example, the remote module list can register login modules, layout modules, component modules, etc., specifying their remote loading paths and version information. The loading order field ensures that core modules (such as fksCore) are loaded before functional modules.

[0076] At runtime, the project loading module reads and parses the configuration file, registers the parsing results in the global runtime environment for use by subsequent steps.

[0077] In this embodiment, unlike traditional front-end projects that require maintaining multiple entry files (such as main.js, app.js, etc.) to start the application, the method of this application abandons the cumbersome entry file system and directly uses the project loading module as the single universal entry point. Developers only need to include this loading module in the HTML file and maintain the list and loading order of remote modules through the project configuration module to complete the application startup configuration.

[0078] This approach not only simplifies the structure of the entry file but also reduces the mental burden on developers during the project initialization phase. At the same time, a unified module loading mechanism ensures consistent loading logic across different module extension scenarios, enhancing system maintainability and scalability.

[0079] S500: Execute the build command, call the project build module to independently package the common basic module and each functional module, generate independent build artifacts, and update the project configuration module according to the module list of this build.

[0080] In this embodiment, in order to build the various functional modules and common basic modules of the modified front-end project into deployable products, it is necessary to execute a build command and call the project build module to complete the packaging process.

[0081] Specifically, developers can execute build commands such as `vue3kit build -r fksCore,fksLogin,fksLayout` in the command line, where the `-r` parameter specifies the list of modules to be built. Upon receiving the command, the project build module first parses the build parameters to determine the scope of modules to be packaged.

[0082] Subsequently, the project build module will build the common base module and each functional module independently in sequence: generate an independent build configuration object for each module and set the corresponding entry file and output path; configure the ModuleFederation plugin to ensure that each module can consume the common base module fksCore normally; and output the module artifacts to the corresponding directory according to the unique code (S300) declared in the build configuration file in the previous steps.

[0083] While the artifacts are being generated, the project build module will also update the project configuration module (e.g., site.local.json) based on the list of modules being built: the path of the newly built module or the remote loading address will be written to the list of remote modules; if an existing module is rebuilt, the original entry will be overwritten to ensure that the latest version takes effect.

[0084] Through the above processing, the final output folder not only includes the independent build artifacts of each module, but also provides details on the artifact structure. Figure 5 The diagram illustrates that the local build artifacts include HTML files and static resources from the original public folder. The module folders built in this batch also include the synchronized and updated project configuration modules.

[0085] S600. Deploy the entire build artifact or a single module artifact according to the project configuration module.

[0086] In this embodiment, in order for the completed front-end multi-module project to provide services to the outside world, it is necessary to deploy the entire build artifact or a single module artifact according to the content of the project configuration modules.

[0087] Specifically, developers can choose between two deployment methods based on their actual needs:

[0088] In this overall deployment approach, all artifacts in the output directory, including common foundational modules, functional modules, updated project configuration files, and static resource files, are uploaded to a server or container environment. Access is then provided directly via a web service such as Nginx or Node.js. This mode allows the application to be deployed as a complete system from the outset, making it suitable for initial releases of new projects or large-scale version iterations.

[0089] In single-module deployment, the build artifacts of a specific module, such as the fksLogin or fksLayout directories, are uploaded independently to a CDN or unified module management platform. Version management is performed on this platform, assigning unique URLs to different module versions. When the project runs, the project's module loading mechanism dynamically retrieves and loads the single-module artifacts based on the remote module list and version number information in the project configuration. This approach supports hot-swapping and on-demand updates; developers only need to rebuild and deploy the modified modules without redeploying the entire application.

[0090] In practical applications, overall deployment and single-module deployment can be used in combination. For example, an overall deployment can be used when a project is first launched, while subsequent feature expansion and bug fixes can be quickly completed through single-module deployment, thereby reducing system operation and maintenance costs.

[0091] This step supports flexible deployment strategies, enabling both a full deployment of all artifacts at once and rapid incremental updates of individual modules. Combined with the remote module list in the project configuration module, the application can automatically load the latest remote modules upon startup, ensuring version consistency. This avoids the high costs and inefficiencies of traditional full builds and deployments, improving system iteration speed and maintainability.

[0092] In this embodiment, since the application entry point is replaced by the project loading module, there is no need to generate or maintain a traditional main entry point file during deployment. Deployment only requires ensuring the HTML file and project configuration module are in the correct locations and uploading the built module artifacts to complete the entire application deployment. The advantages of this mechanism are: developers do not need to perform complex build steps to generate a new entry point; adding, deleting, or modifying modules only requires adjusting configuration files; and operations personnel only need to replace or add build artifacts for the entire application to adapt instantly, greatly improving deployment flexibility and efficiency.

[0093] Figure 2 This is a schematic diagram illustrating a front-end multi-module development, execution, and build process provided in this embodiment of the disclosure. Now, in conjunction with... Figure 2 The specific embodiments of this application are further described below.

[0094] S510 determines whether to execute development mode, build mode, or preview mode based on command parameters.

[0095] In this embodiment, in order to support the construction and operation of multi-module projects in different scenarios, it is necessary to first determine the current execution mode based on the command parameters after executing the build command.

[0096] Specifically, developers can specify the execution mode by entering different commands in the command line. For example, when entering `vue3kit dev -r fksLogin,fksLayout`, the command parameters include the keyword `dev`, and the project build module will recognize that it is currently in development mode; when entering `vue3kit build -r fksLogin,fksLayout`, the command parameter is `build`, corresponding to the build mode; when entering `vue3kit preview`, the command parameter is `preview`, corresponding to the preview mode.

[0097] The behavior of the project build module differs depending on the mode. In development mode, the build module generates build artifacts in memory and starts a local service proxy for access, while also implementing real-time injection of code changes using a hot update mechanism. In build mode, the build module packages each functional module and common foundation module into static files and outputs them to a specified directory for deployment. In preview mode, the build module starts a local service based on the build artifacts, enabling developers to quickly verify the module's performance in a production environment.

[0098] This step enables automated identification and branching of build modes, avoiding the complex operation of developers manually switching configurations and ensuring that the project build module can select the appropriate build process according to actual needs.

[0099] S520: Reads the build configuration file in the project directory and merges it with the internal build configuration to generate a complete build configuration.

[0100] In this embodiment, in order to ensure that the project build module can correctly identify the entry point and build strategy of each functional module, it is necessary to read the build configuration file in the project directory after executing the build command and merge it with the internal default configuration to generate a complete build configuration.

[0101] Specifically, the project root directory typically contains a build configuration file, such as fawkes.config.js or fawkes.config.ts, which declares the unique encoding, entry file path, and related compilation parameters for each functional module in the project directory. When the project build module is executed, it first reads this configuration file and parses its contents into configuration objects.

[0102] Meanwhile, the project build module also includes a pre-defined set of default configurations, such as commonly used file parsing rules (supporting file formats like .vue, .ts, .tsx, and .scss), output directory structure conventions, and default declaration rules for shared dependencies. Through a merging mechanism, the system integrates the project configuration file with the internal configuration: when the project configuration file contains fields identical to those in the internal configuration, the project configuration file takes precedence; when the project configuration file does not declare the relevant fields, the default values ​​in the internal configuration are used.

[0103] This step generates a complete build configuration that reflects the developer's personalized configuration needs while maintaining the system's unified build constraints.

[0104] This process ensures consistent basic behavior across different projects during build execution, while also providing developers with flexible expansion options, thus achieving a build configuration management system that balances standardization and flexibility.

[0105] S530: Parse the command parameters to determine the list of modules to be built, and generate the corresponding array of build configuration objects.

[0106] In this embodiment, in order to achieve the flexibility of multi-module construction, the project construction module needs to determine the list of modules to be built based on the command parameters after parsing the construction command, and generate the corresponding array of construction configuration objects.

[0107] Specifically, when executing a build command, developers can specify which modules to build using the `-r` parameter. For example, `vue3kit build -r fksLogin,fksLayout` means only the login and layout modules will be built. Upon receiving this command, the project build module will parse the `-r` parameter, breaking it down into an array of module names. If the `-r` parameter is not specified in the command, all modules registered in the configuration file will be built by default.

[0108] The parsed list of modules will serve as the basis for generating an array of build configuration objects. The project build module will generate an independent build configuration object for each module, which includes the module's unique identifier, entry file path, output directory path, and module federation-related configuration parameters (such as shared dependencies and public items). These build configuration objects are organized into an array for subsequent unified build execution.

[0109] This step enables precise control over the scope of the project build module, supporting both on-demand building of individual or partial modules and building all modules at once, thus providing greater flexibility and efficiency in the development and deployment process.

[0110] S540: Set an independent output path for each build configuration object, configure the module federated build plugin, set the default consumed public base module, and configure shared dependencies and public items.

[0111] In this embodiment, in order to ensure that each functional module can independently build and correctly consume the common basic module, the project building module sets the output path of the artifacts to be consistent with the encoding of each module by default when generating the build configuration object, and configures the parameters related to module federation.

[0112] Specifically, the project build module first specifies an independent output folder for each module, such as / dist / fksLogin and / dist / fksLayout, to ensure that the build artifacts of different modules are not coupled and to facilitate subsequent independent deployment or incremental updates.

[0113] Subsequently, the module federated build plugin is injected into the build configuration object. This plugin generates a remoteEntry.js file for the module, serving as the module's entry point and exposing the components, methods, and instances configured within the module. For example, in the login module's configuration, the login page components and related logic might be exposed through the exposes field.

[0114] Meanwhile, to ensure that each module can correctly consume the common foundation module, the system declares a dependency on the fksCore module by default in the configuration object. By configuring the loading address of fksCore in the remotes field, all functional modules can directly call the instances and methods provided by the common foundation module at runtime without needing to be repackaged.

[0115] In terms of dependency management, building a configuration object also requires declaring shared dependencies and public items. Shared dependencies are configured through the `shared` field, such as common UI libraries like Element UI and Ant Design, which can be used by multiple modules, thus avoiding duplicate loading and improving runtime efficiency. Public items are specified through the `exposes` field to clearly define which components or methods are exposed for other modules or the system to call.

[0116] This step ensures the independence of module artifacts while enabling collaboration and dependency sharing between modules through the module federation plugin, thus laying the foundation for subsequent module loading and execution.

[0117] S550: Generate a build configuration without an entry file to copy static resource files and write the module information for this build to the remote module list of the project configuration module.

[0118] In this embodiment, in order to ensure that the static resource files of the project can be copied correctly and to keep the project configuration module consistent with the latest build result, the project build module will generate an additional build configuration without an entry file when generating the array of build configuration objects.

[0119] Specifically, this entry-free build configuration does not contain an entry point for business logic files, but is specifically designed to perform two types of operations.

[0120] First, it's responsible for copying static resource files. The project root directory typically contains a `public` folder, which stores globally used static resources such as images, stylesheets, and fonts. During the build process, this no-entry-point configuration copies the entire contents of the `public` folder to the root path of the output directory, maintaining the original directory structure, thus ensuring that the application can access these resources correctly at runtime.

[0121] Secondly, it is responsible for updating the project configuration module. In the preceding steps S530 and S540, the list of modules for this build and their corresponding output paths have already been determined. This no-entry-path build configuration will write this module information to the remote module list in the project configuration module (such as the site.local.json file) during the build execution process. The updated content typically includes the module's unique code, the corresponding entry file path, or the remote loading address. Through this process, it ensures that the project configuration module always remains consistent with the build artifacts.

[0122] Through the above processing, the project configuration module can provide accurate remote module information for subsequent deployment and runtime loading, thereby enabling the module to be traceable and manageable.

[0123] This step avoids the problem of missing static resources and ensures that the project configuration module is automatically updated after the build, reducing the burden of manually modifying configuration files and improving the automation and reliability of the entire build process.

[0124] S560. Call the build tool to execute the array of build configuration objects, obtain multiple build instances, and complete the update of the project configuration module.

[0125] In this embodiment, in order to complete the multi-module build process, the project build module calls the underlying build tool to execute the array of build configuration objects generated in the preceding steps, thereby obtaining multiple build instances and completing the final update of the project configuration module.

[0126] Specifically, the build tool can be a commonly used front-end build tool such as Webpack, Rspack, or Vite. This embodiment uses Webpack as an example. The project build module passes an array of configuration objects to Webpack's initialization method through its Node API interface. Webpack will generate an independent build instance based on each configuration object in the array, and each instance corresponds to the packaging process of a functional module or a common basic module.

[0127] During execution, each build instance outputs its corresponding build artifacts to a separate folder according to the configuration requirements, such as dist / fksLogin and dist / fksLayout. Simultaneously, the entry-free configuration object generated in the preceding step S550 is also executed to copy static resource files and update the remote module list in the project configuration module. In this way, the project configuration module can completely record all modules involved in this build and their corresponding entry paths.

[0128] Once all build instances have completed, the project build module will write the final updated project configuration module to the output directory, for example, generating an updated site.local.json file. This file contains information such as the module's unique identifier, remote loading address, and loading order, providing accurate foundational data for subsequent deployment and runtime loading.

[0129] This step enables the project build module to uniformly schedule and complete the build tasks of multiple modules, ensuring that the outputs of each module are consistent with the project configuration module, thereby achieving an efficient and automated multi-module build process.

[0130] In one embodiment, if the execution of the build command is in development mode, the following steps are further included:

[0131] The build artifacts of each functional module are generated in memory. Specifically, the project build module completes the compilation and packaging of modules in memory space, rather than writing them to the disk directory, thereby greatly improving the build speed and avoiding frequent disk I / O operations.

[0132] Access requests to the build artifacts are proxied through a local service. The project build module starts a Node.js-based local service, such as webpack-dev-middleware, to map the build results in memory to resource paths accessible via a port, allowing developers to preview the current project directly in a browser.

[0133] This module monitors source code changes based on hot-update middleware. By integrating hot-update mechanisms such as webpack-hot-middleware, the project build module can monitor source code file modifications in real time and trigger a rebuild of the corresponding module when a change is detected.

[0134] When a change is detected, only the affected modules are rebuilt. Unlike traditional full builds, this approach supports finer-grained incremental updates, meaning that only modified modules are recompiled and produced, thereby further improving build efficiency.

[0135] This implementation allows developers to debug and verify code more quickly in development mode, avoiding the inefficiencies of traditional full compilation, while significantly improving the development experience and iteration efficiency of front-end engineering.

[0136] In one embodiment, remote modules can be added, replaced, or deleted without rebuilding by modifying the list of remote modules in the project configuration module, and the changes will take effect immediately after the page is refreshed.

[0137] Specifically, the project configuration module typically contains information such as the unique code of the remote module, the address of the entry file, and its loading order. When adjustments to the remote module are needed, developers only need to modify the list of remote modules directly in the project configuration module (such as the site.local.json file) without having to re-execute the packaging or build process.

[0138] For example, if you need to add a new business module to the application, simply add the entry address of the module to the remote module list; if you need to replace a module version, update the address corresponding to the module to the new version path; if you need to delete a module that is no longer in use, remove it from the remote module list.

[0139] When the page is refreshed, the project loading module rereads the contents of the project configuration module and completes runtime module registration and loading based on the new list of remote modules. Therefore, adding, replacing, or deleting modules takes effect immediately without rebuilding the entire project.

[0140] This embodiment can significantly reduce the operation and maintenance costs of function adjustments or version switching, enable rapid iteration and flexible deployment of front-end modules, and improve the maintainability and scalability of the system.

[0141] In one embodiment, the project configuration module supports specifying a target version number for a remote module and obtaining the corresponding build artifact based on the version number when loading the remote module.

[0142] Specifically, in addition to recording the unique code and entry address of each module, the remote module list in the project configuration module also supports recording the target version number field. For example, a remote module fksLogin can register "version": "1.2.0" in the configuration file, indicating that when loading this module, the system should prioritize the build artifact with version number 1.2.0.

[0143] During application startup or module loading, the project loading module reads the version number information and combines it with the module's remote address to generate a complete resource path. For example, it might locate fksLogin@1.2.0 / remoteEntry.js through path concatenation or CDN address rules. When multiple versions of the same module exist on the remote server or CDN service, the loading module will strictly retrieve the version number according to the configured target version number to avoid runtime compatibility issues caused by version inconsistencies.

[0144] This mechanism enables the system to manage versioning of remote modules within the same application. When iterating to a new version, developers can directly adjust the version number in the project configuration module without rebuilding the entire application, thus switching or rolling back module versions.

[0145] This implementation not only improves the flexibility and maintainability of the module, but also provides support for version control and canary releases of enterprise applications.

[0146] In one embodiment, the project loading module supports switching the target version of the remote module at runtime and reloading the remote module without rebuilding.

[0147] Specifically, during initialization, the project loading module loads the corresponding version of the build artifact based on the remote module information registered in the project configuration module. In certain business scenarios, users may need to switch remote module versions during application runtime, such as for canary releases, rollback operations, or multi-version compatibility testing.

[0148] To achieve the above requirements, the project loading module provides runtime version switching capabilities. Developers or operations personnel can dynamically specify a new target version number by modifying the runtime configuration. During execution, the loading module will re-fetch the remote module based on the new version number and trigger the process of registering the remote module with the module federation instance.

[0149] During this process, the entire application does not need to be rebuilt; instead, version switching and resource updates are performed only for the target remote module. For example, if the currently running fksLogin module is version 1.2.0, it can be directly switched to version 1.3.0 in the project configuration module. The system will reload the entry file of the new version module and complete runtime registration.

[0150] This embodiment enables dynamic upgrades or rollbacks of modules without rebuilding, thereby significantly improving the system's flexibility and stability during version iterations, canary releases, and emergency handling.

[0151] Figure 3 This is a schematic diagram illustrating a front-end multi-module development, execution, and loading process provided in this embodiment of the disclosure. Now, in conjunction with... Figure 3 The specific embodiments of this application are further described below.

[0152] S710. After the application page is loaded, the project loading module is triggered to call the preset initialization method.

[0153] In this embodiment, after the application page loads, the browser first parses and loads the basic static resource files, such as index.html, style files, and script files. Subsequently, the project loading module located in the entry file is executed, triggering its internal preset initialization method during execution.

[0154] This initialization method is typically registered by runtime-framework.js or a similar runtime script. Once the page has completed its initial load, the loading module will actively call this initialization method, thus entering the first phase of application startup.

[0155] This initialization method serves as the core entry point for application startup, responsible for accessing and resolving the project configuration module, creating runtime instances, and registering remote modules. Therefore, step S710 is not only the starting point of the application loading process but also the trigger point for the entire runtime module management logic.

[0156] By automatically triggering the initialization method after the page loads, the application can obtain the required module configurations immediately upon startup, avoiding issues such as delayed module loading or missing dependencies, thereby ensuring that the overall startup process of the front-end application is efficient and stable.

[0157] S720. The initialization method obtains and parses the project configuration file, and registers the parsing result globally.

[0158] In this embodiment, when the initialization method of the project loading module is triggered, it first obtains and parses the project configuration file. The project configuration file is usually located in the application root directory, such as site.local.json, which records the key configuration information required for the application to run, including the list of remote modules, the unique code of each module, the entry path of each module, and the loading order of the modules.

[0159] Specifically, the initialization method accesses the configuration file via an asynchronous request (such as Ajax or the Fetch API) and parses the file content after retrieving it. The result of the parsing is the transformation of JSON-formatted module information into runtime-recognizable data structures, such as objects or dictionaries.

[0160] After parsing, the initialization method registers the results to the global environment. Registering to the global environment means storing the parsed module configuration information in the application's global state or runtime context, such as attaching it to a global variable, a global configuration object, or injecting it into the context of the module federation runtime instance. This way, components or subprocesses that need to access module information in subsequent steps can directly call them using the globally registered data.

[0161] This step ensures that the application can correctly perceive the distribution and dependencies of remote modules in the early stages of startup, laying the foundation for the creation of subsequent runtime instances (S730) and the loading of common basic modules (S740).

[0162] S730. Create a module federation runtime instance based on the project configuration file, and register the list of remote modules in the instance.

[0163] In this embodiment, after the initialization method completes the parsing of the project configuration file and registers the result globally, it will create a module federation runtime instance based on the project configuration file.

[0164] Specifically, the Module Federation runtime instance is generated by the runtime capabilities provided by Module Federation. It serves as a module management container during application runtime, responsible for operations such as remote module registration, dependency sharing, and dynamic loading. In this embodiment, the project loading module calls MDF.init or a similar initialization interface, passing the parsed remote module information as a parameter to create a new runtime instance.

[0165] After the runtime instance is created, the system registers the list of remote modules from the project configuration file into that instance one by one. Registration refers to storing metadata such as the remote module's unique identifier, entry point address, version information, and loading order into the runtime instance's internal management structure. For example, the fksLogin module will be registered with its identifier fksLogin and the corresponding remoteEntry.js address; the fksLayout module will be added in the same way.

[0166] Through this step, the runtime instance obtains a complete remote module mapping table, which can accurately locate remote resources and perform dynamic loading based on module call requirements in subsequent loading phases.

[0167] Therefore, the role of S730 is to create a module federation runtime instance, providing a unified container and context environment for the dynamic management and runtime scheduling of remote modules, and ensuring that calls and dependencies between modules can be handled correctly.

[0168] S740. Load the common basic module through the runtime instance, and execute the module loading and application startup process exposed by the common basic module.

[0169] In this embodiment, after registering the remote module list, the module federation runtime instance will prioritize loading the common basic modules.

[0170] Specifically, the runtime instance calls `loadRemote` or a similar remote loading method to obtain the entry file of a common base module (such as `fksCore`). This common base module has already exposed the necessary instances, components, methods, and shared dependencies through module federation configuration during the build phase, so it can be directly consumed by other functional modules during runtime loading. After the common base module is loaded, the runtime instance executes the module loading and application startup methods exposed by that module.

[0171] To ensure the universality of the project's loading module, the loading module does not load and execute remote modules; this is handled uniformly by the common base module. Within the common base module, the module entry files are loaded sequentially according to the order of the remote module list configured in the project. Content is then retrieved, the project instance is supplemented and modified, and corresponding callback methods are inserted at specific lifecycle stages to achieve module mounting.

[0172] Figure 4 This is a schematic diagram of a front-end multi-module development system based on module federation, provided as an embodiment of this disclosure. Now, in conjunction with... Figure 4 The specific embodiments of this application are further described below.

[0173] The project build module is used to read the build configuration file and merge it with the internal build configuration. Based on the merged build configuration, it independently packages the common basic modules and each functional module, outputs the build artifacts to the corresponding directory, and updates the project configuration module according to the list of modules built this time.

[0174] Specifically, the project build module first reads the build configuration file (such as fawkes.config.ts) located in the project root directory and merges it with the system's internal preset build configuration to generate complete build configuration parameters. This merging process balances user-defined configurations with system default strategies, ensuring flexibility and consistency in the build process.

[0175] After obtaining the complete build configuration, the project build module will perform independent packaging operations on the common base module and each functional module according to the configuration. During the packaging process, the system will generate a separate output artifact for each module and store it in the corresponding output folder to achieve artifact isolation and independent deployment. At the same time, the project build module will automatically remove dependencies that have been shared by the common base module to avoid duplicate packaging, thereby reducing artifact size and improving build efficiency.

[0176] In addition, the project build module is also responsible for updating the project configuration module based on the list of modules built this time. Specifically, after the build is completed, the system will write the information of the current build artifacts (such as module code, entry file path, version number, etc.) into the project configuration module (such as site.local.json), so that the project loading module can dynamically load remote modules based on the latest configuration at runtime.

[0177] The project's building modules enable the independent construction of common basic modules and functional modules, avoiding the problems of redundant sub-application construction and complex dependency management in traditional micro-frontend architectures, and significantly improving the maintainability and scalability of the construction process.

[0178] In this embodiment, a project build module is provided, which is configured to read the build and packaging configuration and package multiple modules according to the build configuration, so as to realize the development environment construction, hot module replacement and production environment construction of multi-module projects.

[0179] This module can be further encapsulated using front-end build tools such as Webpack, Rspack, and Vite. Taking Webpack as an example, the project build module is extended based on Webpack's Node API and includes the following functionalities:

[0180] 1. Provides the ability to package project resources (including most commonly used files such as .vue, .js, .ts, .tsx, .html, .scss, .css, .png, etc.).

[0181] 2. Provides local development environment build capabilities, enabling rapid builds and hot updates through dev mode.

[0182] 3. Provides the ability to build production and testing environments, and can generate optimized artifacts through build mode for deployment and testing.

[0183] 4. Provides a preview mode, allowing developers to directly launch pre-built artifacts locally and preview them in a simulated production environment.

[0184] 5. Built-in Module Federation 2.0 build plugin, supporting module federation configuration, shared dependency configuration, and generating module federation artifacts.

[0185] 6. Provides the ability to build individual complete applications independently.

[0186] 7. Supports the simultaneous construction of artifacts from multiple specified modules to meet the needs of parallel construction of multiple modules.

[0187] 8. Provide the ability to read the build configuration file (such as fawkes.config.ts) in the project root directory and adjust the build strategy according to the configuration content.

[0188] 9. Provides the ability to modify project configuration files (such as site.local.json) in the project root directory and automatically rewrite file import paths during multi-module builds.

[0189] 10. Provides a function to prune shared dependencies, which can eliminate duplicate dependencies, thereby reducing the size of the build artifact and improving build efficiency.

[0190] Through the above functions, the project building module can uniformly manage the building process of multi-module front-end projects. It can not only meet the independent packaging of a single module, but also support the parallel building of multiple modules, and take into account hot updates in the development stage and performance optimization in the production stage, providing efficient and stable technical support for multi-module front-end development.

[0191] The project configuration module stores project parameters, a list of remote modules, and the loading order and configuration information of each remote module, and is updated during the build or deployment process.

[0192] In this embodiment, a project configuration module is provided for storing core parameter information required for project operation and construction.

[0193] Specifically, the project configuration module is used to store the project's global parameters, a list of remote modules, and the loading order and configuration information of each remote module. The list of remote modules includes a unique code for each functional module, the module's entry file path, version number, and dependency information; the loading order is used to indicate which modules need to be loaded first during application startup to ensure that common dependencies and global instances can be correctly initialized.

[0194] During the build process, the project build module updates the project configuration module based on the actual build artifacts. For example, when a new functional module is added and the build is completed, the system automatically writes the module's information into the remote module list of the project configuration module; when a module's version number is updated, the corresponding configuration content in the project configuration module is also modified synchronously.

[0195] During deployment, the project configuration module also serves as the input for the project loading module. When the application starts, the project loading module reads and parses the configuration module to obtain the remote module distribution, version number, and dependencies, and uses this information to complete the runtime module registration and loading.

[0196] This module eliminates the need for developers to manually maintain complex remote module dependencies. Instead, they can rely on automatic updates during the build and deployment process to ensure that project configurations remain consistent with the actual build artifacts. Furthermore, the centralized storage of project configuration modules enables flexible module switching and version management, providing reliable support for subsequent module reuse and dynamic loading.

[0197] The project loading module is used to read the contents of the project configuration module when the application starts, create a module federation runtime instance and register the list of remote modules, load the public base module and execute the module loading and application startup process exposed by the public base module.

[0198] Specifically, once the application page has loaded, the project loading module first reads the contents of the project configuration module to obtain the stored project parameters, the list of remote modules, and the loading order and configuration information of each remote module. Then, the project loading module calls the runtime interface provided by the module federation to create a module federation runtime instance based on this configuration. This runtime instance acts as a unified management container for remote modules, supporting module registration, dependency sharing, and dynamic loading.

[0199] After the runtime instance is created, the project loading module registers the list of remote modules into that instance one by one. Each remote module, when registered, includes its unique code, entry address, version number, and dependency information, thus ensuring that it can be correctly matched and loaded in subsequent calls.

[0200] After remote module registration is complete, the project loading module will prioritize loading common base modules (such as fksCore). These common base modules have already exposed necessary instances, common components, and methods through module federation configuration during the build process, thus providing fundamental support for the entire application when loaded at runtime. Once loaded, the project loading module will execute the application startup methods exposed in the common base module, such as initializing a global application instance, registering common routes, expanding global configuration parameters, and executing lifecycle callbacks.

[0201] Through this process, applications can initialize common basic modules based on a unified runtime environment at startup, and dynamically load other functional modules as needed, thereby realizing hot-swapping and on-demand loading of modules.

[0202] Therefore, the project loading module provided in this embodiment not only realizes the priority loading and application initialization of common basic modules, but also ensures the dynamic expansion capability of subsequent functional modules, significantly improving the flexibility and maintainability of the front-end project.

[0203] Figure 6This is a functional block diagram of a multi-module development system provided in an embodiment of this disclosure. Figure 6 As shown, by employing the method and system provided in this application, one or more front-end engineering resources can be packaged into independent module build artifacts through the project build module. The application associates multiple remote modules through the project configuration module and imports these remote modules through the project loading module, thereby realizing the combination and integration of modules and completing the application startup.

[0204] Figure 7 This is a schematic diagram illustrating the development and deployment of a multi-module front-end system, provided as an embodiment of this disclosure. Now, in conjunction with... Figure 7 This paper further elaborates on specific embodiments of this application. Both the remote module and the project loading module are deployed on a CDN server or resource management platform, where administrators maintain and manage resources and versions. In the online environment, the project can be deployed simply by determining the application configuration, remote module list, and remote module configuration through the project configuration module, and by deploying the HTML file and project configuration file. Additionally, if there are private remote modules, they can also be deployed to the online environment.

[0205] When developers perform local development, such as Figure 7 As shown, by configuring the remote module list and project build configuration, remote module resources from multiple environments can be obtained. Only a single module needs to be started to combine remote modules for development and debugging. After development is complete, the latest module artifact is built, uploaded to the remote server, and the module update is completed. No modifications are needed in the production environment; users can access the latest resources simply by refreshing the page.

[0206] According to embodiments of this disclosure, an electronic device is also provided, which may include a processor, a communications interface, a memory, and a communication bus, wherein the processor, communications interface, and memory communicate with each other via the communication bus. The processor can invoke logical instructions in the memory to execute a configuration software-based software licensing implementation method.

[0207] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and sold or used as independent products, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0208] On the other hand, this disclosure also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the configuration software-based software licensing implementation methods provided by the above methods.

[0209] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0210] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0211] It should be understood that the above embodiments are only used to illustrate the technical solutions of this disclosure, and not to limit them; although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure.

Claims

1. A front-end multi-module development method based on module federation, characterized in that, The method does not need to split the project into multiple sub-applications, but is directly applied to a single project, including: extracting necessary instances, public components and public methods in the front-end project to a public base module, exposing the necessary instances, the public components and the public methods through module federation configuration, and building the public base module as a module federation product; decoupling other functional modules, modifying the reference of each functional module to consume the public base module, and generating an entry file for each functional module; configuring a unique code and a module federation build entry for each functional module in the build configuration file, and avoiding repeated loading of public dependencies by using a shared dependency mechanism; introducing a project loading module in the project html entry file, and adding a project configuration file as a project configuration module in the project root directory, the project configuration module including a remote module list and loading order and configuration information of each remote module; executing a build command to call a project building module to independently package the public base module and each functional module to generate independent build products, and updating the project configuration module according to the module list of this build; deploying the entire build product or a single module product according to the project configuration module; the execution of the build command, the calling of the project building module to independently package the public base module and each functional module to generate independent build products, and the updating of the project configuration module according to the module list of this build, further including: determining to execute a development mode, a build mode or a preview mode according to a command parameter; reading a build configuration file in a project directory, and merging the build configuration file with an internal build configuration to generate a complete build configuration; determining a module list to be built by parsing the command parameter, and generating a corresponding build configuration object array; setting an independent output path for each build configuration object, configuring a module federation build plug-in, setting a default consumed public base module, configuring shared dependencies and exposed items; generating a build configuration without an entry file to copy static resource files, and writing module information of this build into a remote module list of the project configuration module; calling a build tool to execute the build configuration object array to obtain multiple build instances, and completing the updating of the project configuration module.

2. The front-end multi-module development method based on module federation according to claim 1, wherein, after the deployment is completed, the loading process of the project startup further includes: after the application page is loaded, triggering a project loading module to call a preset initialization method; the initialization method obtains and parses a project configuration file, and registers the parsing result to the global; creating a module federation runtime instance based on the project configuration file, and registering a remote module list in the instance; loading a public base module through the runtime instance, and executing a module loading and application startup process exposed by the public base module.

3. The front-end multi-module development method based on module federation according to claim 1, wherein, when the execution of the build command is in the development mode, further including: generating build products of each functional module in the memory; responding to access requests of the build products through a local service agent; monitoring changes in module source code based on a hot update middleware, and only rebuilding affected modules when changes are detected; The updated module content is injected to the running instance without reloading the whole application.

4. The front-end multi-module development method based on module federation according to claim 1, wherein, The adding, replacing or deleting of remote modules can be done without rebuilding by modifying the remote module list in the project configuration module, and takes effect immediately after page refresh.

5. The front-end multi-module development method based on module federation according to claim 1, wherein, The project configuration module supports specifying target version number for remote modules, and obtaining corresponding build products according to the version number when loading the remote modules.

6. The front-end multi-module development method based on module federation according to claim 5, wherein, The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding.

7. A module federation based front-end multi-module development system for running the module federation based front-end multi-module development method according to any one of claims 1 to 6, characterized in that The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding.

8. An electronic device comprising: The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports switching the target version of the remote modules at runtime, and reloading the remote modules without rebuilding. The project loading module supports

Images