Umi front-end framework dynamic modular packaging method and device based on pnpm and GitSubmodule and medium

Abstract

The invention provides a Umi front-end framework dynamic modular packaging method and device based on pnpm and Git Submodule and a medium, and belongs to the technical field of software engineering. The method comprises the following steps: initializing a main project through pnpm, configuring and defining a workspace configuration file, and defining a sub-package directory; the sub-packages are introduced into a sub-package directory defined in the main project, and each sub-package is managed as an independent Git warehouse; realizing a dynamic mechanism, and integrating the following mechanisms in a main project: a sub-packet distributed decoupling and independent operation management mechanism, a dynamic conflict resolution mechanism and a dynamic route generation mechanism; and installing all dependencies according to the dependency list, and sharing the sub-packet dependency by using a soft link mechanism of pnpm. According to the invention, an efficient and flexible modular packaging scheme is provided, and the development experience of traditional Monorepo is remarkably improved.

Description

Technical Field

[0001] The present invention relates to a dynamic modular packaging method, device and medium for a Umi front-end framework based on pnpm and Git Submodule, and belongs to the technical field of software engineering. Background Art

[0002] In front-end project development, dependency management, modularization management, and version control are core technical challenges. Current mainstream solutions include: Dependency Management: npm and yarn are widely used package management tools that manage project dependencies by centrally installing dependent packages. However, in large monorepo projects, dependency management faces multiple challenges as the number of subpackages increases. For example, multiple subpackages may repeatedly define the same module name or alias. Existing tools only resolve conflicts through soft links or manual configuration, lacking automated mechanisms. This requires developers to check and adjust each conflict one by one, which is time-consuming and error-prone. In addition, npm and yarn are slow to install, especially when the dependency tree is large. Reinstalling dependencies can take several minutes, and the caching mechanism is inefficient, further affecting development efficiency.

[0003] Project structure and module management: The single-repository model (Monorepo) centralizes multiple functional modules in a Git repository, facilitating code reuse and team collaboration. However, this model has significant drawbacks: Strong module coupling and dependency version conflicts. Sharing dependencies and configurations between sub-packages leads to strong coupling. For example, if all sub-packages share the same version of React (such as 17), if sub-package A is upgraded to React 18, it may cause runtime errors in sub-package B because the code of sub-package B is not adapted to the new version. More seriously, when sub-packages are combined with the main project, the main project usually forces a unified dependency version (such as through the package.json in the root directory). If the sub-package dependency versions are inconsistent, it may cause multiple instance problems (such as loading multiple instances of React and causing Hooks errors due to inconsistent context). Existing technologies lack an effective runtime instance management mechanism. Relying solely on version coverage of package management tools cannot completely resolve multiple instance conflicts during dynamic loading. If the global alias configuration is shared by multiple sub-packages, modifying the alias implementation of one sub-package may cause reference errors in other sub-packages, resulting in high debugging and maintenance costs.

[0004] Routing management is complex. As the number of sub-packages increases, routing configurations need to be manually merged. For example, if sub-package A defines route / a and sub-package B defines / b, developers must manually integrate these in the main project. This makes it difficult to dynamically adapt to the addition and deletion of sub-packages, and development efficiency gradually decreases.

[0005] Poor scalability. Sub-packages are tightly bound to the main project. When adding sub-packages or adjusting the module structure, the global configuration needs to be modified, which increases development complexity.

[0006] Module Version Control: The traditional Monorepo model typically uses a single Git repository to manage all modules, preventing sub-packages from running or maintaining independent versions. For example, all sub-packages share the main project's version number. When a sub-package needs to be updated or rolled back, the entire project version must be synchronized. This approach leads to complex version management and limited flexibility. Summary of the Invention

[0007] The purpose of the present invention is to provide a dynamic modular packaging method, device and medium for the Umi front-end framework based on pnpm and Git Submodule, aiming to solve the problems of strong module coupling, complex version management, dependency version conflicts, naming conflicts and difficult routing management in traditional Monorepo projects, provide an efficient and flexible modular packaging solution, and significantly improve the development experience of traditional Monorepo.

[0008] To achieve the above-mentioned purpose, the present invention is implemented through the following technical solutions: A dynamic modular packaging method for the Umi front-end framework based on pnpm and Git Submodule, comprising the following steps: Initialize the main project through pnpm, configure the workspace configuration file, and define the sub-package directory; Introduce the subpackage into the subpackage directory defined in the main project, and manage each subpackage as an independent Git repository; Implement dynamic mechanisms and integrate the following mechanisms into the main project: distributed decoupling and independent operation management mechanism for sub-packages, using GitSubmodule to achieve distributed decoupling of sub-packages; dynamic conflict resolution mechanism, automatically detecting and resolving naming conflicts between sub-packages and generating unique alias mappings; dynamic routing generation mechanism, merging sub-package routing configurations and resolving path conflicts to generate a global routing table; Install all dependencies according to the dependency list, and use pnpm's soft link mechanism to share sub-package dependencies.

[0009] Preferably, the sub-package distributed decoupling and independent operation management mechanism includes: Use Git Submodule to separate subpackages from the main repository into independent Git repositories. Each subpackage maintains an independent code base, commit history, and dependency versions. Configure independent package.json and Umi configuration files for each sub-package to isolate dependency versions and configurations; Use the umi-plugin-single-instance plugin to force sharing of a single dependency instance of the main project when combining sub-packages.

[0010] Preferably, the plug-in umi-plugin-single-instance specifically includes: Declare public dependencies as external dependencies through Webpack's externals configuration; Inject dependency instances into the main project entry file; Dynamically scan sub-package dependency versions, perform runtime injection on sub-packages with multiple instance risks, and force the use of main project dependency versions.

[0011] Preferably, the dynamic conflict resolution mechanism includes: Traverse the sub-package configuration files, extract the alias definitions and build a global mapping table; Detect duplicate aliases and generate new aliases by adding the subpackage unique identifier; Inject the adjusted alias into the Umi build configuration and transform the code reference during compilation through the Babel plugin.

[0012] Preferably, the dynamic routing generation mechanism includes: Scan subpackage routing configuration files and extract path and component mappings; Conflicting paths are uniquely handled by adding sub-package identifiers or priority rules; Merge sub-package routing tables and inject them into the main project Umi routing system, supporting dynamic loading at runtime; Monitor sub-package directory changes and trigger automatic updates of routing tables.

[0013] Preferably, the sub-package is associated with the main repository through the Git Submodule pointer, and the latest version of the sub-package is synchronized through the git submoduleupdate --remote command; the main project dynamically combines sub-package dependencies through pnpm-workspace.yaml and pnpminstall.

[0014] A dynamic modular packaging device for a Umi front-end framework based on pnpm and Git Submodule comprises a processor and a memory storing program instructions. The processor is configured to execute the dynamic modular packaging method for the Umi front-end framework based on pnpm and Git Submodule when running the program instructions.

[0015] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the dynamic modular packaging method of the Umi front-end framework based on pnpm and Git Submodule.

[0016] The advantages of the present invention are: Through distributed decoupling and independent operation management of sub-packages, pnpm is used to allow sub-packages to install different dependency versions when running independently, and umi-plugin-single-instance is used to solve the multi-instance problem when assembling the main project. As a core innovation, the plugin provides dynamic runtime instance management capabilities, ensuring the operation of a single React instance, completely resolving context inconsistencies and improving operational stability.

[0017] Through the dynamic conflict resolution mechanism, naming conflicts between sub-packages are automatically detected and adjusted to improve module isolation and development efficiency.

[0018] Through dynamic route generation, automatic parsing and integration of sub-package routes, it simplifies management and supports dynamic expansion. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings are used to provide further understanding of the present invention and constitute a part of the specification. They are used to explain the present invention together with the embodiments of the present invention and do not constitute a limitation of the present invention.

[0020] Figure 1 Schematic diagram of the process of the present invention.

[0021] Figure 2 Schematic diagram of the present invention. DETAILED DESCRIPTION

[0022] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0023] like Figure 1 、 Figure 2 As shown in the figure, a dynamic modular packaging method for the Umi front-end framework based on pnpm and Git Submodule is proposed. This method combines the efficient dependency management of pnpm and the distributed version control of Git Submodule through a single warehouse structure, introduces a sub-package distributed decoupling and independent operation management mechanism, a dynamic conflict resolution mechanism, and a dynamic routing generation mechanism.

[0024] Specifically, the following steps are included: S1: Initialize the main project through pnpm, configure the pnpm-workspace.yaml file, and define the subpackage directory.

[0025] S2: Introduce the subpackage into the subpackage directory defined in the main project, and manage each subpackage as an independent Git repository.

[0026] S3: Implement dynamic mechanisms and integrate the following mechanisms into the main project: distributed decoupling and independent operation management mechanism for sub-packages, achieving distributed decoupling of sub-packages through Git Submodule; dynamic conflict resolution mechanism, automatically detecting and resolving naming conflicts between sub-packages, generating unique alias mappings; dynamic routing generation mechanism, merging sub-package routing configurations and resolving path conflicts, generating a global routing table.

[0027] S4: Install all dependencies according to the dependency list and use pnpm's soft link mechanism to share sub-package dependencies.

[0028] As a refinement of the above embodiment, the sub-package distributed decoupling and independent operation management mechanism is as follows: Git Submodules enable distributed decoupling of subpackages. Each subpackage is managed as an independent Git repository, supporting independent development, execution, and version control. It can also be combined with the main package to form a Monorepo project. pnpm flexibly manages subpackage dependency versions, allowing different versions (such as React 18 and 17) to be used when running independently. When combining, if multiple instances are present (such as inconsistent React contexts), umi-plugin-single-instance can be used to resolve them. If multiple instances are not a problem, subpackage version flexibility is retained. The importance of the plugin lies in its ability to dynamically manage runtime instances, ensuring a single React instance runs and avoiding context conflicts that traditional solutions cannot resolve. For example, if subpackage A runs independently using React 18, while subpackage B uses React 17, the plugin can be used to force a single React 18 instance to run when combined.

[0029] The technical principles are as follows: Distributed decoupling: Utilize the submodule feature of Git Submodule to separate subpackages from the single Git repository of the main project into independent Git repositories. Each subpackage has an independent code base, commit history, and dependency management, reducing direct coupling between subpackages.

[0030] Dependency version management during independent runtime: Using pnpm's workspace feature, you can configure an independent dependency environment (such as a separate node_modules) for each sub-package, allowing sub-packages to install different versions of dependencies. For example, sub-package A using React 18 and sub-package B using React 17, they will not interfere with each other when running independently.

[0031] Configuration isolation during independent runtime: Use independent sub-package configuration files (such as .umirc.js) to avoid sharing global alias configurations. For example, sub-packages A and B can each define @ / utils without affecting each other.

[0032] Dependency version management during combination: When there is no multi-instance problem, pnpm allows sub-packages to retain their own dependency versions, and the main project loads the node_modules of the sub-package through pnpm's soft link mechanism, supporting version differences. For example, React18 of sub-package A and React17 of sub-package B can coexist, and the main project is dynamically loaded, which is suitable for scenarios that do not rely on a single context (such as tool libraries). When there is a multi-instance problem, a plug-in (umi-plugin-single-instance) is used to force all sub-packages to share a single dependency instance of the main project (such as React18). This plug-in completely solves the context inconsistency problem caused by multiple instances of React (such as Hooks errors) through runtime checking and instance injection, which is the core innovation of the present invention.

[0033] Configuration coordination during assembly: The main project's configuration management system dynamically adjusts alias configurations between sub-packages to avoid global alias conflicts. For example, mapping @ / utils in sub-package A to pkgA / @ / utils ensures uniqueness during assembly.

[0034] Independent operation and dynamic combination: Subpackages can be run independently or dynamically combined into the main project through Git Submodule pointers and pnpm workspaces to form a flexible Monorepo structure.

[0035] The specific implementation is as follows: (1) Subpackage separation: In the main project, use the git submodule add command to add the subpackage as an independent GitSubmodule. For example, run git submodule add git@repo.com:pkgA.git packages / pkgA to add subpackage A to the packages / pkgA directory and generate a .gitmodules file to record the subpackage repository address.

[0036] (2) Dependency version management during standalone runtime: Configure a separate package.json file for each sub-package, defining its required dependency versions. For example, sub-package A's package.json file declares "react":"18.0.0", while sub-package B declares "react":"17.0.0". Run pnpm install in the sub-package directory to generate a separate node_modules file, optimizing disk usage through pnpm's soft link mechanism.

[0037] (3) Configuration isolation during independent runtime: Each sub-package uses an independent Umi configuration file (such as packages / pkgA / .umirc.js) to define a dedicated alias. For example, sub-package A configures alias:{'@ / utils':'. / src / utils'}, and sub-package B configures a different @ / utils to avoid global configuration sharing.

[0038] (4) Independent operation support: Configure an independent Umi build script and runtime environment for each sub-package. For example, run umi g app in the root directory of sub-package A to generate a Umi application template, configure the script "start": "umidev" in package.json, and allow sub-package A to be started independently through npm run start (such as listening on localhost:8001).

[0039] (5) Dependency version management and multi-instance solutions during combination: If there are no multiple instances: Configure the main project's pnpm-workspace.yaml file to define the subpackage path (e.g., packages / *). Run pnpm install in the main project, loading the subpackage's node_modules using pnpm's soft link mechanism. This allows subpackage A to use React 18 and subpackage B to use React 17 to coexist, and the main project dynamically references each version.

[0040] To address the multiple instance issue: Develop the core plugin umi-plugin-single-instance, set React as an external dependency through Webpack's externals configuration, for example, externals:{'react':'React'}, and provide a global React18 instance in the main project's entry file (such as app.js). The plugin dynamically scans the React versions of sub-packages during build time. If a multi-instance risk is detected (for example, if sub-package B still references React17 and hasn't been overwritten), runtime injection forces the use of the main project version to ensure single-instance operation. The importance of this plugin lies in its ability to provide dynamic runtime management capabilities, a key innovation that distinguishes this invention from the prior art.

[0041] (6) Configuration coordination during combination: The main project scans the sub-package configuration through a custom Umi plug-in and dynamically adjusts the alias. For example, @ / utils of sub-package A is mapped to pkgA / @ / utils, and @ / utils of sub-package B is mapped to pkgB / @ / utils. The alias configuration of the main project is injected to ensure uniqueness during combination.

[0042] (7) Version management: Subpackages maintain independent version numbers (e.g., 1.0.0) in their respective repositories, and version control is implemented through Git tags and the npm publishing mechanism. For example, after subpackage A is updated, running cd packages / pkgA && npm versionpatch && npm publish will independently release the new version 1.0.1, and other subpackages will not be affected.

[0043] (8) Dynamic combination: The main project records subpackage references in the .gitmodules file and uses the git submoduleupdate --remote command to synchronize the latest versions of subpackages. pnpm manages dependencies through pnpm-workspace.yaml and pnpm install. The main project's Umi build process combines plug-ins and configuration adjustments to automatically combine subpackages for operation.

[0044] Example operation: Add subpackage A: git submodule add git@repo.com:pkgA.git packages / pkgA Subpackage A configures dependencies and runs: cd packages / pkgA&&pnpm add react@18&&npm runstart (starts an independent service, such as localhost:8001) Subpackage B configures dependencies and runs: cd packages / pkgB&&pnpm add react@17&&npm runstart (starts an independent service, such as localhost:8002) Main project combines sub-packages (no multiple instance issues): Configure pnpm-workspace.yaml:{"packages":["packages / *"]}.

[0045] Run git submodule update --remote&&pnpm install. Sub-package A uses React 18 and sub-package B uses React 17. The main project is loaded dynamically.

[0046] The main project combines sub-packages (multiple instance issues): Enable umi-plugin-single-instance and run git submodule update --remote && pnpm install && pnpm start to ensure that a single React 18 instance is running.

[0047] As a refinement of the above embodiment, the dynamic conflict resolution mechanism includes automatically detecting and resolving naming conflicts (such as duplicate aliases or module names) between sub-packages, ensuring uniqueness and isolation of module references. For example, if multiple sub-packages define the same alias @ / utils, the system dynamically adjusts the alias to pkgA / @ / utils and pkgB / @ / utils.

[0048] The technical principles are as follows: Conflict detection: By scanning the configuration files of sub-packages, identifying duplicate naming definitions (such as aliases and module paths), and building a global naming mapping table.

[0049] Dynamic adjustment: Generate a namespace based on the unique identifier of the sub-package (such as the package name), automatically assign new identifiers to conflicting items, and resolve naming overlap issues.

[0050] Seamless integration: Inject the adjusted naming into Umi's build process, ensure runtime consistency through code conversion, and avoid errors caused by manual modifications.

[0051] The specific implementation methods are as follows: (1) Subpackage scanning: Use the function (getPackageInfo) to traverse the packages directory, read the configuration files of each subpackage (such as .umirc.js and package.json), and extract the alias definition. For example, subpackage A defines @ / utils to point to . / src / utils, and subpackage B also defines @ / utils to point to a different path.

[0052] (2) Conflict detection: Analyze the aliases of all subpackages and identify duplicate key values. For example, if @ / utils is detected to be repeated in subpackages A and B, it will be marked as a conflicting item.

[0053] (3) Dynamic adjustment: Add a package name prefix (such as pkgA / ) to the conflicting aliases to generate a unique identifier. For example, @ / utils is adjusted to pkgA / @ / utils and pkgB / @ / utils, and the alias mapping table is updated to store the new path.

[0054] (4) Configuration injection: Inject the adjusted alias into Umi's build configuration (such as extraBabelPlugins or the alias field in .umirc.js). The Babel plugin transforms the references in the code during compilation (such as replacing import '@ / utils' with import'pkgA / @ / utils'), ensuring that module references are accurate during development and runtime.

[0055] The sample pseudo code is as follows: function resolveAliasConflicts(packages) {const aliasMap=new Map(); for(const pkgName in packages){ const{alias}=packages[pkgName]; for(const key in alias){ if(aliasMap.has(key)){ aliasMap.set(`${pkgName} / ${key}`,alias[key]); }else{ aliasMap.set(key,alias[key]);} } packages[pkgName].alias=Object.fromEntries(aliasMap); } return packages; } As a refinement of the above embodiment, the technical principle of the dynamic routing generation mechanism is as follows: Route parsing: Scan the sub-package's route configuration file, extract the path and component mapping, and form a sub-package-level route collection.

[0056] Conflict handling: Resolve routing path conflicts through namespace or priority rules to ensure the uniqueness of the global routing table.

[0057] Dynamic merging: Integrate sub-package routes and inject them into the Umi routing system of the main project, supporting dynamic loading and updating at runtime.

[0058] The specific implementation methods are as follows: (1) Route scanning: traverse the subpackage directory and read the route configuration file (such as routes.js or the routes field in .umirc.js). For example, subpackage A's routes.js defines {path:' / a',component:'. / pages / a'}, and subpackage B defines {path:' / b',component:'. / pages / b'}.

[0059] (2) Conflict handling: Detect routing conflicts (e.g., duplicate definitions of / a) and resolve them by adding subpackage identifiers (e.g., / pkgA / a) or priority rules (e.g., by subpackage loading order). For example, if subpackages A and B both define / a, adjust them to / pkgA / a and / pkgB / a.

[0060] (3) Route merging: Integrate the routes of each sub-package into a global routing table and inject it into Umi's dynamic routing system (such as through the umi-plugin-routes plugin). For example, the merged result is [{path:' / pkgA / a',component:'pkgA / pages / a'},{path:' / pkgB / b',component:'pkgB / pages / b'}].

[0061] (4) Dynamic Update: When subpackages are added or removed, the package directory is monitored for changes and the routing table is automatically regenerated. For example, a file monitoring tool (such as chokidar) can be used to detect subpackage changes and trigger the re-merging of routes, eliminating the need for manual adjustments.

[0062] Example process: Subpackage A: {path:' / a',component:'. / pages / a'} Subpackage B: {path:' / b',component:'. / pages / b'} Merged result: [{path:' / pkgA / a',component:'pkgA / pages / a'},{path:' / pkgB / b',component:'pkgB / pages / b'}].

[0063] It should be noted that: in the traditional single-repository mode, sub-packages share the main project dependencies and versions, which are strongly coupled and cannot flexibly manage dependency versions. For example, all sub-packages share React17, and upgrading sub-package A to React18 may cause runtime errors in sub-package B. When the main project is combined, the version is forced to be unified or multiple instances may occur (such as inconsistent Hooks context), which lacks runtime instance management capabilities and takes a long time. The distributed decoupling and independent operation management of sub-packages in the present invention utilizes Git Submodule and pnpm to implement the use of different dependency versions when sub-packages run independently (such as sub-package A uses React18, and sub-package B uses React17). When combined, umi-plugin-single-instance is used to solve the multiple instance problem. As a core innovation, this plug-in provides dynamic runtime instance management, ensures the operation of a single React instance, completely eliminates the problem of inconsistent context, and greatly improves operational stability and version management flexibility.

[0064] Existing technologies, such as Webpack or pnpm, resolve naming conflicts through manual configuration, requiring the adjustment of aliases one by one, which is time-consuming and error-prone. The dynamic conflict resolution mechanism of the present invention automatically detects and adjusts conflicting aliases, significantly reducing manual work and ensuring accurate module references.

[0065] The existing technology requires manual merging of sub-package routes, which is complex to configure. The present invention's dynamic routing generation automatically parses and aggregates routes, significantly shortening configuration time and improving development efficiency and module management flexibility.

[0066] This invention provides a flexible and efficient modular packaging solution through distributed decoupling of sub-packages, independent runtime management, dynamic conflict resolution, and route generation. The introduction of plugins significantly outperforms the static configuration and lack of runtime management limitations of existing technologies, making it particularly suitable for large-scale enterprise-level front-end projects requiring high stability and consistency.

[0067] The disclosed embodiment also provides a dynamic modular packaging device for the Umi front-end framework based on pnpm and Git Submodule, comprising a processor and a memory. Optionally, the device may further comprise a communication interface and a bus. The processor, the communication interface, and the memory may communicate with each other via the bus. The communication interface may be used for information transmission. The processor may call logic instructions in the memory to execute the dynamic modular packaging method for the Umi front-end framework based on pnpm and Git Submodule of the above embodiment.

[0068] In addition, the logic instructions in the above-mentioned memory can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product.

[0069] The memory, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as the program instructions / modules corresponding to the methods in the embodiments of the present disclosure. The processor executes the program instructions / modules stored in the memory to perform functional applications and data processing, thereby implementing the dynamic modular packaging method of the Umi front-end framework based on pnpm and GitSubmodule in the above-mentioned embodiments.

[0070] The memory may include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function; the data storage area may store data generated based on the use of the terminal device. Furthermore, the memory may include high-speed random access memory and non-volatile memory.

[0071] An embodiment of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute the above-mentioned dynamic modular packaging method of the Umi front-end framework based on pnpm and Git Submodule.

[0072] The aforementioned computer-readable storage medium may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0073] The technical solutions of the embodiments of the present disclosure may be embodied in the form of a software product, which is stored in a storage medium and includes one or more instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in the embodiments of the present disclosure. The aforementioned storage medium may be a non-transitory storage medium, including: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, an optical disk, and other media that can store program code, or a transient storage medium.

[0074] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art will be able to modify the technical solutions described in the aforementioned embodiments or substitute equivalents for some of the technical features. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A dynamic modular packaging method for the Umi front-end framework based on pnpm and Git Submodule, characterized in that: The following steps are involved: Initialize the main project through pnpm, configure the workspace configuration file, and define the sub-package directory; Introduce the subpackage into the subpackage directory defined in the main project, and manage each subpackage as an independent Git repository; Implement a dynamic mechanism and integrate the following mechanisms into the main project: distributed decoupling and independent operation management mechanism for sub-packages, using GitSubmodule to achieve distributed decoupling of sub-packages; dynamic conflict resolution mechanism, automatically detecting and resolving naming conflicts between sub-packages and generating unique alias mappings; Dynamic routing generation mechanism, merges sub-packet routing configurations and resolves path conflicts to generate a global routing table; Install all dependencies according to the dependency list, and use pnpm's soft link mechanism to share sub-package dependencies.

2. The Umi front-end framework dynamic modular packaging method based on pnpm and Git Submodule according to claim 1 is characterized in that, The sub-package distributed decoupling and independent operation management mechanism includes: Use Git Submodule to separate subpackages from the main repository into independent Git repositories. Each subpackage maintains an independent code base, commit history, and dependency versions. Configure independent package.json and Umi configuration files for each sub-package to isolate dependency versions and configurations; Use the umi-plugin-single-instance plugin to force sharing of a single dependency instance of the main project when combining sub-packages.

3. The dynamic modular packaging method of the Umi front-end framework based on pnpm and Git Submodule according to claim 2 is characterized in that, The plugin umi-plugin-single-instance specifically includes: Declare public dependencies as external dependencies through Webpack's externals configuration; Inject dependency instances into the main project entry file; Dynamically scan sub-package dependency versions, perform runtime injection on sub-packages with multiple instance risks, and force the use of main project dependency versions.

4. The dynamic modular packaging method of the Umi front-end framework based on pnpm and Git Submodule according to claim 1 is characterized in that: The dynamic conflict resolution mechanism includes: Traverse the sub-package configuration files, extract the alias definitions and build a global mapping table; Detect duplicate aliases and generate new aliases by adding the subpackage unique identifier; Inject the adjusted alias into the Umi build configuration and transform the code reference during compilation through the Babel plugin.

5. The dynamic modular packaging method of the Umi front-end framework based on pnpm and Git Submodule according to claim 1 is characterized in that: The dynamic routing generation mechanism includes: Scan subpackage routing configuration files and extract path and component mappings; Conflicting paths are uniquely handled by adding sub-package identifiers or priority rules; Merge sub-package routing tables and inject them into the main project Umi routing system, supporting dynamic loading at runtime; Monitor sub-package directory changes and trigger automatic updates of routing tables.

6. The Umi front-end framework dynamic modular packaging method based on pnpm and GitSubmodule according to claim 1 is characterized in that, The sub-package is associated with the main repository through the Git Submodule pointer, and the latest version of the sub-package is synchronized through the git submoduleupdate--remote command; the main project dynamically combines sub-package dependencies through pnpm-workspace.yaml and pnpminstall.

7. A dynamic modular packaging device for the Umi front-end framework based on pnpm and Git Submodule, comprising a processor and a memory storing program instructions, characterized in that: The processor is configured to execute the Umi front-end framework dynamic modular packaging method based on pnpm and Git Submodule as described in any one of claims 1-6 when running the program instructions.

8. A computer-readable storage medium, characterized in that A computer program is stored thereon, which, when executed by a processor, implements the dynamic modular packaging method of the Umi front-end framework based on pnpm and Git Submodule as described in any one of claims 1 to 6 above.

Images