Multi-page application construction method and device, equipment and medium

Abstract

The invention relates to the technical field of research and development management, can be applied to business scenes of financial science and technology, medical health and the like, and discloses a multi-page application construction method and device, equipment and a medium, and the method comprises the steps: configuring a mapping relation between a template path and a script path; traversing a page module under the source file directory, and extracting a module identifier and a script path parameter; generating an entry script reference and injecting a placeholder of the template engine, and generating a page entry file; setting an entry configuration item of the construction tool and loading a module script file; executing a code compiling process, a dependency analysis process and a static resource packaging process; extracting a public dependency library of the page module and combining the public dependency library with the module script file into a public code block; and packaging the public code block and the compiled product into a deployable application package. According to the method, the mapping relation between the template entry and the script path is uniformly managed, the page entry file is automatically generated, and the construction tool entry is configured, so that the page entry configuration complexity is reduced.

Description

Technical Field

[0001] The present invention relates to the field of R&D management technology, and in particular to a method, device, equipment and storage medium for constructing a multi-page application. Background Art

[0002] In current front-end engineering practices, the multi-page application (MPA) construction model is widely used in large-scale business systems, especially in the financial technology and healthcare business fields. In the financial technology business scenario, the system is usually composed of multiple independent business modules, such as customer information management, risk assessment, contract configuration, transaction records, etc. Each module corresponds to an independent page entry, which places high demands on the flexibility and construction efficiency of multi-page configuration. Similarly, in the healthcare business field, subsystems involving patient management, testing and inspection, drug information, registration and settlement, etc., also need to be deployed and iterated in modules based on a multi-page architecture. Therefore, the flexibility and degree of automation of the construction system in terms of entry management have become important concerns.

[0003] While new build tools like Vite offer significant advantages in terms of development experience, they still have limitations in their native support for multi-page application structures. Specifically, Vite defaults to using a single index.html file as the project entry point, and the build process starts with an HTML file, resulting in weak multi-page support. When configuring multiple page entry points, developers must manually create multiple HTML files and write separate script import statements, which is not only labor-intensive but also prone to reference conflicts, path errors, and other issues.

[0004] In contrast, traditional build tools like Webpack use JavaScript files as the build entry point and support centralized definition of module entry points for multiple pages through object configuration, offering greater flexibility. However, when a project needs to switch between Webpack and Vite, or wants to support both build tools simultaneously, due to the fundamental differences in their entry point configuration mechanisms, developers often need to manually maintain two completely different entry point structures and build configurations. This not only increases maintenance costs and the complexity of the build process, but also impacts configuration reusability and build consistency across teams and projects.

[0005] Furthermore, some current Vite-based multi-page building solutions rely on static configuration or directory conventions, making them inflexible to adapt to the dynamic changes and expansion of business modules. This is especially true in scenarios where demand changes rapidly or deployment modules are frequently updated. These solutions can lead to untimely responses, error-proneness, and difficulty in unified management. This limitation is particularly pronounced in healthcare, where systems often face module adjustments due to policy changes or interface upgrades. In fintech, version iterations and compliance requirements often lead to frequent page structure adjustments, placing higher demands on the multi-entry scalability and compatibility of the building system.

[0006] In summary, existing construction tools still have shortcomings in terms of flexibility, automation, configuration compatibility, etc. in multi-page portal management, and it is difficult to meet the actual needs of unified construction of complex page structures, cross-tool compatibility and efficient configuration management in scenarios such as finance and medical care. Summary of the Invention

[0007] The main purpose of the present invention is to provide a method, device, equipment and storage medium for constructing a multi-page application, aiming to solve the technical problems in the prior art that the construction of a multi-page application requires manual maintenance of scattered entry configurations and dependencies, resulting in low development efficiency and redundant common dependencies.

[0008] To achieve the above objectives, the present invention provides a method for constructing a multi-page application, comprising:

[0009] Configure the mapping between the template path of the embedded template engine and the script path of the page module;

[0010] Traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module;

[0011] Generate a corresponding entry script reference according to the module identifier and the script path parameter, and inject the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file;

[0012] Setting an entry configuration item of a construction tool based on the page entry file, and loading the module script file in the source file directory pointed to by the entry script reference according to the entry configuration item;

[0013] Execute the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate compiled front-end code and static resources;

[0014] Extracting the common dependency library of all page modules during the dependency parsing process, and merging the common dependency library and the module script files into a common code block;

[0015] The common code block is packaged with the compiled front-end code and static resources to generate a deployable application package.

[0016] Furthermore, to achieve the above-mentioned purpose, the present invention provides a device for constructing a multi-page application, comprising:

[0017] Template mapping configuration module, used to configure the mapping relationship between the template path of the embedded template engine and the script path of the page module;

[0018] The module parameter extraction module is used to traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module;

[0019] An entry file generation module is used to generate a corresponding entry script reference according to the module identifier and the script path parameter, and inject the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file;

[0020] An entry configuration loading module, used to set the entry configuration items of the construction tool based on the page entry file, and load the module script file in the source file directory pointed to by the entry script reference according to the entry configuration items;

[0021] The compilation and packaging execution module is used to execute the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate the compiled front-end code and static resources;

[0022] A common dependency extraction module is used to extract the common dependency library of all page modules during the dependency parsing process, and merge the common dependency library and the module script file into a common code block;

[0023] The deployment package generation module is used to package the common code block with the compiled front-end code and static resources to generate a deployable application package.

[0024] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a multi-page application construction program stored in the memory and runnable on the processor. When the multi-page application construction program is executed by the processor, the steps of the multi-page application construction method described above are implemented.

[0025] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a multi-page application construction program is stored. When the multi-page application construction program is executed by a processor, the steps of the multi-page application construction method as described above are implemented.

[0026] Beneficial effects: The present invention relates to the field of R&D management technology, and can be applied to business scenarios such as financial technology and medical health. It discloses a method for constructing a multi-page application, including: configuring the mapping relationship between the template path of the embedded template engine and the script path of the page module; traversing the page modules under the source file directory, extracting the module identifier and the script path parameter; generating an entry script reference and injecting the placeholder of the template engine to generate a page entry file; setting the entry configuration item of the construction tool and loading the module script file; executing the compilation, dependency resolution and static resource packaging process of the front-end code; extracting the common dependency library of the page module and merging it with the module script file into a common code block; packaging the common code block and the compiled product into a deployable application package. The present invention automatically generates a page entry file and configures the construction tool entry by uniformly managing the mapping relationship between the template entry and the script path, so that module information can be automatically extracted and dependency processing and packaging operations can be completed during the construction of the multi-page application, thereby reducing the complexity of the page entry configuration, reducing the workload of manual maintenance, and improving the compatibility and construction efficiency in the multi-tool construction environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0028] Figure 1 A schematic diagram of an application environment of a method for constructing a multi-page application in one embodiment of the present invention;

[0029] Figure 2 This is a flow chart of an embodiment of a method for constructing a multi-page application according to the present invention;

[0030] Figure 3 A schematic diagram of functional modules of a preferred embodiment of a device for constructing a multi-page application of the present invention;

[0031] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0032] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0033] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0034] The method for constructing a multi-page application provided by the embodiment of the present invention can be applied in the following situations: Figure 1In an application environment, the user end communicates with the server end through a network. The server end can configure the mapping relationship between the template path of the embedded template engine and the script path of the page module through the user end; traverse the page modules under the source file directory, extract the module identifier and the script path parameter; generate an entry script reference and inject it into the placeholder of the template engine to generate a page entry file; set the entry configuration item of the construction tool and load the module script file; execute the compilation, dependency resolution and static resource packaging process of the front-end code; extract the common dependency library of the page module and merge it with the module script file into a common code block; package the common code block and the compiled product into a deployable application package. The present invention automatically generates a page entry file and configures the construction tool entry by uniformly managing the mapping relationship between the template entry and the script path, so that module information can be automatically extracted and dependency processing and packaging operations can be completed during the multi-page application construction process, thereby reducing the complexity of the page entry configuration, reducing the manual maintenance workload, and improving the compatibility and construction efficiency in the multi-tool construction environment. Among them, the user end can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server end can be implemented with an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific examples.

[0035] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a method for constructing a multi-page application provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0036] like Figure 2 As shown, the method for constructing a multi-page application proposed by the present invention includes the following steps:

[0037] S10, configuring a mapping relationship between the template path of the embedded template engine and the script path of the page module;

[0038] In this embodiment, configuring the mapping relationship between the template path of the embedded template engine and the script path of the page module first involves two dimensions of information structure. On the one hand, there is the template path, which refers to the location of the template file used for page entry file generation in the file system, usually in the form of a string path, which may be an absolute path or a relative path relative to the project root directory; on the other hand, there is the script path of the page module, which refers to the location of the script file in the source file directory that is actually responsible for page rendering and logic processing in the business module. An embedded template engine generally refers to a rendering engine that can dynamically embed structured data into a template, such as EJS, Handlebars, Mustache, etc. In actual applications, the injectable area is usually expressed in a predefined placeholder structure. These placeholders use a specific syntax (such as <%=script%>) to represent the fragment that will be dynamically filled by external data.

[0039] During the specific configuration process, the system will maintain a mapping relationship table, which uses the module identifier as the key to associate the corresponding template path and script path information. The purpose of this mapping relationship is to ensure that the template engine can find the corresponding template structure and its associated business logic script based on the module identifier when rendering the page entry file. In the structural design of the path, it is usually required to follow the modular directory specification. For example, each business module under the source directory should contain a main script file and a template file to facilitate automatic identification and matching. The mapping relationship can come from the configuration file, directory rules or initialization scan results. The configuration file can use JSON, YAML, JavaScript objects and other forms to declare the binding relationship between the module and the path; the directory rule is based on the idea that convention is better than configuration, and the path is automatically deduced according to the file naming and directory hierarchy; the initialization scan refers to traversing the source directory to generate a path comparison table when the system starts to support dynamic module discovery.

[0040] The mapping configuration process not only establishes a static association between the template and the business logic script, but also makes preliminary preparations for the subsequent dynamic generation of entry files, construction of entry extraction, and module packaging. During the rendering process of the embedded template engine, the path mapping results will be used to fill in the placeholders and generate the structural content of the actual page entry file, while the template path ensures that different modules can apply differentiated page layout structures, such as master-slave pages, pop-up pages, nested pages, etc. In technical implementation, the standardization and unification of paths are key links, and it is necessary to consider issues such as cross-platform compatibility of path splicing, unified processing of file system delimiters, and resolution priority of relative paths and absolute paths. In addition, it is also necessary to support an incremental update mechanism for path mapping, that is, to allow adding, deleting, or replacing modules during the development process without affecting the existing mapping structure. This dynamic response mechanism usually relies on monitoring file system change events.

[0041] In one implementation, the path mapping relationship can be automatically constructed through the initialization process. The specific process is: during the system startup phase, scan the preset module directory (such as src / modules / ), analyze each module folder, identify the template files (such as template.ejs) and main script files (such as main.js), and generate a module identifier based on the folder name, for example, user / profile generates the identifier user-profile. The identifier is then bound to its corresponding template path and script path to form a complete mapping record, which is stored in the path mapping table. The mapping table can be maintained as a JavaScript object or Map structure, and supports quick positioning of the corresponding path based on the module identifier.

[0042] In another implementation, path mapping can be established by reading a configuration manifest file (such as module.config.json). This file structure defines each module's identifier, template file path, script file path, and other content. During the initialization phase, the system reads this manifest and parses it into an in-memory mapping structure for subsequent rendering and building. This method is suitable for situations where the module structure is inconsistent or the template path does not conform to the default rules, enhancing the flexibility and controllability of path configuration.

[0043] Fuzzy matching mapping can also be combined with path regularization rules. For example, when multiple template variants exist, the best template can be selected through path rule matching, such as using different template styles for different terminals (PC / Mobile). In this case, the relationship between the module identifier and the template path is no longer a unique binding, but a polymorphic binding that is dynamically selected based on environment variables, terminal type, or parameters. This structure implements dynamic mapping decisions through policy functions or conditional expressions.

[0044] Example: In the healthcare business, for example, the registration, testing, and reporting submodules in a hospital management system each exist as page modules. The system can automatically generate page entry files for each submodule by configuring a mapping between template paths and script paths. During the registration process, when a user accesses the registration entry page, the corresponding template and script files are automatically generated through pre-configuration. The build tool eliminates the need to manually specify the HTML file entry, enabling dynamic page expansion and consistent control of the build process.

[0045] In fintech businesses, such as customer rating systems, credit review systems, and risk model management systems, each deployed as multiple page modules, utilizes a path mapping mechanism. Developers only need to maintain their respective script and template files within the module directory. During the build process, the system automatically generates page entry files containing corresponding references and uniformly injects them into the build tool configuration. This enables independent development and unified integration of page-level business modules, improving collaborative efficiency and reducing configuration conflicts. This path mapping mechanism also supports front-end architecture optimizations such as on-demand loading and dynamic routing mounting, adapting to business needs for rapid iteration and multi-terminal deployment.

[0046] By establishing a mapping relationship between template paths and module script paths, the system can dynamically generate page entry file structures, eliminating the need for manual maintenance of static HTML files and the insertion of script references in the build process. This reduces the complexity of front-end build configuration, improves the automation of template injection, and enhances the project's maintainability and module extensibility. The path mapping mechanism also supports unified abstraction and management of different business module structures, providing standardized input for subsequent entry extraction, dependency analysis, and build packaging, improving the compatibility and portability of multi-page applications across different build tools.

[0047] S20, traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module;

[0048] In this embodiment, traversing the page modules under the source file directory and extracting the module identifier and script path parameters of each page module is the prerequisite for the entire construction process. The source file directory is usually a root directory structure containing multiple business sub-modules. Each sub-module usually exists in the form of a folder, and each folder represents a page module. The traversal operation uses a recursive scanning method to access the directory and its nested structure to identify all sub-paths that may constitute the page module. In actual implementation, naming conventions or structural rules are usually set as identification standards. For example, there should be a file named main.js, index.ts or entry.jsx under the page module folder. After the system identifies the module folder that meets the conditions, it generates a module identifier from the path structure. The module identifier is usually derived from the hierarchical splicing of the folder path. For example, the path src / modules / account / report will be parsed as account-report. This identifier serves as the unique logical name of the module in the subsequent process.

[0049] The script path parameter is the physical path information used to locate the module logic entry script file in the build process, usually an absolute path or a relative path under the project root path. This path parameter can be declared through the configuration file in the module directory, such as the entry field in module.config.json, or it can automatically identify the default script file during the scanning process based on the agreed rules. After the module identifier and script path parameters are extracted, this set of information will be uniformly written into the module parameter collection. The module parameter collection is a data structure used to centrally manage the page module entry information in the build process. It can be organized in the form of an object key-value structure or a Map, with the module identifier as the key and the script path as the value. This collection provides standardized basic data support for subsequent operations such as entry script reference generation, build configuration generation, and resource dependency management.

[0050] During the processing, some edge cases must be considered. For example, some modules may lack default script files or have multiple entry candidates. In this case, the system needs to set priority rules or guide prompts. Path normalization processing must also be implemented, including cross-platform compatibility of path splicing, handling of illegal characters in paths, adaptation of path case sensitivity, and symbol standardization in path parsing. In addition, it should also have incremental synchronization capabilities, that is, when page modules are dynamically added or deleted during the development process, the module parameter set can be updated in real time to avoid problems with missing entries or redundant files during construction.

[0051] In one implementation, a recursive algorithm can be used to scan the pre-set source file root directory during system startup, traversing each subdirectory structure in turn. For each directory, a check is performed to determine whether a file named index.js, main.ts, or app.jsx exists. If so, a module identifier is generated based on the directory path structure and the file path is extracted as the script path parameter. A mapping relationship between the identifier and the corresponding path is written into the module parameter set.

[0052] Another implementation involves maintaining a module description file, such as modules.config.json or a YAML manifest, with the developer pre-installing the identifiers and path definitions for all page modules. This manifest can then be read during system initialization to generate a set of module parameters, eliminating runtime scanning overhead. In scenarios with complex module structures or a large number of modules, a caching mechanism can be introduced to index resolved module paths, accelerating recognition efficiency.

[0053] In projects that support dynamic module loading, you can also dynamically detect the addition, deletion, or movement of module folders by listening to file system events and update the module parameter set to support full perception of module entry status during build time.

[0054] Example: In a healthcare system, a patient service platform typically includes multiple independent functional modules, such as a registration portal, personal files, examination records, and online consultations. These modules correspond to different page structures and are distributed in a unified code directory. By traversing the source file directory and extracting module identifiers and script path parameters, the build process can automatically identify newly added subsystem page portals, such as remote image viewing modules or multidisciplinary consultation modules, without requiring developers to manually adjust configurations. This ensures that each module is accurately included in the build scope when it goes online, thereby ensuring the rapid responsiveness of module-level expansion and the structural consistency of the online version.

[0055] In financial business systems, a credit approval platform, for example, is typically composed of multiple front-end page modules, such as credit application, credit limit assessment, risk review, and approval feedback. These modules are independently maintained by different teams, with complex storage path structures and frequent updates. By automatically traversing the build entry directory and identifying each module's identifier and script path, the system can dynamically integrate new module page entries developed by various teams, such as adding anti-fraud analysis modules or internal scoring model management pages, reducing configuration conflicts or omissions, and ensuring that all approval process-related pages can simultaneously participate in unified build tasks in a multi-page environment, thereby improving multi-department collaboration efficiency and front-end asset management capabilities.

[0056] By automatically traversing source file directories and extracting module identifiers and script path parameters, it automates the collection of page module entry information, eliminating the manual intervention required for module entry configuration in traditional build processes. This can significantly reduce configuration costs and build failures caused by incorrect references in projects with frequently changing module structures. It also provides structured and stable input for subsequent operations such as injecting entry scripts into templates, generating build configuration items, and constructing dependency graphs, forming a closed-loop mechanism for the front-end module build process.

[0057] S30, generating a corresponding entry script reference according to the module identifier and the script path parameter, and injecting the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file;

[0058] In this embodiment, the module identifier and the script path parameter are used to generate an entry script reference, and based on the mapping relationship between the template path and the script path, the entry script reference is injected into the placeholder area of ​​the embedded template engine to generate a page entry file with module entry capabilities. The module identifier is usually a unique tag used to identify each business page module, such as "user-profile", "loan-approval", etc., which has the functions of logical separation and construction isolation. The script path parameter refers to the main entry script file path of the module, which is usually declared in the configuration file and needs to be converted into a path format recognizable by the build tool, such as the absolute path of Webpack or the relative path of Vite. The entry script reference generates a unique reference identifier that complies with the rules of the build tool from the module identifier, and is spliced ​​with the standardized path to generate a complete HTML script statement, for example <script src＝" modules user-profile index.js">< / script> .

[0059] The entry script reference injection process relies on the mapping relationship between the preset template path and the script path. The build system uses this mapping relationship to find the template path corresponding to each page module and reads the HTML template content from it. The predefined script placeholder area in the template (such as {{SCRIPTS}} or <% inject.entryScript%>) is used as an insertion point, and the constructed entry script reference statement is injected into it to form an HTML structure containing a valid entry. This structure supports path replacement, parameter parsing and other operations during the template rendering process, and finally generates a page entry file for building the entry. Each entry file is named with a module identifier and stored in a specified temporary directory (such as .temp / entry-user-profile.html) for subsequent build tools to call when setting entry configuration items.

[0060] During implementation, it is necessary to consider the differences between different build tools and ensure that the script reference format and loading strategy are consistent. The template engine can support multiple placeholders and multiple location injection strategies to adapt to the need to differentiate scripts in the head and body areas. For example, some modules in the template need to insert the main entry script into the head area for priority loading, while some modules need to lazy load business components to the end of the body. The system can specify the injection location based on module configuration or build parameters, and add attribute tags such as async and defer to adapt to different runtime environments and loading requirements.

[0061] In one implementation, the build system converts the script path of each module into a standard path based on the mapping rules between the module identifier and the template path (such as the module identifier is included in the template name), generates an entry script HTML tag, reads the corresponding template file, parses the script injection point, performs string replacement and insertion operations, and writes the result as an HTML page to a temporary build directory.

[0062] In another implementation, the system uses an engine that supports template variable binding (such as EJS, Pug, Nunjucks, etc.), encapsulates the entry script as a rendering parameter, and injects it into the template using dynamic tags. This method is suitable for building scenarios with variable templates and flexible injection locations, and facilitates handling complex structural combinations or conditional insertion logic through template syntax.

[0063] Example: In a healthcare system, such as a remote diagnosis and treatment platform, its page modules are divided into online registration, intelligent guidance, electronic prescriptions, etc., each with an independent entry point. Through this build process, the system can automatically generate the corresponding entry point file for each page, ensuring that the doctor-side and patient-side interfaces are independently configured and loaded on demand, improving service response efficiency and user experience.

[0064] In financial scenarios, such as online credit service systems, the front-end module includes sub-pages for customer information collection, credit scoring, and approval processes. The system manages the entry points of different business pages through module identifiers and script paths, automatically generates entry pages corresponding to each process node, and inserts script references in a unified format into the template. This makes the front-end construction of the overall approval process more structured, scalable, and flexible in deployment, meeting the requirements of multi-process distribution and improving maintenance efficiency.

[0065] By dynamically generating entry script references from module identifiers and script path parameters and injecting placeholders into the embedded template engine, automatic generation of entry files is achieved in multi-page build scenarios. This mechanism avoids the inefficient manual maintenance of HTML entry files and repeated editing of script tag content, improving maintainability and module independence during the build process. Especially in projects with frequent page module iterations and path structure adjustments, entry pages corresponding to each module can be automatically and synchronously generated, forming a closed-loop entry integration during the build process, ensuring that each module has a valid entry file in the build tool.

[0066] S40, setting an entry configuration item of a construction tool based on the page entry file, and loading a module script file in the source file directory pointed to by the entry script reference according to the entry configuration item;

[0067] In this embodiment, setting the entry configuration item of the build tool requires extracting the structured entry information required for the build based on the page entry file. The page entry file is an HTML file or an equivalent intermediate build file generated during the template injection phase, which contains an entry script reference characterized by a module identifier. The entry script reference corresponds to the specific module script file path in the source file directory, usually in the form of a standard relative path or an absolute path compatible with the build tool. This path is the direct basis for the build tool to load the module script.

[0068] The build tool's entry configuration item refers to a multi-entry parameter structure configured before a build task begins. In Webpack, this is typically represented as an object in the entry field, and in tools like Vite, it's represented as an input configuration. This configuration item specifies entry scripts for multiple pages, enabling the build tool to handle compilation, dependency analysis, and asset bundling for each module in parallel. Based on the entry identifiers and path mappings defined in the entry configuration item, the build tool will proactively locate and load the corresponding module script files as the starting point for building the graph.

[0069] Extracting entry declarations from page entry files typically includes entry identifiers and corresponding script paths. The system must uniformly collect, parse, and convert multiple entry files to construct a unified entry configuration object that conforms to the build tool specifications. This processing may also require format conversion, path concatenation, or alias adaptation of the path structure to ensure that the loading path fully matches the module source file structure.

[0070] Loading module script files follows the entry point configuration and is the first stage of the build process, which actually starts code compilation. The build tool automatically parses the corresponding module script file based on the path specified in the entry point configuration, entering the module dependency collection and syntax analysis phase.

[0071] In one embodiment, the system traverses all generated page entry files, reads the entry declaration items contained in the files, such as the key-value pairs defined in the meta tags, extracts the module identifier and script path mapping, and constructs the mapping relationship into an object structure compatible with the build tool, such as a configuration table with the module identifier as the key and the script path as the value.

[0072] After unified conversion, this configuration table is merged into the build tool's entry configuration object, packaged in different data structures depending on the build tool type. In Webpack, this object can be directly assigned to the entry field, while in Vite, it is passed to the input configuration item. When the build starts, the tool loads the module script file in the source file directory according to the path listed in the configuration object and connects it to the compilation process as the entry module.

[0073] In another implementation, the system can pass all page entry file paths to a plug-in mechanism, which will be responsible for parsing and setting the entry configuration. In this process, advanced configuration strategies such as path alias mapping, version isolation mechanism, or build cache control can also be introduced to adapt to the module isolation or build stability requirements of complex projects.

[0074] Example description: In a healthcare system, the construction tool can automatically identify multiple service module entrances, including electronic medical record pages, examination appointment pages, and vital sign monitoring pages, through a unified entrance configuration object. The system automatically updates the configuration and completes the construction entrance loading when the module script is updated or added, thereby maintaining the rapid response capability and structural consistency of the medical platform, and ensuring that the medical business logic still has a complete construction path under the parallel development of multiple modules.

[0075] In a financial business platform, for example, a credit card application system includes modules such as credit limit application, credit limit adjustment, credit assessment, and risk warning. During the development cycle, each module may be updated independently by different teams. By setting the entry configuration items of the build tool based on the page entry file, the entry of each module can be managed uniformly and the loading configuration can be automatically completed without manually adding paths or adjusting build rules, effectively reducing the risk of version conflicts and improving system integration efficiency and the controllability of the online rhythm.

[0076] By setting the build tool's entry configuration items based on the page entry files and loading the module script files according to the entry configuration items, we achieve automated configuration of the entry structure and script loading control in the multi-page build process. This mechanism avoids the static manual configuration issues of traditional build processes and improves the scalability, accuracy, and consistency of multi-module systems during the build phase. Especially in projects where the number of entry points changes frequently, it can effectively reduce build failures, missing entry points, or loading path conflicts, and enhance the build tool's adaptability to multi-page structures.

[0077] S50, executing the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate compiled front-end code and static resources;

[0078] In this embodiment, the module script file is the main entry file of the front-end page or component, which usually includes page rendering logic, state control, dependency introduction and resource reference. In the build process, the compilation operation is to convert the module script file into a code format that can be run in the target environment, which usually involves syntax conversion, semantic verification and compression optimization. Dependency parsing refers to the build tool identifying the dependent third-party libraries or internal modules by parsing the import statements in the module script, and building a dependency graph to ensure that the module can correctly load the resources it depends on at runtime. The static resource packaging process is a process of unified management, format optimization and naming standardization of non-code resources referenced in the module script, such as images, style sheets, font files, etc.

[0079] The compilation phase is typically performed by a compiler integrated into the build tool, such as Babel, which converts JavaScript syntax to backward compatibility with modern JavaScript. The build tool uses the module script file as the entry point, recursively traverses its dependencies, and uniformly performs code transformations. The dependency resolution mechanism relies on module import specifications (such as ESM and CommonJS). The build tool locates the specific file path based on these import instructions and organizes all dependency nodes into a graph structure to support subsequent optimization operations such as module pruning and shared dependency extraction.

[0080] During the asset packaging process, the tool extracts the paths to static assets introduced in the script via import or require methods, determines the asset type, and invokes asset processors (such as image-loader and CSS-minifier) ​​to perform transcoding or compression. Based on the build configuration, the tool generates an output path with a unique identifier, typically a hashed filename. This process not only reduces asset size and eliminates redundancy, but also supports browser caching mechanisms.

[0081] Finally, the build tool organizes and outputs the compiled front-end code and packaged static resources into the intermediate product directory in preparation for subsequent deployment or launch.

[0082] In one implementation, module script files are written in ES6+ syntax, and the system uses Babel to perform syntax conversion. The minify plugin is also enabled to perform variable compression and dead code removal. The tool then scans all import statements in the module, centrally loading third-party dependencies such as Axios and React, as well as internal common modules, and constructing a dependency graph based on the calling relationships between modules.

[0083] After parsing is complete, the system identifies the CSS files and image resources imported into the module and passes them to the resource pipeline for processing. The CSS resources are converted and compressed using the postcss plugin, while the image resources are converted using the webp compressor and have a file digest suffix added. All processed resources are uniformly named and output to the target directory, replacing the original paths in the HTML template with the new resource paths.

[0084] In another implementation, module script files can contain dynamic import statements. During parsing, the system determines whether code splitting is enabled based on the build configuration. If enabled, the system generates a separate code block for each dynamically imported module, separating it from the static dependency graph to improve first-screen load speed. The final output includes the main entry script, multiple asynchronous modules, and all static resources.

[0085] Example: In a healthcare service platform, a module like the Health Management Center typically includes multiple view components and data interface interaction logic. This module's script file, while introducing multiple submodules such as user profile query, indicator trend analysis, and physical examination report presentation, also requires loading a large number of chart libraries and style resources. Through a unified compilation and packaging process, this module and its dependent scripts and image resources are processed and output together, ensuring that health management functions are efficiently rendered and all their dependencies are correctly loaded when accessed, improving the fluidity and security of medical data visualization.

[0086] In financial risk control systems, a credit scoring page's module script files often rely on multiple algorithm modules and backend interfaces, and introduce a large number of interactive components and animation effect resources. Through the syntax compilation and dependency parsing mechanisms of this build process, algorithm dependencies can be loaded in chunks, style resources can be compressed on demand, and a set of ready-to-deploy build artifacts can be output. This improves the system's front-end responsiveness and stability under high-concurrency user access, while ensuring the maintainability and isolation of the risk control logic code structure.

[0087] By using module script files as the entry point for compilation, dependency resolution, and static resource packaging, a structurally complete and logically closed front-end build product can be efficiently generated. This process eliminates the tedious manual configuration of paths and the individual loading of resources, enabling automated and unified management of resource compilation and loading. This can effectively reduce maintenance costs, improve build speed and accuracy, and support module reuse and resource sharing under complex dependencies, particularly in large-scale multi-module projects, enhancing the robustness and scalability of the overall build system.

[0088] S60, extracting the common dependency library of all page modules during the dependency parsing process, and merging the common dependency library and the module script files into a common code block;

[0089] In this embodiment, during the dependency resolution process, the build tool generates a module dependency graph based on the import statements of each module's script file. This graph records the import paths and resource dependencies between all modules. Common dependency libraries refer to dependencies that are repeatedly introduced in multiple page modules. They typically include framework libraries, tool function libraries, style component libraries, etc., such as React, Lodash, Moment, AntDesign, etc. These dependencies are shared between modules, but the content itself does not change with the business module.

[0090] Identifying public dependencies requires traversing the entire dependency graph and counting the frequency of each dependency referenced across multiple page modules. Dependencies whose reference counts exceed a preset threshold or are present in all modules are marked as public. After identification, version consistency checks are also performed to ensure that versions of the same dependency referenced in different modules do not conflict or cause incompatibilities. If version discrepancies exist, compatibility resolution is required through methods such as version locking, aliasing, or unified dependency specifications.

[0091] After tagging and versioning common dependency libraries, the build tool physically strips these dependencies from each module's script files. Instead of repeatedly packaging them into the module's corresponding artifacts, the build tool centrally packages them into a single, independent block of common dependency code. This block is typically named with a prefix like vendors, shared, or common, and is logically associated with the corresponding module script files in subsequent build configurations through mechanisms like entry injection, dynamic loading, or a shared runtime. This type of merging doesn't involve physically merging module source files; instead, it outputs the dependency code in a unified manner and connects it to the business module at runtime through loading logic.

[0092] The resulting common code blocks usually have independent caching properties, a single-point update mechanism, and browser-level resource sharing capabilities, which can significantly reduce build redundancy and network repeated loading, and improve the overall system's build performance and loading efficiency.

[0093] In one implementation, the build tool performs a global statistics operation after the dependency graph is constructed, recording the number of times each dependent library is referenced and the reference source path. The tool has built-in rules for marking public dependencies. For example, if more than two modules are referenced or a module matches a specified list, it is considered a public dependency. The package manager is then called to resolve the version of the referenced library. If a version discrepancy is found, a warning is issued or a unified version strategy is activated to replace the dependency.

[0094] The build process then strips these common dependencies from the bundled artifacts of each module script and outputs them as separate chunk files, such as vendors.js or shared.js, to ensure they are not repeated across business modules. Each module script file automatically imports this common code chunk as a pre-dependency or automatically registers and uses it through the runtime module system.

[0095] In another embodiment, multiple intra-domain public dependency blocks can be generated according to the functional domain (such as user, order, message, etc.) to which the business module belongs, and dependency splitting can be performed according to the business isolation logic to improve the construction granularity and cache friendliness.

[0096] Example: In a healthcare service platform, various page modules, such as appointment booking, examination reports, and medication reminders, may share the same chart library, date processing function, or UI component library. By extracting these common dependencies and generating a unified vendors-medical.js file, this file can be loaded uniformly at system startup, avoiding repeated loading on every page. This improves page responsiveness and reduces bandwidth and computing pressure on the user end. This is particularly suitable for efficient rendering scenarios on mobile terminals.

[0097] In financial transaction systems, different business modules, such as loan review, risk control, and customer data, often reuse the same encryption algorithms, identity authentication components, and message notification mechanisms. Without common dependency extraction, each module might independently package the same dependencies, leading to build size bloat and loading conflicts. This mechanism generates a single finance-shared.js code block that can be shared across multiple modules, ensuring consistent dependency versions and unified cache loading, significantly improving build consistency and resource management efficiency.

[0098] By extracting the common dependency libraries of all page modules during dependency resolution and merging them into a unified common code block, we can significantly reduce build redundancy between modules, improving overall build efficiency and product structure clarity. Centralized management and independent output of common dependencies not only avoid duplicate packaging and resource conflicts, but also improve browser cache hit rates and module loading performance, significantly enhancing the maintainability and resource reuse capabilities of the front-end build system in a multi-module collaborative development environment.

[0099] S70: Package the common code block, the compiled front-end code, and static resources to generate a deployable application package.

[0100] In this embodiment, the common code blocks are packaged with the compiled front-end code and static resources to generate a deployable application package. This means that after the module script file compilation and resource packaging process is completed, the generated common code blocks are combined to perform unified resource integration and output as a final product with deployment capabilities. Common code blocks refer to shared dependency content extracted and uniformly packaged from multiple page modules, including but not limited to framework class libraries, common component functions, etc.; compiled front-end code refers to business module scripts that have undergone syntax conversion, code compression, dependency parsing, and tree shaking optimization; static resources include CSS style sheets, images, font files, icon sets, and other files. These resources usually exist in conjunction with the page module logic.

[0101] Packaging is a key task performed at the end of the build process. Its purpose is to organize the paths, structure, and output directories of the three types of products mentioned above, and generate a unified build manifest for subsequent deployment tool recognition. The packaging process not only includes moving or copying files to the target output directory, but also involves generating reference paths for scripts and resources in HTML pages, hash identifier binding, and compression archiving. A deployable application package typically includes an entry HTML file, an entry script file, business module code split as needed, common code block files, hash-named static resource files, and a build manifest or resource mapping index.

[0102] The final product meets the following requirements: complete structure, valid paths, clear resource references, closed dependencies, and deployment without external tools for reprocessing. This product can be uploaded to CDN, web servers, container image systems, or automated deployment pipelines, and has the ability to be directly put online.

[0103] In one implementation, after completing module compilation and resource packaging, the build tool invokes a build scheduler to consolidate common code blocks, the front-end code for each page module, and its associated static resources into a unified output directory. Resource paths are uniformly mapped to relative paths, and reference paths in the entry HTML file are updated synchronously to ensure valid reference relationships in the deployment environment. The tool also generates a build manifest file that records the original path, generated path, and version hash of each resource for use by the deployment platform or caching system.

[0104] In another implementation, the packaging logic can be adapted based on the target build environment (e.g., mobile, desktop, or embedded systems). For example, in a WebView container scenario, all scripts, styles, and resources can be compressed and packaged into a single HTML package for offline use. In a high-concurrency CDN deployment environment, common code blocks and static resources can be packaged separately and cached independently.

[0105] It is also possible to output multiple sub-packages based on module granularity, split different page modules into independent build subsets through dynamic routing or on-demand loading mechanisms, and trigger loading only when the corresponding page is accessed, thereby improving the first loading speed and bandwidth utilization efficiency.

[0106] Example: In a healthcare information system, such as a physical examination center's front-end system, multiple patient interaction modules are compiled and packaged separately to form multiple business submodules. Chart components and physiological indicator parsing libraries are reused to generate unified common code blocks. Through this packaging process, all module scripts, component libraries, and patient data graphics resources are integrated into a complete application package that can be directly deployed to in-hospital servers or mobile terminals, enabling rapid delivery of module expansion and consistent platform version control.

[0107] In the financial industry, the front-end of risk control platforms often involves highly sensitive components and graphical data display modules, which rely on a large number of statistical functions and visualization component libraries. After the build is complete, these common dependencies are extracted to generate a unified common code block. This is then combined with the compilation results of each approval process page module and the accompanying chart resources. This is then output as a unified deployment package through this packaging mechanism. A hash signature is added to the build manifest to meet the financial industry's compliance requirements for build file version traceability and structural integrity. This approach ensures consistency, security, and compliance in the delivery of financial system front-ends.

[0108] By packaging common code blocks with compiled front-end code and static resources to generate deployable application packages, we achieve standardized structure and centralized resource path management for build artifacts, ensuring that every resource file is properly integrated, linked, and archived before deployment, thus avoiding issues like missing files, incorrect references, or incomplete dependencies during deployment. This process improves the reliability and automation of front-end engineering output, providing a stable foundation for continuous integration and continuous deployment.

[0109] The present invention relates to the field of R&D management technology, and can be applied to business scenarios such as financial technology and medical health. A method for constructing a multi-page application is disclosed, comprising: configuring a mapping relationship between a template path of an embedded template engine and a script path of a page module; traversing the page modules under a source file directory, extracting module identifiers and script path parameters; generating an entry script reference and injecting a placeholder into the template engine to generate a page entry file; setting an entry configuration item of a construction tool and loading a module script file; executing the compilation, dependency resolution, and static resource packaging process of a front-end code; extracting a common dependency library of a page module and merging it with the module script file into a common code block; packaging the common code block and the compiled product into a deployable application package. The present invention automatically generates a page entry file and configures a construction tool entry by uniformly managing the mapping relationship between template entry and script path, so that module information can be automatically extracted and dependency processing and packaging operations can be completed during the construction of a multi-page application, thereby reducing the complexity of page entry configuration, reducing manual maintenance workload, and improving compatibility and construction efficiency in a multi-tool construction environment.

[0110] In one embodiment, the above step S20 includes:

[0111] S201, recursively scanning the subdirectory structure of the source file directory, and identifying page module folders in the subdirectory structure that comply with a preset naming strategy;

[0112] S202, generating a corresponding module identifier according to the hierarchical path of the page module folder;

[0113] S203, reading the configuration file in the page module folder and extracting the script path parameter declared in the configuration file;

[0114] S204, verifying whether the script file corresponding to the script path parameter exists and is accessible;

[0115] S205: Store the mapping relationship between the verified script path parameters and the module identifier into a module parameter set.

[0116] In this embodiment, the source file directory is the root path for storing business module code in the build process, and usually contains multiple subdirectories, each of which represents a folder for a page module. Recursive scanning refers to starting with the source file directory and entering each level of the subdirectory structure in sequence using a depth-first or breadth-first method until all subpaths are enumerated. This process does not limit the number of directory levels to ensure that module folders with different hierarchical structures in different projects can be identified.

[0117] Identifying page module folders relies on a pre-defined naming strategy, which can be a fixed prefix, suffix, or naming pattern. For example, directories prefixed with "page-" or "mod-" are considered valid page modules. This naming strategy is determined by configuration files set during project initialization or by internal build tool rules, ensuring that irrelevant subdirectories such as public components, utility methods, or static resource directories are excluded from the scanning process.

[0118] The module identifier uniquely identifies a page module. It is typically generated from the relative path of the page module folder within the source directory, using a " / " as the middle path. For example, for the directory structure src / pages / user / profile, the module identifier could be user / profile or user_profile. The generated module identifier must be unique and resolvable to avoid build conflicts and injection errors.

[0119] The configuration file is a descriptive file in the page module folder that declares the module's build entry script path. It typically takes the form of a JSON, YAML, or TS / JS object file. Reading this configuration file requires consideration of file existence and format validity. The parsed structure should contain a script path parameter field, which is used to locate the relative or absolute path of the entry script file within the current module directory.

[0120] Verifying the script path parameter refers to checking the validity of the script path declared in the configuration file to ensure that the script file pointed to by the path actually exists in the file system and has access permissions. This process may call system file APIs, such as the Node.js fs module or the operating system's file status verification interface, to determine whether the path corresponds to a valid file rather than a directory or link.

[0121] A module parameter collection is a data structure that typically stores a mapping between module identifiers and their corresponding script path parameters as key-value pairs. This is used to generate entry script references and inject configuration items during the subsequent build process. This collection must be both efficient and structurally stable to support incremental builds, module change monitoring, and automatic build configuration generation.

[0122] In one embodiment, the build tool recursively reads all subdirectory paths of the source file directory and filters out valid page module folders according to the naming strategy. For each module folder that meets the naming rules, the tool calculates its relative path and generates a module identifier, which is used as the key name for subsequent parameter storage.

[0123] After entering the module folder, the tool reads the configuration file, which may be a fixed file such as module.config.json or specified by the project configuration. After reading, the tool parses the content structure and extracts the script path parameter fields, such as entryScript or mainPath. If these fields are missing, the module is marked as abnormal.

[0124] After reading the script path parameter, the tool performs standardization and validation on the path to confirm that the file pointed to by the path exists and has read permissions. If the validation passes, the module identifier and script path parameter are written to the module parameter set to form a structured build input.

[0125] In another embodiment, redundant path matching and format diversification support for module configuration files can also be supported, such as preferentially reading module.ts and fallback to module.json to improve compatibility, and the path alias resolution mechanism can be combined to handle non-standard path references.

[0126] This embodiment automatically traverses the source file directory and extracts module identifiers and script path parameters. The construction system can realize the automated collection of page module entry information, thereby avoiding the problem of manual intervention in module entry configuration in the traditional construction process. In projects where the module structure changes frequently, it can significantly reduce configuration costs and reduce build failures caused by incorrect references. At the same time, it can provide structured and stable input for subsequent operations such as template injection, entry script generation, construction configuration item construction, and construction dependency graph, forming a closed-loop mechanism for the front-end module construction process.

[0127] In one embodiment, the above step S30 includes:

[0128] S301, generating an entry reference identifier that complies with the construction tool specification according to the module identifier;

[0129] S302, converting the script path parameter into an absolute path compatible with the construction tool;

[0130] S303, generating a complete entry script reference statement according to the entry reference identifier and the absolute path;

[0131] S304, based on the mapping relationship, matching the corresponding template path according to the script path parameter, and reading the original template content from the matched template path;

[0132] S305, parsing the position of the script placeholder in the original template content, inserting the entry script reference statement into the position of the corresponding script placeholder, and generating the modified template content;

[0133] S306, rendering the modified template content by the embedded template engine to generate final page content;

[0134] S307: Write the final page content into a temporary storage directory to generate the page entry file.

[0135] In this embodiment, the module identifier is a key parameter for distinguishing the logical structures of different page modules, and is usually automatically generated based on the relative directory structure of the page module. For example, the identifier corresponding to the business module "User Information" can be "user-profile" or its hierarchical path representation. In order to meet the entry item identification requirements of the construction tool, the module identifier needs to be mapped to an entry reference identifier that complies with the naming specification. Generally, a unique identifier is generated by replacing illegal characters (such as slashes) and adding a prefix, such as "entry_user_profile". This identifier will serve as a mark for the construction entry item to ensure that the path search and resource identification logic of the construction tool remain accurate and consistent when configuring multiple entries.

[0136] The script path parameter refers to the relative or absolute path of the module entry script, obtained from the page module configuration file. The conversion process includes path normalization, path alias resolution, and build compatibility processing. Build tools typically require the path to be absolute or in a standard path format based on the project root directory. Therefore, the original script path must be converted to a build tool-compatible absolute path to ensure correct subsequent references.

[0137] The process of generating an entry script reference statement is to combine the entry reference identifier with the absolute path to form a script reference string that conforms to HTML syntax, such as <script src＝" dist modules entry_user_profile.js">< / script>The string structure must conform to the template syntax constraints and can be correctly identified and injected by the build tool when rendering the page.

[0138] Based on the pre-configured mapping between template paths and script paths, the system matches the corresponding template path based on the script path parameters and reads the original template content from the matched template path. This mapping relationship can be established through configuration files or path rules. For example, a corresponding template structure is specified for each business module, ensuring that different pages can correctly match the template source during the structure injection phase.

[0139] The template content is an HTML file read by an embedded template engine. It contains syntax tags that define placeholders, which are used to insert dynamic content during the template rendering phase. Placeholders may be expressed as EJS syntax (such as <%=scripts%>) or custom identifiers. The purpose of parsing the placeholder position is to embed the generated script reference statement in the expected location to ensure that the script is correctly loaded on the browser side.

[0140] The rendering operation compiles the modified template content into a complete page structure through an embedded template engine. This process includes replacing placeholders, resolving variables, and validating syntax, ultimately generating an HTML page that meets the build standards. The rendered page should have correct script references, a complete structure, and high compatibility.

[0141] The generated page content is written to a temporary storage directory and used as the page entry file in the subsequent build process. This entry file must have a unique naming strategy, usually named by adding a module identifier and a timestamp or hash value, such as entry_user_profile_84f2.html, to avoid build conflicts and overwriting issues.

[0142] In one implementation, the system calls a format conversion function based on the module identifier to generate an entry reference identifier. It then uses string substitution or regular expression matching to replace directory separators with underscores and adds a build prefix. The script path parameter is then concatenated with the project root directory and a path resolution module is called to generate an absolute path, compatible with platform differences and path aliases.

[0143] After obtaining the template path, the build tool loads the original template content through a template engine such as EJS or Pug and searches for the defined script injection placeholder. After finding the script injection location through regular expressions or the template API, the generated entry script reference statement is inserted into the template structure. The updated template is cached in memory and awaits rendering.

[0144] When rendering a template, the build tool compiles the template content, including script references, with the preset variable environment to generate the final page content. This content is written to a temporary storage directory, where the path rules can be set by the build configuration to a unified naming convention or a structured path corresponding to the module identifier.

[0145] In another implementation, the template injection logic can also support multiple languages, such as automatically injecting the language resource path according to the entry reference identifier in the internationalization construction, and inserting the language package reference script through the template injection mechanism to form a language isolation entry page.

[0146] This embodiment can achieve dynamic generation of page entry files by automatically generating entry script references based on module identifiers and script path parameters and injecting placeholders into the embedded template engine, replacing the tedious manual maintenance of HTML entry files in the traditional build process. This automation mechanism reduces the cost of entry file maintenance and reduces build failures caused by manual configuration errors, while ensuring that the correspondence between pages and module scripts is stable and reliable. Temporarily generated entry files can participate in processes such as building entry configuration items, building resource injection, and building dependency tracking, further improving build efficiency and the engineering level of the build system.

[0147] In one embodiment, the above step S40 includes:

[0148] S401, parsing the entry declaration item declared in the page entry file, and extracting the mapping relationship between the entry reference identifier defined in the entry declaration item and the absolute path;

[0149] S402, converting the mapping relationship between the entry reference identifier and the absolute path into an intermediate configuration format compatible with the construction tool;

[0150] S403, merging the intermediate configuration formats corresponding to all page entry files into a unified entry configuration object of the construction tool;

[0151] S404: Convert the unified configuration object into an entry configuration item of the construction tool according to the type of the construction tool;

[0152] S405: Load the module script file in the source file directory based on the absolute path corresponding to the entry script reference in the entry configuration item.

[0153] In this embodiment, the page entry file is an intermediate HTML file generated by rendering with a template engine. Each page entry file declares an entry declaration item for building the configuration. An entry declaration item is a piece of meta information embedded in the page structure, usually annotated with a specific identification tag. For example, a meta node is embedded in the HTML header to declare the correspondence between the entry reference identifier and the script path. This declaration has the triple characteristics of parsability, build tool independence, and platform compatibility, and is the basic input for subsequent build tools to recognize multi-entry structures.

[0154] In practice, each entry declaration contains two key fields: an entry reference identifier and an absolute script path. The former is associated with the build entry's logical identifier, while the latter corresponds to the module script's physical path, forming a dual identifier for the build entry. During the extraction process, the build system needs to traverse all page entry files, locate and parse each declaration, extract the mapping between the pair, and normalize the data structure.

[0155] After extraction, the mapping is converted into an intermediate configuration format compatible with build tools. This format is an abstract, unified structure that typically uses key-value pairs to represent the correspondence between entry points and script paths. This format aims to mask differences in build tools and provide standard input for generating entry point configuration items across different build platforms (such as Webpack and Vite). This intermediate format must support mergeability, scalability, and reusability, and be capable of merging across entry points.

[0156] The intermediate configuration formats in multiple page entry files are consolidated and merged into a unified entry configuration object for the build tool. This object logically encompasses the entry reference relationships of all modules and is the core structure of the build entry phase. During the merging process, naming conflicts, redundant paths, and duplicate configurations should be avoided. Data consistency is ensured through entry identifier deduplication and path validation mechanisms.

[0157] Different build tools have different formats for expressing entry configuration items. Webpack typically uses an object structure to declare entry items, while Vite prefers an array structure or a path-based key-value mapping. Therefore, the system needs to convert the structure of the unified entry configuration object based on the build tool type to form entry configuration items in the corresponding format to meet the build tool's entry recognition requirements.

[0158] Finally, the build tool reads the generated entry configuration item and loads the module script file from the source directory based on the absolute path corresponding to the entry script reference contained therein. The module script file is the code implementation of the module logic, and its loading mechanism relies on the module loader within the build tool. This process marks the official start of the build process.

[0159] In one implementation, the entry declaration item is defined in the page entry file through a meta tag, for example:

[0160] <meta name="build-entry"

[0161] content="entry_user_profile: / src / modules / user / profile / main.js">. The build system uses regular expressions or an HTML parser to locate this tag when scanning the directory and extracts the entry reference identifier and absolute path from the content. The system organizes the extraction results into an intermediate configuration format such as {entry_user_profile:' / src / modules / user / profile / main.js'}.

[0162] In a multi-page system, different modules may use different templates to generate entry files. Therefore, the system needs to support extracting multiple declaration items from multiple entry files and merging them to form a unified structure after deduplication. The merging mechanism can implement policy control based on entry identifier sorting, absolute path verification, and configuration priority rules to avoid overwriting errors.

[0163] When switching build platforms, such as migrating from Webpack to Vite, the way build tools identify entry points changes. The system automatically adjusts the structure of the unified configuration object through build type tags, such as converting the original object format to an array format or path mapping structure to adapt to Vite's input field format requirements.

[0164] During the module script loading phase, the system calls the module loader interface inside the build tool, uses the unified entry configuration item as the loading starting point, reads and caches all module script files into the compilation cache, and prepares to enter the subsequent compilation and packaging phase.

[0165] It can also support multi-language or multi-theme construction scenarios, add language identification or theme tag fields in the entry declaration item, and the construction system dynamically adjusts the path structure according to the tag to achieve independent loading of multi-language page entries.

[0166] This embodiment automates and unifies page module entry management by extracting entry declarations from page entry files and generating entry configuration items recognizable by build tools. This solves issues such as manual entry path configuration, difficulty switching build tools, and inconsistent configuration formats in multi-page systems. This mechanism significantly improves the stability and scalability of the build process, particularly in front-end systems with a large number of modules and frequent updates, enabling the build system to adapt to cross-platform, multi-entry, and multi-module structures. It also provides structural support for module loading and dependency tracking.

[0167] In one embodiment, the above step S50 includes:

[0168] S501, performing syntax conversion and code compression on the module script file to generate an intermediate compiled code;

[0169] S502, parsing dependency import statements in the intermediate compiled code to construct a dependency graph between modules;

[0170] S503, extracting the static resource files referenced in the dependency graph, performing format optimization and hash naming on the static resource files, and generating hash-named static resource files;

[0171] S504, performing tree shaking optimization and code obfuscation processing on the intermediate compiled code to generate a compiled front-end code;

[0172] S505: Output the compiled front-end code and the hash-named static resource file to an intermediate product directory.

[0173] In this example, module script files refer to the front-end source code files used to implement the page's business logic. They are typically written in JavaScript or TypeScript and have a modular structure. Before executing the build process, these files undergo multiple stages of processing, including syntax conversion, dependency analysis, and static resource processing, to generate a final deployable front-end product.

[0174] Syntax conversion converts the next-generation syntax features (such as ES6 and ESNext) contained in module script files into standard syntax (such as ES5) executable on the target platform. This conversion is often accomplished using syntax converters such as Babel. Code compression is used to reduce file size and network transmission load. Compressors such as Terser are often used to compress redundant structures and whitespace. The resulting code is called intermediate compiled code and serves as an intermediate product in the build process.

[0175] Dependency import statement parsing uses an abstract syntax tree to analyze the module reference syntax (such as import or require statements) contained in the intermediate compiled code, thereby constructing a dependency graph between modules. This graph, with modules as nodes and dependencies as edges, clearly describes the reference relationships between modules. The accuracy of the dependency graph directly affects the rationality of subsequent resource subcontracting and optimization.

[0176] The dependency graph may contain references to static resource files, most commonly stylesheets, images, and fonts. The build process must identify the reference paths to these resources, extract them, and perform format optimization operations. Format optimization includes image format conversion (such as PNG to WebP), stylesheet compression, font subset extraction, and a hash naming strategy. This strategy appends a content hash value to the file name to generate unique and cacheable hash-named static resource files.

[0177] After the intermediate compiled code is generated, further tree shaking and code obfuscation processing of the intermediate product is an important part of improving the performance and security of the build product. Tree shaking is an optimization technology based on static syntax analysis. Its main goal is to remove variables, functions, classes and other syntax entities that are defined in the module but not actually referenced without affecting the program operation. Such unused code is usually called "dead code" during the packaging process. By analyzing the dependency graph of the module, the build tool can identify which exported members have never been referenced in any entry file and completely remove them in the final build output. This can effectively reduce the product size and shorten the page loading time.

[0178] Code obfuscation is a security enhancement measure. Its core is to transform the original module code through a series of syntax-level transformations, reducing its readability while preserving its functionality. Common obfuscation operations include, but are not limited to, minimizing and renaming variable and function names, rearranging logical structures, compressing control flow, and encrypting strings. These operations are typically accomplished by building plugins or specialized tool chains (such as Terser, UglifyJS, and SWC Obfuscator). Obfuscation aims to make the code more difficult to reverse-engineer on the client side, protecting the implementation of business logic and core algorithms from being easily cracked.

[0179] Taking the medical and health data management platform as an example, the "Patient Electronic Record Management" module in the platform contains definitions of multiple form components and data processing logic on the front end. During development, for the convenience of debugging and maintenance, a large number of test functions and unenabled input validation modules were retained in the code. After performing tree shaking optimization, the build tool recognized that these functions were not referenced by any entry point and automatically removed them from the packaged product. Subsequently, obfuscation operations such as variable name minimization, string replacement, and object structure folding were performed on the retained patient information processing functions, making the sensitive processing logic in the final packaged product difficult to understand, thereby improving data security protection capabilities.

[0180] Another example is the "Risk Control Strategy Configuration" module in the financial risk control front-end system. Its core function is to dynamically load and render a variety of conditional expressions. This module references numerous third-party logical expression libraries. Many unused logic functions are identified and removed by Tree Shaking during the build phase. Subsequently, through obfuscation, the expression generator functions in the policy configuration are converted to an unreadable, minimal form, preventing outsiders from retrieving the rule logic through a browser, thereby safeguarding the confidentiality of financial policies. This optimization mechanism effectively reduces the build size and creates a protective barrier to code security.

[0181] The final build process outputs the compiled front-end code and hash-named static resource files to an intermediate product directory. The intermediate product directory is used in subsequent stages for common dependency extraction, deployment packaging, or incremental update processing, and is the standard storage location for build outputs.

[0182] In one embodiment, the module script file is syntax-converted by the Babel tool, and the conversion target is set to ES5 to ensure compatibility with traditional browser environments. Immediately after the conversion, it is compressed by Terser to remove comments, shorten variable names, generate intermediate compiled code and write it to the memory buffer. Subsequently, the intermediate compiled code is subjected to AST analysis by a build tool plug-in (such as WebpackModuleDependency Plugin), all import statements and resource reference paths are extracted, and a module dependency graph is constructed. The resource type identification rules defined in the system configuration will filter out all resource references such as images and styles in the graph, call a dedicated resource processor (such as image-webpack-loader, postcss) to perform format conversion and compression processing, generate a hash value based on the content, and update the resource file name and path reference.

[0183] When performing a tree-shaking operation on the intermediate compiled code, the system performs static analysis on code nodes that do not form strong dependencies in the dependency graph, removing unused module code. It then invokes an obfuscation engine such as UglifyJS or SWC to perform variable rewriting and control structure reconstruction on the remaining code, outputting the final compiled front-end code.

[0184] The front-end code and the generated hash-named static resources are written together into the intermediate product directory configured by the build tool, such as the .build / cache or dist / temp directory. The directory structure is organized by module dimension to provide complete input for subsequent steps such as merging common code blocks or building deployment packages.

[0185] It can also support outputting different build versions by language region, and generate multiple product branches based on resource paths and module dependencies by language dimension to adapt to internationalization scenarios.

[0186] This embodiment implements a complete compilation, dependency resolution, and static resource packaging process for module script files, achieving standardized output from source code to an intermediate deployable structure, effectively improving the security, stability, and performance of module construction. This mechanism not only implements syntax adaptation and compression processing at the source code stage, but also constructs a dependency graph between modules at the structural level, providing support for dependency management and incremental updates. At the same time, it improves the cache efficiency of the build product through a unified hash naming strategy for static resources. The overall process forms a controllable, traceable, and scalable construction link, which helps support the continuous integration of large-scale modular systems.

[0187] In one embodiment, the above step S60 includes:

[0188] S601, traversing the dependency graph generated in the dependency resolution process, counting the dependency libraries repeatedly referenced in all page modules, and marking the repeatedly referenced dependency libraries as public dependency libraries;

[0189] S602: performing version compatibility verification on the public dependency library to select public dependency libraries that meet version constraint conditions;

[0190] S603, separating the public dependency libraries that meet the version constraint conditions from the script files of each module to generate independent public dependency code blocks;

[0191] S604, generating an independent common code block by using the dependency splitting mechanism of the construction tool to separate the common dependency code block and the stripped module script file;

[0192] S605: Add a version identifier to the common code block and store it in the build manifest.

[0193] In this embodiment, in the dependency resolution stage of the front-end build process, in order to improve the resource reuse rate and reduce the cost of repeated loading, the system traverses and analyzes the dependency graph generated during the build process to extract dependency libraries that can be used by all page modules. The dependency graph is a structured expression of module dependencies, which records reference information such as imports, exports, and call paths between modules. By counting the reference frequency of nodes in the graph, dependency libraries that are simultaneously referenced by multiple page modules can be identified. These repeatedly referenced dependencies are marked as public dependency libraries. The marking process is completed based on strategies such as whether the number of references exceeds a preset threshold or whether they exist in the paths of all modules.

[0194] After the public dependency library is identified, it is next subjected to version compatibility verification. This process is based on the dependency version requirements declared in the module script file (such as the semver semantic version range in package.json), combined with the dependency versions actually installed in the project, to calculate whether they meet the usage requirements of all references. If a dependency library that is repeatedly referenced has a version conflict, that is, the version ranges required by multiple references do not overlap, then the dependency library cannot be included in the public dependency set and must be maintained as a private dependency of the module; otherwise, it will be confirmed as a public dependency library that meets the version constraints.

[0195] After determining the set of common dependency libraries, they are stripped from each module script file to generate independent common dependency code blocks. This stripping process is typically implemented using the chunk splitting mechanism provided by the build tool, such as Webpack's splitChunks plugin, which extracts common dependencies into separate bundle files by setting cacheGroups. After stripping, each original module will no longer contain the implementation of the dependency, but will retain a reference path to the common dependency code block. The system then logically associates the common dependency code block with the stripped module script files to form a unified common code block, making it easier for the build tool to form the correct loading dependency path when generating the final product.

[0196] During the modular construction of multi-page applications, multiple page modules often reference the same dependency library. If these duplicate dependencies are not stripped, the build tool will repeatedly package these dependencies in the output of each module, resulting in serious redundancy in the final build product. This not only expands the size but also significantly reduces the browser's resource loading efficiency. Therefore, the build process needs to establish a synergistic mechanism between dependency reuse, resource redundancy, and loading optimization, that is, to handle dependencies through the method of "stripping first and then unified management." The goal of stripping is to remove duplicate dependency implementations from each module and make them independent build resources, while unified management uses the build tool to generate structured common code blocks and establish loading path relationships for each business module during the packaging phase to ensure that the product is reusable, clearly structured, and runs correctly.

[0197] The entire process typically consists of the following five stages. In the first stage, a global dependency graph is constructed by scanning dependency import statements in all module script files. The reference frequency of each dependency library is counted, and dependencies with a frequency exceeding a set threshold are marked as candidate common dependency libraries. In the second stage, version consistency checks are performed on these candidate common dependency libraries to ensure that the versions required by each module for the same dependency meet the merge conditions, thereby avoiding build anomalies caused by version conflicts. In the third stage, a dependency splitting mechanism (such as Webpack's splitChunks.cacheGroups) is configured in the build tool. Common dependencies that pass the verification are physically separated from the original module according to the rules, generating independent dependency code blocks. In the fourth stage, the original module script files retain reference paths to these common dependency code blocks, rather than directly including the dependency implementation bodies. In the fifth stage, during the generation of the final build product, the build tool automatically establishes a load path index based on the entry configuration and module dependencies, organizing the common dependency code blocks and business module code into a unified build structure. The runtime loader loads them on demand to complete the logical assembly.

[0198] This processing mechanism is the two coordinated stages of dependency optimization in the module build process: stripping solves redundancy, ensuring that the same dependency only needs to be loaded once; unified management solves loading association issues, ensuring that the module has a complete dependency environment at runtime. Stripping without establishing reference relationships will cause module loading to fail; building directly without stripping will cause modules to continue to be redundantly packaged, resulting in a chaotic structure and no optimization. Therefore, "stripping first, then unified management" is a necessary strategy for achieving module reuse and improving loading efficiency in the build process, and is also a key means of scale control and performance optimization for build products in multi-page projects.

[0199] To enhance the maintainability and version control of build artifacts, the system adds a version identifier to each common code block. This identifier is generated based on information such as the dependent library version number, build timestamp, and hash digest. This unique identification avoids browser cache conflicts and facilitates rollbacks or incremental releases. Furthermore, this common code block and its version identifier are written into the build manifest. The build manifest serves as metadata output for the build artifact, recording key information such as the build time, dependency versions, and entry path for each module. This information can be used for subsequent version audits, build tracking, and deployment verification.

[0200] Taking the mobile consultation module in the medical platform as an example, multiple pages such as medical record viewing, online prescription, and treatment records all reference the same chart drawing library and message communication library. Through this common dependency extraction mechanism, repeated references to these libraries can be automatically identified and stripped into common code blocks chart-core.js and messaging-core.js, retaining their logical reference paths in each module to avoid volume waste caused by repeated packaging. In financial services such as insurance underwriting systems, the risk rating module, rule evaluation module, and report display module all use the same mathematical operation library and data verification function library. This mechanism can form a unified dependency base between different approval process pages to ensure dependency consistency during upgrades. At the same time, the build list can be used to track the version evolution of each dependent component to reduce error rates and rollback costs.

[0201] This embodiment realizes the centralized management and unified loading of dependent resources by automatically extracting the dependency libraries that are repeatedly referenced in the page module and forming a unified common code block during the dependency resolution phase, effectively reducing the redundant content in the build product and reducing the volume expansion problem caused by the introduction of repeated dependencies. Due to the introduction of the version compatibility verification mechanism, it is ensured that the merged common dependencies can be safely used in all referenced modules, avoiding module conflicts or functional anomalies caused by version inconsistencies during the post-build runtime. At the same time, by stripping and merging, repeated dependencies are extracted from the module script file, which improves the independence of the business code and the clarity of the module boundaries, and contributes to the decoupling and maintenance of the front-end project. In the build product generation phase, the common code blocks are marked with version identification and written into the build manifest, which also enhances the traceability of the build process and the controllability of the deployment process, and provides structured data support for subsequent cache optimization, incremental release and problem backtracking, thereby forming a streamlined, efficient and maintainable front-end build dependency management mechanism.

[0202] In one embodiment, after the above step S50, the method further includes:

[0203] S506, traversing the temporary storage directory when the compilation, dependency resolution, and static resource packaging processes of the build tool are completed;

[0204] S507, matching files in the temporary storage directory that comply with the page entry file naming rules;

[0205] S508, verifying that the file is in a deletable state and is not marked as a retained file;

[0206] S509, performing a physical deletion operation on the file that is in a deletable state and is not marked as retained;

[0207] S510: Record the path and operation status of the deleted file in a cleanup log.

[0208] In this embodiment, after completing the front-end code build process, clearing the temporarily generated page entry files is a key operation to maintain the cleanliness of the output directory and the controllability of resources. This process is first triggered by the build tool lifecycle event, and the cleanup process is started after the compilation, dependency resolution, and resource packaging steps are all completed. At this time, the system will traverse the temporary storage directory defined in the build phase. This directory is usually specified by the build tool configuration item, has an independent path structure, and is dedicated to caching intermediate build files.

[0209] During the traversal process, naming rule matching logic must be executed. This matching method generally uses file name patterns to identify whether a file belongs to a page entry file. For example, this method uses a uniform prefix, includes a module identifier, and includes an entry tag. Naming rules should be unique and recognizable. Common rules include entry-module identifier-[hash].html. Only when the file name matches the rule will the next round of judgment be entered.

[0210] After the match is completed, the deletability check is performed. The deletability check combines two conditions: one is the lock status reported by the system file interface, and the other is whether there is a retention flag. The lock status is achieved by attempting to access the file resource to obtain an exclusive handle or judging the file descriptor status. Common methods include using fs.open to try to open the file in write mode, or using fs.access to determine whether it is occupied by the operating system. The retention flag can be identified through the file name suffix (such as .keep), file meta information, or the retention list registered in the build configuration.

[0211] After determining that the target file meets the deletion criteria, immediately invoke the operating system's file deletion instructions to complete the physical cleanup. File deletion should be an atomic operation, combined with exception handling to prevent build interruptions due to non-existent paths, restricted permissions, or concurrent reads and writes. File deletion operations must be completed while maintaining file system synchronization, ensuring that cleanup operations are decoupled from the build process.

[0212] After the cleanup is complete, a deletion log is generated. The log should include the file path, deletion timestamp, deletion result, and exception information (if any). This log can be written to the build log system or a separate cleanup log file for deployment verification, backtracking analysis, or build result validation. The logging mechanism should be consistent with the build tool's main logging system to avoid inconsistent output structure that can make parsing difficult.

[0213] This cleanup mechanism forms a closed loop for the entire build process, from page entry generation to compilation, packaging, and cleanup. Each intermediate build file has a complete lifecycle definition and operation path, preventing redundant resources from lingering in deployment packages or being mistakenly identified as valid artifacts, ensuring the controllability of the front-end build process and the stability of the results.

[0214] Example: In a multi-business approval system in the financial sector, such as a credit review platform for corporate loan applications, multiple page modules, including initial review, re-review, risk control modeling, and decision output, are typically developed and deployed independently by different front-end engineers. The system needs to support dynamic module expansion and independent debugging. By configuring the mapping between the embedded template engine's template path and the module script path, the system automatically binds each approval page's structured template to its corresponding business logic script. The platform then recursively scans the source file directory to identify newly added approval modules, such as the newly added risk scoring page, and extracts their module identifiers and script paths, preventing manual configuration errors. Based on the module identifiers, an entry script reference is generated and dynamically injected into the corresponding placeholder in the template engine, generating page entry files that can be used for multiple build targets. The build tool loads these page entry files, parses the entry declarations, and converts them into a standardized entry configuration object, compatible with the current build system (such as Vite or Webpack), enabling independent or batch builds of multiple approval modules. During the compilation process, the build system automatically performs syntax conversion and module compression, handles dependencies within the business logic, extracts static resources such as chart libraries and authentication SDKs, and completes format standardization and hash naming. When multiple modules repeatedly reference dependencies such as echarts and moment, the system separates them into unified public dependencies during the build process and generates shared common code blocks through chunking for reuse across business pages. Finally, all module scripts and resources are compiled and packaged to generate the deployment files for the financial approval system. After the build process is complete, the system automatically clears temporary page entry files generated during the build and records a cleanup log, improving the traceability of the build process and the cleanliness of the output directory.

[0215] In healthcare scenarios, for example, building a comprehensive health management platform encompassing modules such as physical exam appointments, post-exam reports, remote consultations, and medication reminders requires a flexible, efficient, and module-level extensibility build process. The system first establishes rules based on the mapping of template paths to script paths, statically associating EJS templates, such as those for the "remote consultation page," with their corresponding logic scripts. By traversing the source code directory containing each medical service page, the system automatically identifies newly added modules, such as the "AI Doctor Evaluation" module, and extracts its module identifier and script path parameters. Subsequently, a script reference statement is generated using the module identifier and inserted into the template, outputting the entry HTML file for the build. The build system reads this entry file, identifies its declarations, and converts them into standard entry configuration objects to drive front-end packaging. The build process converts the logic scripts in modules such as the "post-exam report" module into compatible code, extracts a large number of static files, such as electronic medical record templates and medical image resources, and packages and names them. For common dependencies reused across multiple pages, such as medical computing libraries and identity authentication service SDKs, the system automatically analyzes and separates them into chunks using the dependency graph, generating independent common code blocks to support reuse across multiple modules. Ultimately, the system outputs the deployment artifacts for the health platform's front-end applications. After the build is complete, the platform automatically clears all temporary entry files generated during the build process and logs the cleanup details to ensure the security and consistency of the deployed files.

[0216] This embodiment can effectively remove temporary page entry files generated during the construction process through the automatic cleanup mechanism after the construction is completed, and avoid mixing invalid script entries or script entries during the debugging process into the construction product, thereby improving the standardization of the construction output and the consistency of deployment. This process relies on a dynamic judgment mechanism for the file lock status and retention mark to ensure the security of the deletion operation and avoid accidental deletion of key files. In a construction system with dynamic loading of multiple modules, especially in systems with highly dynamic front-end page structures such as those in the medical health and financial fields, this mechanism can reduce redundant resources introduced during the construction process, reduce deployment risks, and improve the closed-loop automation level of the construction process. Ultimately, through a consistent cleanup strategy after the construction is completed, automatic management of the life cycle of intermediate entry files is achieved to avoid long-term accumulation and build pollution and deployment errors.

[0217] In one embodiment, a device for constructing a multi-page application is provided, and the device for constructing a multi-page application corresponds one-to-one to the method for constructing a multi-page application in the above embodiment. Figure 3 , Figure 3This is a functional module diagram of a preferred embodiment of the multi-page application construction device of the present invention. It includes a template mapping configuration module 10, a module parameter extraction module 20, an entry file generation module 30, an entry configuration loading module 40, a compilation and packaging execution module 50, a public dependency extraction module 60, and a deployment package generation module 70. Each functional module is described in detail below:

[0218] The template mapping configuration module 10 is used to configure the mapping relationship between the template path of the embedded template engine and the script path of the page module;

[0219] The module parameter extraction module 20 is used to traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module;

[0220] An entry file generation module 30 is configured to generate a corresponding entry script reference according to the module identifier and the script path parameter, and inject the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file;

[0221] An entry configuration loading module 40 is used to set the entry configuration items of the construction tool based on the page entry file, and load the module script file in the source file directory pointed to by the entry script reference according to the entry configuration items;

[0222] The compilation and packaging execution module 50 is used to execute the front-end code compilation, dependency analysis and static resource packaging process based on the module script file to generate the compiled front-end code and static resources;

[0223] A common dependency extraction module 60 is used to extract the common dependency library of all page modules during the dependency parsing process, and merge the common dependency library and the module script files into a common code block;

[0224] The deployment package generation module 70 is used to package the common code block with the compiled front-end code and static resources to generate a deployable application package.

[0225] In one embodiment, the module parameter extraction module 20 is specifically configured to:

[0226] Recursively scan the subdirectory structure of the source file directory and identify page module folders in the subdirectory structure that comply with a preset naming strategy;

[0227] Generate a corresponding module identifier according to the hierarchical path of the page module folder;

[0228] Read the configuration file in the page module folder and extract the script path parameters declared in the configuration file;

[0229] Verify that the script file corresponding to the script path parameter exists and is accessible;

[0230] The mapping relationship between the verified script path parameters and the module identifier is stored in the module parameter set.

[0231] In one embodiment, the entry file generation module 30 is specifically configured to:

[0232] Generate an entry reference identifier that complies with the construction tool specification according to the module identifier;

[0233] Convert the script path parameter to an absolute path compatible with the build tool;

[0234] Generate a complete entry script reference statement according to the entry reference identifier and the absolute path;

[0235] Based on the mapping relationship, matching the corresponding template path according to the script path parameter, and reading the original template content from the matched template path;

[0236] Parsing the position of the script placeholder in the original template content, inserting the entry script reference statement into the position of the corresponding script placeholder to generate the modified template content;

[0237] Rendering the modified template content by the embedded template engine to generate final page content;

[0238] The final page content is written into a temporary storage directory to generate the page entry file.

[0239] In one embodiment, the entry configuration loading module 40 is specifically configured to:

[0240] Parsing the entry declaration item declared in the page entry file, and extracting the mapping relationship between the entry reference identifier defined in the entry declaration item and the absolute path;

[0241] Converting the mapping relationship between the entry reference identifier and the absolute path into an intermediate configuration format compatible with the build tool;

[0242] Merge the intermediate configuration formats corresponding to all page entry files into the unified entry configuration object of the build tool;

[0243] According to the type of the construction tool, converting the unified configuration object into an entry configuration item of the construction tool;

[0244] Based on the absolute path corresponding to the entry script reference in the entry configuration item, load the module script file in the source file directory.

[0245] In one embodiment, the compiling and packaging execution module 50 is specifically configured to:

[0246] Performing syntax conversion and code compression on the module script file to generate an intermediate compiled code;

[0247] Parsing dependency import statements in the intermediate compiled code to construct a dependency graph between modules;

[0248] Extracting the static resource files referenced in the dependency graph, performing format optimization and hash naming on the static resource files, and generating hash-named static resource files;

[0249] Perform tree shaking optimization and code obfuscation on the intermediate compiled code to generate compiled front-end code;

[0250] Output the compiled front-end code and the hash-named static resource files to the intermediate product directory.

[0251] In one embodiment, the common dependency extraction module 60 is specifically configured to:

[0252] Traverse the dependency graph generated during the dependency resolution process, count the dependency libraries that are repeatedly referenced in all page modules, and mark the repeatedly referenced dependency libraries as public dependency libraries;

[0253] Performing version compatibility verification on the public dependency library to select public dependency libraries that meet version constraint conditions;

[0254] Remove the public dependency libraries that meet the version constraints from each module script file to generate independent public dependency code blocks;

[0255] The common dependency code block and the stripped module script file are used to generate an independent common code block through the dependency splitting mechanism of the construction tool;

[0256] A version identifier is added to the common code block and stored in the build manifest.

[0257] In one embodiment, the compiling and packaging execution module 50 is specifically configured to:

[0258] At the end of the compilation, dependency resolution, and static resource packaging process of the build tool, traverse the temporary storage directory;

[0259] Match files in the temporary storage directory that conform to the page entry file naming rules;

[0260] Verifying that the file is in a deletable state and is not marked as a retained file;

[0261] Performing a physical deletion operation on the file that is in a deletable state and is not marked as retained;

[0262] The paths and operation status of deleted files are recorded in the cleanup log.

[0263] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the server side of a method for constructing a multi-page application.

[0264] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a method for constructing a multi-page application.

[0265] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0266] Configure the mapping between the template path of the embedded template engine and the script path of the page module;

[0267] Traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module;

[0268] Generate a corresponding entry script reference according to the module identifier and the script path parameter, and inject the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file;

[0269] Setting an entry configuration item of a construction tool based on the page entry file, and loading the module script file in the source file directory pointed to by the entry script reference according to the entry configuration item;

[0270] Execute the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate compiled front-end code and static resources;

[0271] Extracting the common dependency library of all page modules during the dependency parsing process, and merging the common dependency library and the module script files into a common code block;

[0272] The common code block is packaged with the compiled front-end code and static resources to generate a deployable application package.

[0273] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0274] Configure the mapping between the template path of the embedded template engine and the script path of the page module;

[0275] Traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module;

[0276] Generate a corresponding entry script reference according to the module identifier and the script path parameter, and inject the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file;

[0277] Setting an entry configuration item of a construction tool based on the page entry file, and loading the module script file in the source file directory pointed to by the entry script reference according to the entry configuration item;

[0278] Execute the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate compiled front-end code and static resources;

[0279] Extracting the common dependency library of all page modules during the dependency parsing process, and merging the common dependency library and the module script files into a common code block;

[0280] The common code block is packaged with the compiled front-end code and static resources to generate a deployable application package.

[0281] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0282] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0283] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0284] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A method for constructing a multi-page application, characterized in that: The following steps are involved: Configure the mapping between the template path of the embedded template engine and the script path of the page module; Traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module; Generate a corresponding entry script reference according to the module identifier and the script path parameter, and inject the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file; Setting an entry configuration item of a construction tool based on the page entry file, and loading the module script file in the source file directory pointed to by the entry script reference according to the entry configuration item; Execute the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate compiled front-end code and static resources; Extracting the common dependency library of all page modules during the dependency parsing process, and merging the common dependency library and the module script files into a common code block; The common code block is packaged with the compiled front-end code and static resources to generate a deployable application package.

2. The method for constructing a multi-page application according to claim 1, wherein: Traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module, including: Recursively scan the subdirectory structure of the source file directory and identify page module folders in the subdirectory structure that comply with a preset naming strategy; Generate a corresponding module identifier according to the hierarchical path of the page module folder; Read the configuration file in the page module folder and extract the script path parameters declared in the configuration file; Verify that the script file corresponding to the script path parameter exists and is accessible; The mapping relationship between the verified script path parameters and the module identifier is stored in the module parameter set.

3. The method for constructing a multi-page application according to claim 1, wherein: Generate a corresponding entry script reference according to the module identifier and the script path parameter, and inject the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file, including: Generate an entry reference identifier that complies with the construction tool specification according to the module identifier; Convert the script path parameter to an absolute path compatible with the build tool; Generate a complete entry script reference statement according to the entry reference identifier and the absolute path; Based on the mapping relationship, matching the corresponding template path according to the script path parameter, and reading the original template content from the matched template path; Parsing the position of the script placeholder in the original template content, inserting the entry script reference statement into the position of the corresponding script placeholder to generate the modified template content; Rendering the modified template content by the embedded template engine to generate final page content; The final page content is written into a temporary storage directory to generate the page entry file.

4. The method for constructing a multi-page application according to claim 1, wherein: Setting the entry configuration item of the construction tool based on the page entry file, and loading the module script file in the source file directory pointed to by the entry script reference according to the entry configuration item, including: Parsing the entry declaration item declared in the page entry file, and extracting the mapping relationship between the entry reference identifier defined in the entry declaration item and the absolute path; Converting the mapping relationship between the entry reference identifier and the absolute path into an intermediate configuration format compatible with the build tool; Merge the intermediate configuration formats corresponding to all page entry files into the unified entry configuration object of the build tool; According to the type of the construction tool, converting the unified configuration object into an entry configuration item of the construction tool; Based on the absolute path corresponding to the entry script reference in the entry configuration item, load the module script file in the source file directory.

5. The method for constructing a multi-page application according to claim 1, wherein: Execute the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate compiled front-end code and static resources, including: Performing syntax conversion and code compression on the module script file to generate an intermediate compiled code; Parsing dependency import statements in the intermediate compiled code to construct a dependency graph between modules; Extracting the static resource files referenced in the dependency graph, performing format optimization and hash naming on the static resource files, and generating hash-named static resource files; Perform tree shaking optimization and code obfuscation on the intermediate compiled code to generate compiled front-end code; Output the compiled front-end code and the hash-named static resource files to the intermediate product directory.

6. The method for constructing a multi-page application according to claim 1, wherein: During the dependency parsing process, the common dependency library of all page modules is extracted, and the common dependency library and the module script files are merged into a common code block, including: Traverse the dependency graph generated during the dependency resolution process, count the dependency libraries that are repeatedly referenced in all page modules, and mark the repeatedly referenced dependency libraries as public dependency libraries; Performing version compatibility verification on the public dependency library to select public dependency libraries that meet version constraint conditions; Remove the public dependency libraries that meet the version constraints from each module script file to generate independent public dependency code blocks; The common dependency code block and the stripped module script file are used to generate an independent common code block through the dependency splitting mechanism of the construction tool; A version identifier is added to the common code block and stored in the build manifest.

7. The method for constructing a multi-page application according to claim 1, wherein: After executing the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate the compiled front-end code and static resources, it also includes: At the end of the compilation, dependency resolution, and static resource packaging process of the build tool, traverse the temporary storage directory; Match files in the temporary storage directory that conform to the page entry file naming rules; Verifying that the file is in a deletable state and is not marked as a retained file; Performing a physical deletion operation on the file that is in a deletable state and is not marked as retained; The paths and operation status of deleted files are recorded in the cleanup log.

8. A device for constructing a multi-page application, characterized in that: The multi-page application construction device includes: Template mapping configuration module, used to configure the mapping relationship between the template path of the embedded template engine and the script path of the page module; The module parameter extraction module is used to traverse the page modules under the source file directory and extract the module identifier and script path parameters of each page module; An entry file generation module is used to generate a corresponding entry script reference according to the module identifier and the script path parameter, and inject the entry script reference into the placeholder of the embedded template engine based on the mapping relationship to generate a page entry file; An entry configuration loading module, used to set the entry configuration items of the construction tool based on the page entry file, and load the module script file in the source file directory pointed to by the entry script reference according to the entry configuration items; The compilation and packaging execution module is used to execute the front-end code compilation, dependency parsing and static resource packaging process based on the module script file to generate the compiled front-end code and static resources; A common dependency extraction module is used to extract the common dependency library of all page modules during the dependency parsing process, and merge the common dependency library and the module script file into a common code block; The deployment package generation module is used to package the common code block with the compiled front-end code and static resources to generate a deployable application package.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a multi-page application construction program stored in the memory and capable of running on the processor. When the multi-page application construction program is executed by the processor, the steps of the multi-page application construction method described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores a multi-page application construction program, and when the multi-page application construction program is executed by the processor, the steps of the multi-page application construction method according to any one of claims 1 to 7 are implemented.

Images