A method, system, and medium for modular construction and aggregated debugging of multi-page applications

Abstract

This invention discloses a method, system, and medium for modular construction and aggregated debugging of multi-page applications, belonging to the field of front-end development technology. This method establishes a modular organizational framework based on a workspace mechanism within a single codebase, dividing the application into independently buildable and deployable page packages and common library packages, achieving a high degree of decoupling and code reuse of business modules. During the debugging phase, the system automatically discovers all page packages for developers to interactively select; subsequently, it automatically assigns unique ports to the selected page packages, starts each development server in parallel, and finally starts a main proxy server listening on a fixed port. Based on the mapping relationship between package name and port, it forwards requests to the corresponding sub-services, while simultaneously generating a unified navigation page. This invention organically combines modular organization with aggregated debugging tools, solving the technical problems of bloated projects, cumbersome debugging, and low parallel efficiency in the development of large-scale multi-page applications, thus improving the development experience and engineering efficiency.

Description

Technical Field

[0001] This invention relates to the field of front-end engineering development technology, and in particular to a method, system, and medium for modular construction and aggregated debugging of multi-page applications. Background Technology

[0002] In the development of large-scale web applications, projects typically contain dozens or even hundreds of functional pages, and need to share common UI components, utility functions, and other common code. How to efficiently organize projects, manage code, and perform local development and debugging is a core challenge in the field of front-end engineering.

[0003] Currently, the main technical solutions for organizing such large-scale multi-page application projects are as follows:

[0004] (1) Monolithic Repository Solution: All page code is stored in a single project, and shared code is achieved through local references. This solution has extremely high project coupling. Modifying any page or common component often requires rebuilding and redeploying the entire application, resulting in a slow development and release process, and is not suitable for parallel collaboration in large teams.

[0005] (2) Multi-repository solution: Each page or module is managed as an independent code repository, and the shared code is published to the NPM artifact repository as an independent repository for other projects to install and use. This solution makes the sharing and version management of public code extremely complicated, requires frequent switching between multiple projects during debugging, the development experience is fragmented, and atomic modifications across repositories are almost impossible to achieve.

[0006] (3) Basic Monorepo solution: This solution uses tools such as Lerna and Yarn / PNPM Workspace to integrate multiple modules into a single codebase, with shared code referenced internally through the workspace mechanism. While this solution solves the code sharing problem, it lacks a mature local debugging solution when developing multi-page applications. If developers want to debug multiple pages simultaneously, they usually need to manually open multiple terminal windows locally, start the development server for each page one by one, and manually manage and record the different port numbers used by each service. This process is cumbersome, inefficient, and error-prone.

[0007] In summary, multi-page application development has a rigid requirement for modular organization of project structure and local aggregation debugging. However, existing monolithic repository solutions suffer from high coupling and slow build and deployment, while multi-repository solutions suffer from complex code sharing and version management and fragmented debugging experience. The basic Monorepo solution lacks a convenient mechanism for parallel startup of multiple services and unified debugging, resulting in low efficiency in the development of large-scale multi-page applications and cumbersome local environment configuration. There is an urgent need for better technical solutions to address these core pain points. Summary of the Invention

[0008] The purpose of this invention is to provide a method, system, and medium for modular construction and aggregation debugging of multi-page applications, thereby solving all or one of the aforementioned problems in the prior art.

[0009] To solve the above-mentioned technical problems, the specific technical solution of the present invention is as follows:

[0010] On one hand, the present invention provides a method for modular construction and aggregated debugging of multi-page applications, including the following steps: Modular organization step: establishing a package structure based on the workspace mechanism in a single codebase, the package structure containing multiple page packages and at least one public library package, each page package having its package name; wherein, each page package is configured to be able to be built and deployed independently; the page package declares its dependency on the public library package through the workspace mechanism, so that it can directly link to the local public library package code during dependency resolution;

[0011] Aggregated debugging steps: In response to the developer's operation to initiate aggregate debugging, the workspace configuration is scanned to discover all the page packages and their package names, and the developer's selection of at least one of the page packages is received through the interactive interface; based on the number of selected page packages, a unique available port number is assigned to each selected page package, and a mapping relationship between package name and port number is established; development servers for each selected page package are started in parallel, with each development server starting based on its assigned port number; after all the development servers are started and accessible, a main proxy server is started. The main proxy server listens on a fixed port, and according to the mapping relationship, it forwards access requests for different page package paths containing the selected page package name on the fixed port to the development server with the corresponding port number, and generates a unified navigation page.

[0012] As an improved approach, in the modular organization step:

[0013] The page package represents either a standalone page or a cohesive business function module;

[0014] The public library package contains code that can be shared by multiple page packages.

[0015] As an improved approach, the aggregation debugging step, specifically the scanning workspace configuration to discover all page packages and their package names, further includes:

[0016] The workspace configuration of the single code repository is read and parsed to identify the sub-packages that meet the preset conditions for independent operation, and their package names are extracted as the page packages.

[0017] As an improved solution, receiving the developer's selection of at least one of the page packages via an interactive interface further includes:

[0018] The discovered package names are presented as a multi-select list through the command-line interactive interface, and the results selected by the developer are used as the selected page packages.

[0019] As an improved approach, the step of assigning a unique available port number to each selected page packet and establishing a mapping relationship between packet names and port numbers further includes:

[0020] Using a port lookup library, based on the number of selected page packets received by the interactive interface, the system dynamically obtains available, non-conflicting port numbers and stores the established mapping relationship between packet names and port numbers as a string in the environment variables of the current process.

[0021] As an improved approach, the parallel startup of development servers for each selected page package, each development server starting based on an assigned port number, further includes:

[0022] The process iterates through the page packages selected by the developer, creates an independent child process for each selected page package using the child process creation interface, passes the environment variables to each child process, and executes the development startup commands for each page package in parallel. The development server within each page package reads its corresponding port number from the environment variables and starts the service on that port.

[0023] As an improved approach, starting a primary proxy server further includes:

[0024] The main proxy server is created using a web server framework and a proxy middleware library, and a preset fixed listening port is configured for it. According to the mapping relationship between package name and port number, a proxy rule is created for the development server of each selected page package, which forwards the request path containing the corresponding package name to the independent port listened to by the development server of that page package. The main proxy server also dynamically generates an HTML navigation homepage, which centrally displays the access entry links of all launched page packages.

[0025] On the other hand, the present invention also provides a system for modular construction and aggregate debugging of multi-page applications, comprising:

[0026] A modular organization framework is used to establish a package structure based on a workspace mechanism in a single codebase. The package structure includes multiple page packages and at least one public library package. Each page package has its own package name. Each page package is configured to be built and deployed independently. The page package declares its dependency on the public library package through the workspace mechanism, so that it can directly link to the local public library package code during dependency resolution.

[0027] The aggregation and debugging device includes:

[0028] The package discovery unit is used to receive the developer's command to start aggregate debugging, scan the workspace configuration, and discover all the page packages and their package names.

[0029] An interactive selection unit is used to receive a developer's selection of at least one of the page packages via an interactive interface;

[0030] The port allocation unit is used to assign a unique available port number to each selected page packet based on the number of selected page packets, and to establish a mapping relationship between packet name and port number.

[0031] The sub-service startup unit is used to start the development servers of each selected page package in parallel, and each development server is started based on the port number assigned to it.

[0032] The proxy service unit is used to start a main proxy server after all the development servers are started and accessible. The main proxy server listens on a fixed port and, according to the mapping relationship, forwards access requests for different page package paths containing the selected page package name on the fixed port to the development server with the corresponding port number, and generates a unified navigation page.

[0033] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the method for modular construction and aggregation debugging of multi-page applications.

[0034] The beneficial effects of the technical solution of this invention are:

[0035] 1. The method for modular construction and aggregated debugging of multi-page applications described in this invention decouples business modules by building independently buildable and deployable page packages and shareable public library packages in a single codebase, reducing project complexity and improving code maintainability and reusability. Simultaneously, through aggregated debugging steps, the development server startup process for multiple page packages is simplified to a single interactive operation, automatically completing port allocation and proxy forwarding, and providing a unified navigation page as the debugging entry point. This completely solves the problems of cumbersome port management and the need to manually launch multiple terminal windows during parallel debugging of multiple pages in existing technologies, overcoming the shortcomings of existing technologies and significantly improving the local development and debugging efficiency and developer experience of large-scale multi-page application projects, thus possessing high application value.

[0036] 2. The system for modular construction and aggregate debugging of multi-page applications described in this invention can achieve the method for modular construction and aggregate debugging of multi-page applications described in this invention by cooperating with the system modules of the modular organization framework and the package discovery unit, interaction selection unit, port allocation unit, sub-service startup unit and proxy service unit in the aggregate debugging device.

[0037] 3. The computer-readable storage medium of the present invention can enable the boot system module to cooperate, thereby realizing the method of multi-page application modular construction and aggregation debugging of the present invention. Furthermore, the computer-readable storage medium of the present invention also effectively improves the operability of the method of multi-page application modular construction and aggregation debugging. Attached Figure Description

[0038] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0039] Figure 1 This is a schematic diagram of the modular framework structure of an embodiment of the present invention;

[0040] Figure 2 This is a flowchart of the aggregation debugging system according to an embodiment of the present invention. Detailed Implementation

[0041] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, so that the advantages and features of the present invention can be more easily understood by those skilled in the art, thereby providing a clearer and more explicit definition of the scope of protection of the present invention.

[0042] In the description of this invention, it should be noted that the embodiments described in this invention are only some embodiments of this invention, not all embodiments; based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0043] The terms "first," "second," etc., used in this specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0044] In the description of this invention, it should be noted that:

[0045] Monorepo stands for Monolithic Repository, which refers to an organizational strategy that stores the code of multiple projects or modules in the same code repository.

[0046] Page packages are sub-packages that represent an independent page or a cohesive business function module. They contain independent build configuration files and dependency configuration files and can be built, packaged, and deployed independently.

[0047] Public library packages refer to sub-packages that contain code that can be shared across multiple page packages, such as UI component libraries and utility function libraries;

[0048] The workspace mechanism refers to the functionality provided by the package manager that allows multiple packages to be declared within a single codebase and linked locally, enabling a package to directly reference the local code of another package without having to publish it to the registry.

[0049] An aggregated proxy server refers to a main proxy server that listens on a fixed port and forwards requests to the corresponding page's sub-service on the port that is actually being listened to, based on the mapping relationship between packet names and ports, and dynamically generates a unified navigation page.

[0050] Sub-services refer to the development and debugging services that each page package starts on the port allocated to it by its development server.

[0051] Port mapping refers to the mapping between packet names and automatically assigned available port numbers;

[0052] Environment variables are data carriers used to pass port mapping relationships between processes, such as PACKAGES_PORT which stores the mapping relationship as a JSON string.

[0053] Example 1 provides a method for modular construction and aggregated debugging of multi-page applications, which addresses the problems of insufficient development and debugging efficiency caused by bloated project structures, high module coupling, difficulty in code reuse, low parallel development efficiency, and cumbersome local development environment configuration in the development of large-scale multi-page applications. Figures 1-2 As shown, it includes:

[0054] Step 1: Modular organization and construction steps.

[0055] Within a single codebase, establish a package management structure that conforms to the workspace mechanism, dividing the project into page packages and public library packages.

[0056] Each page package is configured to be built and deployed independently. The common library package contains code that can be shared by multiple page packages. For example, packages / components is a UI component library and packages / utils is a utility function library. This shared code can be any software module suitable for reuse among multiple page packages, such as UI component library, utility function library, business logic library, type definition library, common style library or general service layer code.

[0057] The workspace mechanism allows page packages to directly declare their dependencies on public library packages, enabling direct linking to the local public library package code during dependency resolution without the need for publishing.

[0058] In this embodiment, one way to enable a page package to have independent build and deployment capabilities is to provide it with an independent build configuration file (such as vite.config.ts). For example, the packages / pages / bs-news page package contains the aforementioned independent configuration file and an independent dependency configuration file (package.json), allowing it to be processed independently by the build tool as a fully functional sub-project. In other embodiments, this independent build and deployment capability can also be achieved by inheriting or merging global configurations and overlaying specific override configurations, as long as the final result is to achieve the effect of independently building and deploying a single page package.

[0059] Step Two: Dynamic Discovery and Interactive Selection Steps

[0060] In response to the developer's operation of initiating aggregate debugging, the system reads and parses the workspace configuration of the single code repository, identifies the sub-packages that meet the preset conditions for independent operation as the page packages, and extracts their package names; the discovered package names are presented through an interactive interface, and the system receives the developer's selection operation for at least one page package.

[0061] In this embodiment, one way to identify sub-packages that meet preset independent running conditions is to parse the workspace definition file by calling the programming interface provided by a package management tool (such as PNPM) (e.g., the `@pnpm / workspace.find-packages` library function), and then selecting sub-packages with independent build configuration files and dependency configuration files as page packages. In other embodiments, page packages that meet the conditions can also be discovered by scanning package names according to a pre-defined directory structure or specific naming rules. The interactive interface is specifically a command-line interactive interface (e.g., implemented based on the `inquirer` library), which uses a multi-select list for developers to select page packages. In other embodiments, the interactive interface can also be a graphical user interface or a plugin interface in an integrated development environment.

[0062] Step 3: Automated Port Assignment Steps

[0063] Based on the number of selected page packages, assign a unique port number available to the current system to each page package to be launched (e.g., through the portfinder library), and establish a mapping relationship between the package name and the assigned port (e.g., {"bs-news": 3300, "bs-report": 3302}), and store this mapping relationship in the environment variables.

[0064] Step 4: Parallel Startup of Sub-services

[0065] Iterate through all selected page packages, create an independent child process for each page package (e.g., using Node.js's child_process.spawn API), pass the environment variables to the child processes, and execute the development startup commands corresponding to each page package (e.g., pnpm --filter) in parallel.<package_name> (dev); The development server within each page package reads its assigned port number from environment variables and starts a sub-service on that port.

[0066] Step 5: Aggregator Proxy Startup Steps

[0067] After all sub-services are started and accessible, a main proxy server is started, listening on a preset fixed port (e.g., port 3100). This main proxy server (e.g., implemented using the express and http-proxy-middleware libraries) creates proxy rules for each sub-service based on the mapping relationship, and forwards requests containing page packet paths on the fixed port (e.g., access to http: / / localhost:3100 / bs-news) to the independent port where the corresponding sub-service is located (e.g., http: / / localhost:3300 / bs-news). At the same time, the main proxy server generates a navigation page that centrally displays the access entry links for all started sub-services.

[0068] Through the above steps, modular organization of multi-page applications is achieved, and developers are provided with one-click, unified entry point for local aggregation debugging capabilities.

[0069] Example 2: This example provides a system for modular construction and aggregate debugging of multi-page applications. The system includes a modular organization framework and an aggregate debugging device.

[0070] Modular organizational framework

[0071] The framework is implemented based on a single codebase and workspace mechanism, and includes multiple page packages and at least one common library package.

[0072] Each page package is configured to be built and deployed independently. In this embodiment, this capability is achieved by providing each page package with an independent build configuration file (such as vite.config.ts) and dependency configuration file (package.json). For example, the packages / pages / bs-news page package contains the aforementioned independent configuration file. In other embodiments, this independent build and deployment capability can also be achieved by inheriting or merging global configurations and overlaying specific overriding configurations, as long as the final result is to achieve the effect of independently building and deploying a single page package.

[0073] Public library packages store shared code. For example, packages / components contains UI component libraries, and packages / utils contains utility function libraries. This shared code can be any software module suitable for reuse across multiple page packages, such as UI component libraries, utility function libraries, business logic libraries, type definition libraries, common style libraries, or general service layer code. Page packages declare their dependencies on public library packages through the workspace mechanism, and the build tool directly links to the corresponding local code when resolving dependencies.

[0074] Aggregation debugging device

[0075] The device operates on the aforementioned modular organizational framework and specifically includes:

[0076] Package discovery unit: used to receive the developer's operation to start aggregate debugging, read and parse the workspace configuration of a single code repository, identify the sub-packages that meet the preset conditions for independent operation as the page package, and extract their package names;

[0077] Interactive selection unit: used to present the discovered package names to the developer through an interactive interface, and to receive the developer's selection operation for at least one of the page packages;

[0078] In this embodiment, the package discovery unit identifies sub-packages that meet the conditions by parsing the workspace configuration using library functions provided by the package management tool (e.g., @pnpm / workspace.find-packages) and filtering out sub-packages with independent build configuration files (e.g., vite.config.ts) and dependency configuration files (package.json) as page packages. The interactive selection unit provides an interactive interface that is a command-line interface (e.g., implemented based on the inquirer library), presenting page package names in a multi-select list format. In other embodiments, a graphical user interface or integrated development environment plugin interface can also be used, as well as package discovery methods such as directory scanning or naming rule matching.

[0079] Port allocation unit: Used to allocate unique available port numbers based on the number of selected page packages (e.g., implemented using the portfinder library), and generate a mapping relationship between package names and port numbers (e.g., {"bs-news": 3300, "bs-report": 3302}), and store it in environment variables;

[0080] Sub-service startup unit: Used to create a child process for each selected page package (e.g., through Node.js's child_process.spawn API), passing the environment variables, and executing the development startup commands for each page package in parallel (e.g., pnpm --filter).<package_name> `dev`, so that the development server in each page package starts on the corresponding port;

[0081] Proxy service unit: After all sub-services are accessible, the main proxy server (e.g., implemented using express and http-proxy-middleware libraries) is started. This proxy server listens on a fixed port (e.g., port 3100), establishes proxy rules based on the mapping relationship, and forwards requests to different page packet paths pointing to the fixed port (e.g., access to http: / / localhost:3100 / bs-news) to the corresponding sub-services on the port (e.g., http: / / localhost:3300 / bs-news), and dynamically generates a unified navigation page for developers to access.

[0082] Example 3: This example provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps:

[0083] Build a modular organizational structure in a single codebase, enabling multiple page packages and common library packages to share code based on a workspace mechanism, with each page package configured to be built and deployed independently;

[0084] In response to the developer's operation to start aggregate debugging, the system reads and parses the workspace configuration of a single code repository, identifies sub-packages that meet the preset conditions for independent operation as page packages and extracts their package names; presents the discovered package names through an interactive interface, and receives the developer's selection operation for at least one of the page packages;

[0085] Assign unique available port numbers to each selected page package, establish a mapping relationship between package name and port and store it in environment variables;

[0086] Create a subprocess for each selected page package, execute its development startup command in parallel, and pass the environment variables to enable the development server of each page package to start on the corresponding port.

[0087] Once all sub-services are accessible, the main proxy server is started and listens on a fixed port. Requests are forwarded according to the mapping relationship, and a navigation page displaying the entry links for all sub-services is generated.

[0088] This storage medium can carry all the logic of the above methods and can be applied in the front-end development environment, significantly simplifying the modular construction and debugging process of multi-page applications.

[0089] Furthermore, the computer-readable storage medium in this embodiment can be any combination of one or more readable storage media, wherein the readable storage medium includes an electrical, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof.

[0090] In this embodiment, the identification of sub-packages that meet the preset independent running conditions can be achieved by calling library functions provided by the package management tool (e.g., @pnpm / workspace.find-packages). Specifically, this involves filtering out sub-packages that have independent build configuration files (e.g., vite.config.ts) and dependency configuration files (package.json). The interactive interface described above can be a command-line interface (e.g., implemented based on the inquirer library), presented in the form of a multi-select list. In other embodiments, other package discovery mechanisms and interactive interface forms may also be used.

[0091] Unlike existing technologies, the method, system, and medium for modular construction and aggregated debugging of multi-page applications proposed in this application enable independent construction and deployment of modules in large multi-page application projects. Through a one-click aggregated proxy debugging mechanism, the multi-service debugging process that originally required manual startup and management of multiple terminal windows has been simplified to a single interactive operation and unified entry point access. This effectively mitigates problems such as structural bloat, high module coupling, decreased development efficiency, and cumbersome local debugging configuration caused by project growth. It ensures that the development, debugging, and release processes of each page module maintain a high degree of independence and parallelism, meeting the needs of large teams for efficient collaboration and continuous delivery in multi-page application scenarios. It also makes up for the shortcomings of existing monolithic repositories, multi-repositories, and basic Monorepo solutions in terms of debugging experience, and has high application value.

[0092] It should be understood that in the various embodiments of this document, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this document.

[0093] It should also be understood that, in the embodiments herein, the term "and / or" is merely a description of the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following associated objects have an "or" relationship.

[0094] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this document.

[0095] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0096] In the embodiments provided herein, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0097] 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 units can be selected to achieve the purpose of the embodiments described herein, depending on actual needs.

[0098] Furthermore, the functional units in the various embodiments of this document can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0099] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this paper, in essence, or the part that contributes to the prior art, or all or 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 paper. 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.

[0100] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for modular construction and aggregate debugging of multi-page applications, characterized in that, Includes the following steps: Modular Organizational steps: Establish a package structure based on the workspace mechanism in a single code repository. The package structure contains multiple page packages and at least one public library package. Each page package has its own package name. Each page package is configured to be able to be built and deployed independently. The page package declares its dependency on the public library package through the workspace mechanism, so that it can directly link to the local public library package code during dependency resolution. Aggregated debugging steps: In response to the developer's operation to initiate aggregate debugging, the workspace configuration is scanned to discover all the page packages and their package names, and the developer's selection of at least one of the page packages is received through the interactive interface; based on the number of selected page packages, a unique available port number is assigned to each selected page package, and a mapping relationship between package name and port number is established; development servers for each selected page package are started in parallel, with each development server starting based on its assigned port number; after all the development servers are started and accessible, a main proxy server is started. The main proxy server listens on a fixed port, and according to the mapping relationship, it forwards access requests for different page package paths containing the selected page package name on the fixed port to the development server with the corresponding port number, and generates a unified navigation page.

2. The method for modular construction and aggregation debugging of multi-page applications according to claim 1, characterized in that: In the modular organization step: The page package represents either a standalone page or a cohesive business function module; The public library package contains code that can be shared by multiple page packages.

3. The method for modular construction and aggregation debugging of multi-page applications according to claim 1, characterized in that: In the aggregation debugging step, the scanning workspace configuration to discover all page packages and their package names further includes: The workspace configuration of the single code repository is read and parsed to identify the sub-packages that meet the preset conditions for independent operation, and their package names are extracted as the page packages.

4. The method for modular construction and aggregation debugging of multi-page applications according to claim 3, characterized in that: Receiving the developer's selection of at least one of the page packages via the interactive interface further includes: The discovered package names are presented as a multi-select list through the command-line interactive interface, and the results selected by the developer are used as the selected page packages.

5. The method for modular construction and aggregation debugging of multi-page applications according to claim 1, characterized in that: The step of assigning a unique available port number to each selected page packet and establishing a mapping relationship between packet name and port number further includes: Using a port lookup library, based on the number of selected page packets received by the interactive interface, the system dynamically obtains available, non-conflicting port numbers and stores the established mapping relationship between packet names and port numbers as a string in the environment variables of the current process.

6. The method for modular construction and aggregation debugging of multi-page applications according to claim 5, characterized in that: The parallel startup of development servers for each selected page package, each development server starting based on its assigned port number, further includes: The process iterates through the page packages selected by the developer, creates an independent child process for each selected page package using the child process creation interface, passes the environment variables to each child process, and executes the development startup commands for each page package in parallel. The development server within each page package reads its corresponding port number from the environment variables and starts the service on that port.

7. The method for modular construction and aggregation debugging of multi-page applications according to claim 1, characterized in that: The startup of a primary proxy server further includes: The main proxy server is created using a web server framework and a proxy middleware library, and a preset fixed listening port is configured for it. According to the mapping relationship between package name and port number, a proxy rule is created for the development server of each selected page package, which forwards the request path containing the corresponding package name to the independent port listened to by the development server of that page package. The main proxy server also dynamically generates an HTML navigation homepage, which centrally displays the access entry links of all launched page packages.

8. A system for modular construction and aggregate debugging of multi-page applications, characterized in that, include: A modular organization framework is used to establish a workspace-based package structure in a single codebase. The package structure contains multiple page packages and at least one common library package. Each page package has its own package name. Each page package is configured to be built and deployed independently. The page package declares its dependency on the public library package through the workspace mechanism, so that it can directly link to the corresponding local public library package code during dependency resolution; The aggregation and debugging device includes: The package discovery unit is used to receive the developer's command to start aggregate debugging, scan the workspace configuration, and discover all the page packages and their package names. An interactive selection unit is used to receive a developer's selection of at least one of the page packages via an interactive interface; The port allocation unit is used to assign a unique available port number to each selected page packet based on the number of selected page packets, and to establish a mapping relationship between packet name and port number. The sub-service startup unit is used to start the development servers of each selected page package in parallel, and each development server is started based on the port number assigned to it. The proxy service unit is used to start a main proxy server after all the development servers are started and accessible. The main proxy server listens on a fixed port and, according to the mapping relationship, forwards access requests for different page package paths containing the selected page package name on the fixed port to the development server with the corresponding port number, and generates a unified navigation page.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method for modular construction and aggregation debugging of a multi-page application as described in any one of claims 1 to 7.

Images