Method for upgrading multi-lateral electronic banking front-end project

Abstract

The application discloses a multi-legal person-based front-end project upgrading method for electronic banking, adds a Vue3 framework based on a Vite scaffold, and automatically loads multi-environment variables through an environment file and a build command; a page entry and a start parameter are declared in a centralized configuration file, and the start parameter is converted into a virtual multi-page; in a configuration analysis stage, a corresponding legal person configuration is obtained by using a Node.js API through a self-defined plug-in, and the corresponding legal person configuration is covered, so that multi-legal person automatic switching is realized; in a build completion stage, page configuration is traversed to generate a metadata file for reading by a native terminal; project dependencies are cleaned and upgraded, obsolete build tools are removed, and routing, state management and a UI library are upgraded to versions adapted to the Vue3; a volume warning threshold is set, and esbuild pre-packaging based on Go language integrated by Vite is used. The application realizes flexible analysis of multi-legal person configuration, significantly reduces the packaging failure rate and memory overhead, and improves the building efficiency and user experience.

Description

Technical Field

[0001] This invention belongs to the field of front-end engineering technology for electronic banking, and provides a method for upgrading electronic banking front-end projects based on multiple legal entities in multi-legal entity business scenarios. Background Technology

[0002] With the continuous development of multi-legal entity business in e-banking, the number of business modules in the mobile e-banking platform (including personal and corporate mobile banking) is increasing, and the code size is also expanding accordingly. The existing mobile e-banking project is developed based on the Alibaba Kylin framework. The Kylin framework encapsulates the underlying bundling tool Webpack, loading legal entity configurations and other related resources during project startup, and generating corresponding static files and route files based on page configurations during the bundling and deployment phase, while automatically applying relevant optimization configurations.

[0003] However, the Alibaba Kylin framework ceased maintenance on December 31, 2023, leading to the following major issues in practical applications: 1. Outdated technology stack, resulting in low build efficiency. The Webpack version integrated with the Kylin framework is version 1.15, released in 2016. This version is too old, only compatible with earlier versions of Node.js, resulting in very slow project execution speed and hot reloading (HMR) response speed, which seriously affects development efficiency and user experience.

[0004] 2. Restricted Installation and Use of Mainstream Middleware: Due to the low version of the underlying packaging tool, the Node.js version on which the relevant plugins depend is also limited, which makes it impossible to install, upgrade or use some mainstream middleware normally, greatly restricting the update of the technology stack and the expansion of functions.

[0005] 3. Insufficient page performance and build reliability First, the existing development framework is no longer maintained, making performance optimizations and security updates unavailable. Second, the selection of some middleware is inappropriate, further impacting page loading and runtime performance. In terms of packaging and deployment, the probability of build failure is high. Furthermore, the compilation process is handled by a single-threaded compiler, resulting in significant time consumption and overall low build performance. This performance degradation is particularly pronounced in multi-entity business scenarios with a large number of pages, leading to significantly higher memory usage and making it difficult to meet the engineering requirements of large-scale projects.

[0006] The aforementioned issues combined result in existing front-end engineering solutions failing to adequately support the continuous iteration and large-scale development of multi-legal entity e-banking mobile applications in terms of development efficiency, runtime performance, and build reliability. Therefore, there is an urgent need for an upgrade method for multi-legal entity e-banking front-end projects to address problems such as outdated technology stacks due to framework discontinuation, outdated build tool versions, limited middleware installation and usage, and insufficient page performance and build reliability. Summary of the Invention

[0007] The summary section of this application is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0008] To address the shortcomings of existing technologies, such as outdated technology stacks, limited middleware usage, low page performance, and high deployment failure rates, this invention aims to provide a more universal and high-performance front-end engineering upgrade method that supports multiple legal entities while maintaining the existing design framework. This method aims to solve problems encountered in the development environment and deployment stages of mobile banking applications, improve development efficiency, build speed, and page response speed, eliminate build failures, and support mainstream front-end runtime environments. This resolves the problems mentioned in the background section.

[0009] To achieve the above objectives, the present invention provides the following technical solution: As a first aspect of this application, the present invention discloses a method for upgrading an electronic banking front-end project based on multiple legal entities, specifically including the following steps: Step S1: Based on the official Vite scaffolding, add the Vue3 development framework to generate the basic framework structure, add environment files to the Vite configuration file and automatically load the corresponding environment variables through the mode parameters of the build command, and obtain the corresponding legal entity configuration from the full legal entity configuration library through the legal entity identifier to override the default configuration. Step S2: Configure the entry path and startup parameters of each business page independently in the centralized page configuration file, convert the page configuration into the standard format required by the virtual multi-page plugin in the Vite configuration, and automatically generate the virtual HTML entry file required by the multi-page application. Step S3: During the build phase, the legal entity identifier in the environment variable is read through the configuration parsing hook of the custom plugin, and the legal entity path is parsed from the full legal entity configuration library using the Node.js API to obtain the corresponding legal entity configuration information and overwrite the default configuration. Step S4: In the hook for completing the construction of the custom plugin, the startup parameters are standardized by traversing the centralized page configuration file, and a metadata file containing the application name and all page information is generated by combining the application identifier for the native client to read. Step S5: Clean up and upgrade project dependencies, remove build tools and code inspection packages related to obsolete solutions, upgrade front-end routing, state management, UI component library and style preprocessor to versions adapted to the Vue3 ecosystem, and replace the original test toolchain with a new test framework to complete the build toolchain. Step S6: Based on the toolchain upgraded in step S5, set a volume warning threshold in the build configuration, use custom sub-packaging rules to split dependencies into independent resource packages by function, and use a pre-packaging tool implemented based on a concurrent language for processing.

[0010] Preferably, in step S1, the environment files include development environment files, testing environment files, and production environment files corresponding to the development environment, testing environment, and production environment, respectively; the environment files are named according to the ".env.environment_name" rule, and the environment name corresponds to the mode parameter value in the build command; each of the environment files defines environment variables used to represent the workspace, legal entity, routing base path, and interface prefix, and the environment variables all begin with "VITE_"; the build mode is specified by configuring the "vite build --mode environment_name" command in the package.json script, so that Vite automatically loads the environment variables in the environment file with the corresponding environment name when executing the build.

[0011] Preferably, in step S1, the environment file supports configurations for multiple legal entities, including a global package and a Venus package; the global package is used to output versioned public static resource addresses based on the legal entity identifier and workspace, and the public static resources are directly imported into the page in the form of online URLs and do not participate in business packaging; the Venus package is a full legal entity configuration library, which stores the configurations of each legal entity in a flat manner according to the legal entity identifier.

[0012] Preferably, in step S2, the entry path and startup parameters of each business page are centralized in the src / pages-config.js file. The configuration items of each page include at least the entry path and startup parameters, and the startup parameters include a default title and permission identifier. During the conversion, all page key names in the centralized page configuration file are traversed to generate a standardized object array containing page name, output file name, entry path and title data for each page. This array is used as the configuration input of the virtual multi-page plugin to generate a virtual HTML entry file. During the development phase, the business entry file is injected into the template in memory through the template engine of the virtual multi-page plugin to assemble the complete page. The assembled page is only written to disk during the construction phase.

[0013] Preferably, in step S3, the configuration resolution hook is the `configResolved` hook function. The custom plugin reads the legal entity identifier from the environment variables through the `configResolved` hook function, and uses the Node.js file system API to override the default configuration with the legal entity configuration corresponding to the legal entity identifier. This further includes the following steps: The Vite plugin's configResolved hook function reads the legal entity identifier and workspace information from environment variables; Based on the legal entity identifier, locate and parse the corresponding complete legal entity configuration from the Venus package in the public configuration library; use the Node.js file system API to delete the default legal entity configuration directory; Copy the current legal entity configuration to the default legal entity configuration directory, and automatically load the switched legal entity configuration during subsequent builds or runtime.

[0014] Preferably, in step S4, the build completion hook is the closeBundle hook function. The custom plugin generates metadata files through the closeBundle hook function. In the closeBundle hook function, the centralized page configuration files are read, the startup parameters of each page are traversed and normalized, and the readTitle is converted into a boolean value to determine the page's publicness and role permissions. Then, the application name and application unique identifier appID obtained from package.json are combined to form an output object containing the application name and all page configurations. Finally, write it synchronously to the meta.json file in the project root directory through writeFileSync. The meta.json file is only generated during production builds and serves as a page configuration list delivered by the front end to the native end, allowing the native application to parse startup parameters and control the UI behavior of the title bar and back button when navigating to a page.

[0015] Preferably, in step S5, the cleanup and upgrade of project dependencies specifically includes: Remove build tools and their dependencies associated with the old build scheme; Remove the existing code inspection tools and their plugin packages, and introduce new code inspection tools based on Rust or Go as replacements; Remove the original testing framework and its ecosystem dependencies, and introduce a testing framework adapted to the Vite ecosystem as a replacement; Upgrade the front-end routing library to a version compatible with Vue 3, migrate the state management library to Pinia compatible with Vue 3, and replace the UI component library with a component library compatible with Vue 3.

[0016] Preferably, in step S6, the volume warning threshold is set to 500KB, and the dependencies in node_modules are split into three independent resource packages according to the core framework, interface component library, and tool library using a custom splitting rule. If the package size still exceeds the volume warning threshold after splitting, a rule is added to advancedChunks for secondary splitting, and each file is controlled within the volume warning threshold through repeated packaging and verification. Furthermore, esbuild, implemented in Go, is used for pre-packaging to ensure build speed and stability.

[0017] As a second aspect of this application, the present invention also discloses an electronic device, comprising: At least one processor, and a memory communicatively connected to said at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed, enable the at least one processor to perform the steps of the above-described method for upgrading the front-end project of an electronic bank based on multiple legal entities.

[0018] As a third aspect of this application, the present invention also discloses a computer storage medium storing a computer program thereon, characterized in that the computer program, when executed by a processor, implements the steps of the above-described method for upgrading the front-end project of an electronic bank based on multiple legal entities.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention discloses a method for upgrading a front-end project of an e-banking system based on multiple legal entities. First, a basic framework structure is generated by adding the Vue3 development framework to the Vite official scaffolding. An environment file is added to the Vite configuration file, and the corresponding environment variables are automatically loaded through the mode parameters of the build command. The corresponding legal entity configuration is obtained from the full legal entity configuration library using the legal entity identifier to override the default configuration. The entry path and startup parameters of each business page are independently configured in the centralized page configuration file. The page configuration is converted into the standard format required by the virtual multi-page plugin in the Vite configuration, and the virtual HTML entry file required by the multi-page application is automatically generated. During the build phase, the legal entity identifier in the environment variables is read through the configuration parsing hook of the custom plugin. The legal entity path is parsed from the full legal entity configuration library using the Node.js API to obtain the corresponding legal entity configuration information and override the default configuration. In the custom plugin's build completion hook, the startup parameters are standardized by traversing the centralized page configuration file, and a metadata file containing the application name and all page information is generated by combining the application identifier for native client reading and use. This invention cleans up and upgrades project dependencies, removing build tools and code inspection packages associated with outdated solutions. It upgrades the front-end routing, state management, UI component library, and style preprocessor to versions compatible with the Vue 3 ecosystem, and replaces the original testing toolchain with a new testing framework to complete the build toolchain. Based on the upgraded toolchain, it sets a size warning threshold in the build configuration, uses custom splitting rules to split dependencies into independent resource packages by function, and utilizes a pre-packaging tool implemented in a concurrent language for processing. This invention replaces the old Webpack with the Vite build tool and its integrated Go-based esbuild pre-packaging tool, significantly improving pre-build efficiency, greatly reducing memory usage, and significantly accelerating hot updates during development. By replacing the single-threaded build tool with a pre-packaging tool based on a concurrent language, and combining dependency cleanup and middleware upgrades, it effectively solves problems such as high deployment failure rates and memory overflow. By upgrading the core framework to Vue 3, migrating state management to Pinia, and upgrading the routing middleware to vue-router@5, it improves page rendering performance and runtime response speed, enhancing the user experience. The upgraded project is fully compatible with the Vue 3 ecosystem, eliminating dependencies on outdated ones and facilitating future upgrades and maintenance. While maintaining the existing design framework, a custom Vite plugin enables flexible parsing and overriding of multi-entity configurations, meeting the needs of multi-entity business scenarios. Attached Figure Description

[0020] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application.

[0021] In the attached diagram: Figure 1 This is a flowchart illustrating the steps of the electronic banking front-end project upgrade method based on multiple legal entities in an embodiment of the present invention. Figure 2 This is a flowchart illustrating the deployment of the global package within the multi-legal entity-based electronic banking front-end project upgrade method in this embodiment of the invention. Figure 3 This is a flowchart illustrating the process of generating multiple pages based on page configuration information within the method for upgrading an electronic banking front-end project based on multiple legal entities, as described in this embodiment of the invention. Figure 4 This is a flowchart illustrating the process of processing legal entity information and generating meta.json within the method for upgrading an e-banking front-end project based on multiple legal entities, as described in this embodiment of the invention. Figure 5 This is a connection structure diagram of the electronic device in an embodiment of the present invention. Detailed Implementation

[0022] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0023] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0024] Example This invention discloses a method for upgrading a front-end e-banking project based on multiple legal entities. The method involves centrally configuring business entry points and startup parameters, using a Vite plugin to read HTML template files to generate virtual pages for each business, injecting the business entry file, and then sending the assembled static files to the browser. The method also includes a custom Vite plugin that parses legal entity and workspace information and overrides default configurations in the `configResolved` hook function, and generates and outputs a `meta.json` file in the `closeBundle` hook function.

[0025] Reference Figure 1 As shown, the present invention specifically includes the following steps: Step S1: Based on the official Vite scaffolding, add the Vue3 development framework to generate the basic framework structure, add environment files to the Vite configuration file and automatically load the corresponding environment variables through the mode parameters of the build command, and obtain the corresponding legal entity configuration from the full legal entity configuration library through the legal entity identifier to override the default configuration. Step S2: Configure the entry path and startup parameters of each business page independently in the centralized page configuration file, convert the page configuration into the standard format required by the virtual multi-page plugin in the Vite configuration, and automatically generate the virtual HTML entry file required by the multi-page application. Step S3: During the build phase, the legal entity identifier in the environment variable is read through the configuration parsing hook of the custom plugin, and the legal entity path is parsed from the full legal entity configuration library using the Node.js API to obtain the corresponding legal entity configuration information and overwrite the default configuration. Step S4: In the custom plugin's build completion hook, the startup parameters are standardized by traversing the centralized page configuration files, and a metadata file containing the application name and all page information is generated by combining the application identifier for the native client to read and use. Step S5: Clean up and upgrade project dependencies, remove build tools and code inspection packages related to obsolete solutions, upgrade front-end routing, state management, UI component library and style preprocessor to versions adapted to the Vue3 ecosystem, and replace the original test toolchain with a new test framework to complete the build toolchain. Step S6: Based on the upgraded toolchain in step S5, set a volume warning threshold in the build configuration, use custom splitting rules to split dependencies into independent resource packages by function, and use a pre-packaging tool implemented based on a concurrent language for processing.

[0026] For step S1, the Vue 3 development framework is added based on the official Vite scaffolding to generate a basic framework structure. Environment files are added to the Vite configuration file, and the corresponding environment variables are automatically loaded via the build command's mode parameters. The corresponding legal entity configuration is retrieved from the full legal entity configuration library using the legal entity identifier to override the default configuration. Specifically, the latest version of the development framework (Vue 3 and vue-router@5 middleware) is added using the official Vite scaffolding to generate the basic framework structure. Then, the Vite configuration file is modified to add environment files, allowing for differentiation between packaging environments (development, testing, production, etc.). Furthermore, the output resource file path and environment runtime port are set (only required for the development environment). The added environment files are typically created based on the specific environments used in development, and the naming convention is ".env.environment_name". Here, we introduce the common development, testing, and production environments, with the corresponding environment file names as follows: development environment ".env.development", testing environment ".env.test", and production environment ".env.production".

[0027] The environment file's effectiveness depends on the configuration in the packaging command. For example, to output a package for the test environment, you need to add the packaging command and the `mode` parameter to the npm scripts in the `package.json` file. The `mode` parameter should match the environment name. The contents of the `package.json` npm scripts configuration file are as follows: "scripts": { "build:test": "vite build --mode test" } During execution, `vite build` will run to build the project, and the `mode test` parameter will specify the Vite mode as `test`. This will automatically load the environment variables from the `.env.test` file, thus packaging the artifacts for the corresponding test environment.

[0028] The environment configuration file is tailored to requirements, including the workspace, entity, BASE_URL (configuration route), DEV_PORT (running port), and API_PREFIX (interface mapping). The workspace distinguishes different environments and provides usage; for example, `workspace` corresponds to the current workspace, `default` to development, `fat` to testing, and `prod` to production. The entity stores the entity number, used to differentiate entities in scenarios with multiple entities. The BASE_URL configures the base path for routes, determining the application's root directory under the domain name. The DEV_PORT, effective only in the development environment, specifies the port of the development server. The API_PREFIX defines the prefix mapping for interface paths, used to concatenate unified interface addresses. All fields in the environment file must begin with `VITE_`. An example of a development environment file is shown below: VITE_workspace=default VITE_entity=plhd VITE_BASE_URL= / VITE_API_PREFIX=customer VITE_DEV_PORT=3000 Other environment files may have slightly different fields; for example, they won't have the VITE_DEV_PORT field. This is because VITE_DEV_PORT is only meaningful in the development environment, as only the development environment starts the Vite development server and requires a specified port. Test and production environments are directly packaged into static files, and this field will not appear in the corresponding environment files.

[0029] Multi-entity configuration is supported through environment files, including the global and Venus packages. The global package is used to output versioned public static resources (such as Vue and third-party libraries), which are imported via CDN to reduce the size of build artifacts. The Venus package is the full entity configuration library. It's a centralized configuration library for all entities, with configurations for all entities stored flatly in the Venus / entity directory. Each entity has its own unique entity code, name, website address, service agreement, and other information. During development or packaging, Vite loads configuration items starting with VITE_ from the environment files, identifies the current workspace and entity, and retrieves the corresponding complete configuration from the Venus package. This configuration overrides the default entity configuration, enabling dynamic configuration switching and centralized management in multi-entity scenarios.

[0030] Reference Figure 2As shown, the `global` package outputs a common resource package based on the entity and workspace. This common resource package consists of online resource files stored on the server. It includes the Vue core files, third-party libraries such as Tingyun and FastClick. These libraries do not participate in the business project's build process; instead, they are directly included in the page via an online URL, such as "http: / / environment domain / 98500000_default / g / vue / 3.5.13 / vue.js". This approach reduces the build package size and speeds up the build process. These common resources are only built and deployed to the server during the initial deployment; subsequent business iterations do not require reprocessing them. Furthermore, differentiating the output by entity and workspace ensures that different entities or environments have their own independent paths for common resources, achieving on-demand loading and isolation. Even with the same legal entity but different workspaces, the final combined resource package links may differ, such as "http: / / environment domain / 98500000_default / g / vue / 3.5.13 / vue.js" and "http: / / environment domain / 98500000_sit / g / vue / 3.5.13 / vue.min.js". In other words, the global package is the core of the entire page resource loading process, providing the necessary basic library environment for business operations. For example... Figure 2 As shown, Figure 2 This represents a simplified process for deploying a global package.

[0031] Regarding step S2, the entry path and startup parameters for each business page are configured independently in the centralized page configuration file. In the Vite configuration, the page configuration is converted to the standard format required by the virtual multi-page plugin, and the virtual HTML entry file required by the multi-page application is automatically generated. (Refer to...) Figure 3 As shown, specifically, all business entry paths and startup parameters should not be scattered across multiple places, but rather centrally configured in a configuration file, such as src / pages-config.js. This illustrates that a sub-application can contain multiple pages; using the deposit page and transfer page as examples, each page has its own independent entry path and startup parameters in the configuration file, ensuring a clear structure that is easy to maintain and extend.

[0032] The configuration files include pages-config.js and package.json, which together correspond to the business entry point and startup parameters. The configuration of pages-config.js is as follows: deposit: { entry: ". / src / pages / deposit / main.js", public: true, startupParams: { readTitle: false, defaultTitle: "Deposit Product", permissionId: "DepositMenu", }, }, transfer: { entry: ". / src / pages / transfer / main.js", public: true, startupParams: { readTitle: false, defaultTitle: "Transfer", permissionId: "DepositMenu", }, }, The configuration of package.json is as follows: { "name": "deposit", "private": true, "version": "0.0.0", "type": "module", "h5AppId": "1100222", "scripts": { "dev": "vite", "build": "vite build", "build:test": "vite build --mode test", "preview": "vite preview" }, "dependencies": { "oxlint": "^1.64.0", "venusui": ".. / venusui", "vue": "^3.5.13", "vue-router": "^5.1.0" }, "devDependencies": { "@vitejs / plugin-vue": "^5.2.1", "vite": "^6.2.0", "vite-plugin-virtual-mpa": "^1.12.1" } } `pages-config.js` defines the entry file `entry` and startup parameters `startupParams` for each business page. For example, the deposit page and transfer page each have their own independent entry paths, default titles, and permission identifiers. These constitute the page-level startup configuration. Meanwhile, `h5AppId` in `package.json` declares a unique identifier for the sub-application, a global parameter at the application level, used to distinguish different business modules in multi-application scenarios. The combination of these two provides a global application identifier and centrally specifies the entry point and runtime parameters for each page, achieving unified management of business entry points and startup parameters.

[0033] Then, the vite.config.js configuration file reads the page-config.js centralized configuration file and performs a structural transformation. The core transformation logic is as follows: import pageConfig from ". / src / pages-config.js"; const _pages = Object.keys(pageConfig).map((page) =>({ name: page, filename: `${page}.html`, entry: ` / src / pages / ${page} / main.js`, data: { title: pageConfig[page]?.startupParams?.defaultTitle, / / Not injected into the page }, })); Furthermore, firstly, all page names are obtained through `Object.keys`, and then each page is traversed and converted into the standard format required by the `vite-plugin-virtual-mpa` plugin. During the conversion: `name` takes the page key as the page identifier; `filename` is concatenated according to the `${page}.html` rule to generate the final HTML filename of the build artifact; `entry` is uniformly regenerated according to the ` / src / pages / ${page} / main.js` rule, overriding the relative path in the original configuration; the `title` field is injected into the `data` object, and its value is safely read as the default title of the corresponding page through optional chaining. The resulting standardized array structure is directly used as the configuration input for the MPA plugin, which automatically generates multiple HTML entry files and injects the title. The previous conversion converts the page configuration into a standard format array, which is then passed as a parameter to the `vite-plugin-virtual-mpa` plugin for processing. This plugin is a third-party developed plugin under the MIT open-source license; it can automatically generate multiple HTML entry files required for multi-page applications and complete data injection based on this data, thus eliminating the hassle of manually creating and maintaining HTML templates.

[0034] To ensure successful page generation, it's essential to guarantee that the file specified in the `entry` field of each page exists. While not mandatory, maintaining consistency between the business folder name and the `name` and `filename` fields is crucial for good maintainability and significantly improves project readability and maintainability. Vite's `vite-plugin-virtual-mpa` plugin reads a unified HTML template file and generates a virtual page for each business page. This virtual file is in-memory data and is not directly written to disk. During development, when a page is accessed via a URL, the plugin's built-in template engine (ejs) injects the corresponding business entry file into the template, assembling it into a complete static file before sending it to the browser. These assembled pages are only written to disk during the build phase.

[0035] Regarding step S3, during the build phase, a custom plugin's configuration parsing hook reads the legal entity identifier from environment variables. The Node.js API is then used to parse the legal entity path from the full legal entity configuration library, obtain the corresponding legal entity configuration information, and overwrite the default configuration, thus achieving automated switching between multiple legal entity configurations. (Refer to...) Figure 4As shown, specifically, when creating a custom plugin in Vite, it is recommended to place the plugin file in the `src / plugins` directory and name it `vite-plugin-generate-file`. By setting the `enforce` attribute to `'post'`, you can specify that the plugin should execute after the core plugins in the build phase. Since `meta.json` is a file required for deployment runtime, it is only generated after the build package produces the bundle artifacts, and is not needed in the local development mode. Therefore, Vite's conditional statement for the current command can be used to skip the development server. Vite plugins execute before (`pre`) and after (`post`) the core plugins. Execution before the core plugins corresponds to `enforce: 'pre'`, and execution after the core plugins corresponds to `enforce: 'post'`. When Vite starts, it iterates through all plugin configurations and stores them in three arrays—`prePlugins`, `postPlugins`, and `normalPlugins`—based on the `enforce` attribute. Plugins without a `enforce` attribute are placed in `normalPlugins`. Because our custom plugin has `enforce: 'post'` set, it will be added to the `postPlugins` array, ensuring it runs after all core and regular plugins have finished their work. This is perfect for adding some file generation logic after the final artifact is generated. Vite automatically calls all hooks without explicitly specified orders in the appropriate lifecycle, so there's no need to configure trigger timing separately. You only need to define the appropriate hooks (such as `closeBundle`) in your plugin and write the code to generate `meta.json`.

[0036] During the build process, Vite executes the hooks in the following order: / / Some plugins omitted ...prePlugins, / / Custom plugins / / Some code omitted htmlInlineProxyPlugin(config), cssPlugin(config) / / Some code omitted wasmHelperPlugin(config) webWorkerPlugin(config) assetPlugin(config) ...normalPlugins, / / Custom plugins wasmFallbackPlugin(), definePlugin(config), / / Some plugins omitted dynamicImportVarsPlugin(config), importGlobPlugin(config), ...postPlugins, / / Custom plugins / / Some plugins omitted When Vite starts, it divides plugins into three queues—prePlugins, normalPlugins, and postPlugins—based on their `enforce` attribute. The execution order is as follows: plugins in `prePlugins` are executed first, followed by built-in core plugins and normal plugins without `enforce` settings, and finally plugins in `postPlugins`. This ensures that custom plugins within these queues run after all core and normal plugins. Custom plugins like `vite-plugin-generate-file` with `enforce: 'post'` are placed in `postPlugins`. However, it primarily uses two lifecycle hooks; the `configResolved` hook is highlighted here. This hook is called after Vite's configuration is fully resolved. At this point, all environment variables and user configurations are ready, and the plugin can read the `VITE_workspace` and `VITE_entity` information previously defined in the environment file. After obtaining the current workspace and entity ID, the plugin searches for the corresponding complete entity configuration in the Venus package, then deletes the default configuration in the `node_modules / venus / entity / default` directory and copies the current entity configuration to that default location. In this way, during subsequent builds or development runs, the actual configuration used is the legal entity configuration corresponding to the current environment, realizing automated configuration switching in multi-legal entity scenarios without manual intervention.

[0037] In the third step of the plugin, based on the legal entity configuration obtained during the configuration parsing phase, the legal entity path, such as ". / node_modules / venusui / entity / configured_entity", is parsed from the Venus package in the public library via Node.js API. Venus is an internal structure of Venusui. The corresponding legal entity configuration information is retrieved and overridden with the original default configuration; the default configuration is not used. This information is read when differentiating legal entities in business logic, thus enabling differentiated support for multiple legal entity businesses. Specifically, the logic for overriding the legal entity configuration is as follows: Upon initial dependency installation, the Venus package is copied to the project's node_modules directory. Whether starting the development environment or executing a build, Vite, upon startup, parses the current legal entity configuration from the environment file, deletes the default configuration, and copies the current legal entity information to the current project's node_modules / venus / entity / default folder. This operation occurs during local service startup, affecting only the current user, and follows the node_modules operation, so there are no operational confusion issues. During parallel development, each user has a local set of Venus packages in their working directory, so it only affects local operations. This overwrite is a runtime replacement and will not affect other entities besides the default one. Venus will not be modified unless a new entity is added.

[0038] Regarding step S4, in the custom plugin's build completion hook, the centralized page configuration files are traversed to standardize the startup parameters, and a metadata file containing the application name and all page information is generated for the native client to read, based on the application identifier. Specifically, the `closeBundle` hook function is automatically executed during packaging. Because Vite has already completed the page build at this point, the execution of the `vite-plugin-generate-file` plugin at this time will not affect the main Vite workflow. First, the page configuration information (i.e., `src / pages-config.js`) is imported, and this configuration data is traversed to generate in-memory data. Each page is a set of object data, and the object structure is as follows: import pkg from '.. / .. / package.json' pageInfo[index.html] = { public: true, roles: [], startupParams: { defaultTitle: '', showTitleBar: true, showBack: true } } The core processing flow is as follows: Object.keys(pagesConfig).map((key, index) =>{ / / Process startup parameters const startupParams = pagesConfig[key].startupParams || {}; / / Startup parameters const { readTitle, defaultTitle, showTitleBar, showBack} = startupParams; startupParams.readTitle = !!readTitle; startupParams.defaultTitle = defaultTitle || ""; / / Default title startupParams.showTitleBar = showTitleBar === undefined ? true : showTitleBar; / / Display the title bar startupParams.showBack = showBack === undefined ? true :showBack; / / Show the back button pagesInfo[`${key}.html`] = { public: !!pagesConfig[key].public, / / / / true: No login required, false: Login required, default is false roles: pagesConfig[key].roles || ["A", "B", "C", "D", "E"], startupParams: startupParams, / / H5 container startup parameters }; } All page configurations will be combined together. const output = { appName: `${pkg.name}`, [Application's appID]: pagesInfo, }; The process iterates through all page configurations defined in `pagesConfig`, standardizing the startup parameters for each page and ultimately combining them into a unified output structure. First, it reads the application name from `package.json`. Then, it iterates through the page configuration objects using `Object.keys`, extracting parameters such as `readTitle`, `defaultTitle`, `showTitleBar`, and `showBack` from `startupParams` for each page. Missing items are assigned reasonable default values ​​(e.g., an empty title string, and the default display of the title bar and back button), and `readTitle` is converted to a boolean value. Simultaneously, the `public` and `roles` fields of the page are read to determine if login authentication and role restrictions are required; `roles` predefines a default permission array. The standardized configuration is stored in a `pagesInfo` object with the key "pagename.html". Finally, all page information is combined with the application name obtained from `package.json`, using the application's unique identifier `appID` as the key, to generate a complete output object containing the application name and all page configurations for use by subsequent multi-page generation or runtime containers. `appID`s are centrally configured in Venus; there is no centralized configuration declared in `appName`. In actual projects, the package.json file will also have an appID field, mainly used when generating mate.json. There are no restrictions on the rules for defining appID, as long as it remains consistent across the frontend, backend, and native applications.

[0039] Finally, the previously assembled output object is synchronously written to the meta.json file in the project root directory using Node.js's built-in writeFileSync method. This file is generated only during the build phase and is not needed in development mode. meta.json is used by the native application (Android or iOS) to read when navigating to new pages after the application is deployed. The native application parses this file to obtain the startup parameter configurations for each page, such as whether login is required, the default title, and the display control of the title bar and back button, thereby enabling the native container to control page routing and UI. Therefore, meta.json is essentially a list of page configurations output from the front-end build to the native application; it represents a collaborative agreement between the native and front-end developers and is not within the scope of the front-end runtime.

[0040] For step S5, project dependencies are cleaned up and upgraded. Build tools and code inspection packages related to outdated solutions are removed. Frontend routing, state management, UI component libraries, and style preprocessors are upgraded to versions compatible with the Vue 3 ecosystem. A new testing framework replaces the original testing toolchain to complete the build toolchain. Specifically, the `@ali / kylin-*` series packages related to outdated solutions are removed, all ESLint-related packages (eslint and eslint-* plugins) are deleted and replaced with oxlint, the unnecessary acorn library is removed, and all Webpack-related libraries are removed to fully switch to Vite. Simultaneously, the testing framework is upgraded from Jest to Vitest, which is more compatible with the Vite ecosystem, and chai, karma, phantomjs, and sinon are removed and replaced uniformly by Vitest. The core libraries requiring upgrades include: replacing the UI component library from Mand-mobile with Vant for richer components and faster bug fixes; upgrading vue-router from 3.x to 5.x for full compatibility with the Vue 3 technology stack; migrating the state management library from Vuex 2.x to the latest version, Pinia, which not only adapts to Vue 3 but also provides better modular support; and upgrading the style preprocessor Stylus for new feature support and bug fixes. The first version of vue-router 5.x (5.0.0) was officially released on January 19, 2026.

[0041] For step S6, based on the upgraded toolchain from step S5, a size warning threshold is set in the build configuration. Custom splitting rules are used to divide dependencies into independent resource packages by function, and a pre-packaging tool implemented using a concurrent language is used for processing. The front-end codebase consists of two parts: third-party dependencies and business logic code. The third-party dependencies that need to be split typically fall into two categories: one is the core front-end framework package, responsible for page rendering and routing, which needs to be packaged into independent files for priority loading; the other is the UI component library and utility library. If the size after gzip compression exceeds 500KB, it needs to be split a second time. Splitting rules are added to advancedChunks to ensure that each split file is under 500KB. This is ensured through repeated packaging and testing, as the size of each file is output after packaging. A file size greater than 500KB will affect the user experience, especially under weak network conditions, significantly increasing loading time and severely impacting the performance metric LCP (Largest Contentful Paint), which measures the time required for the most important content to be displayed on a webpage. A lower LCP indicates to the user that the webpage loads quickly.

[0042] The secondary splitting method involves adding rules to advancedChunks, setting the `chunkSizeWarningLimit` field. This is primarily configured in the `build` section of the `vite.config.js` file, as follows: build: { chunkSizeWarningLimit: 500, rollupOptions: { external: ['vconsole'], treeshake: true, output: { cleanDir: true, advancedChunks: { groups: [ { name: 'vendor', test: (id) =>{ return ( id.includes('node_modules')&& (id.indexOf('vue+runtime-dom') !== -1 || id.indexOf('router') !== -1) ) }, }, { name: 'lib', test: (id) =>{ / / console.log(id) return ( id.includes('node_modules')&& (id.indexOf('vant') !== -1 || id.indexOf('pinia') !== -1 || id.indexOf('pinia-plugin-persistedstate') !== -1) ) }, }, { name: 'utils', test: (id) =>{ return ( id.includes('node_modules')&& (id.indexOf('axios') !== -1 || id.indexOf('javascript-common-tools') !== -1 || id.indexOf('javascript-validate-utils') !== -1) ) }, }, ], }, topLevelVar: true, }, }, }, }) The above configuration is the core of the Vite build configuration, mainly providing fine-grained control over production packaging behavior. `chunkSizeWarningLimit:500` sets the warning threshold for excessively large chunks to 500KB; chunks exceeding this threshold will trigger a warning. Setting it to 500KB is to issue a warning when the chunk exceeds 500KB, allowing developers to split it. `external:['vconsole']` prevents vconsole from participating in the packaging, importing it separately as an external dependency via CDN, etc. `treeshake:true` under `rollupOptions` enables tree-shaking optimization, removing unused code. `cleanDir:true` under `output` ensures the output directory is cleared before each build, avoiding residual old files. `advancedChunks.groups` is the core of the custom chunking strategy, splitting dependencies in `node_modules` into three independent packages based on functionality. `vendor` contains the core framework code related to the Vue runtime and routing; `lib` contains UI and state management libraries such as Vant and Pinia; and `utils` contains Axios and utility libraries. This allows for separate packaging of the base library, UI library, and utility library, controlling the size of the single package and improving browser cache utilization. Meanwhile, the base library code changes less frequently, allowing users to continue using the cache when updating. `topLevelVar:true` exposes the top-level variable in the packaged code to the global scope, facilitating debugging or access by other scripts.

[0043] Business code is loaded using dynamic imports, and Vite generates independent chunks for each dynamically imported module to achieve code splitting. This has two advantages: first, resources can be loaded on demand, speeding up the first screen loading; second, each chunk is smaller, resulting in lower memory overhead during static analysis and code compression, reducing the probability of bundling failures. The old solution, based on a single-threaded Node.js Webpack 1.15, required prior compilation of CoffeeScript, which easily reached memory bottlenecks and caused frequent bundling failures when handling large projects. Vite, starting from version 2.0, uses esbuild, implemented in Go, for pre-bundling. Go inherently supports concurrency, and its processing speed and stability far surpass those of single-threaded Node.js. The Webpack 1.15 version integrated into Kylin executes the entire bundling process—from file lookup, dependency resolution, loader transformation (requiring additional CoffeeScript compilation), code generation, to final code compression—serially within a single-threaded Node.js instance. Node.js's single-threaded mechanism means that these tasks can only be queued one after another and cannot be processed in parallel. As the number of project files increases, single-threading can easily become a bottleneck, causing memory to accumulate continuously and not be released in time, ultimately leading to frequent packaging failures. Therefore, this invention can significantly reduce packaging failures, which is the key reason why e-banks upgraded their packaging tools to Vite6.

[0044] From a front-end engineering perspective, to ensure smooth page loading and operation while reducing memory pressure during bundling, improvements can be made in the following ways: First, use the visual analysis plugin rollup-plugin-visualizer to examine the size and dependencies of npm packages, adjust the bundle structure in a timely manner, and merge scattered or irrelevant resource packages to optimize the composition of the bundled artifacts from the source, thereby indirectly reducing the memory overhead of processing large modules during bundling; Second, prioritize the introduction of middleware based on Rust or Go languages, such as oxlint, in toolchain selection. Leverage the advantages of these languages ​​in concurrency and memory management to replace traditional Node.js single-threaded tools, directly reducing memory usage in code inspection and other processes and significantly improving response speed, making the overall build process more lightweight and efficient.

[0045] To implement the above embodiments, this application also discloses an electronic device. (Refer to...) Figure 5As shown, the electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0046] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although... Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 5 Each box shown can represent a device or multiple devices as needed.

[0047] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of some embodiments of this disclosure.

[0048] It should be noted that, in some embodiments of this disclosure, the computer storage medium described above can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0049] In some embodiments of this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used or combined with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or combined with an instruction execution system, apparatus, or device. The program code contained on the computer storage medium can be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof. The aforementioned computer storage medium can be included in the aforementioned electronic device or can exist independently without being assembled into the electronic device. The aforementioned computer storage medium carries one or more programs that, when executed by the electronic device, enable the electronic device to implement a method for upgrading the front-end project of an electronic bank based on multiple legal entities.

[0050] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0051] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0052] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings.

[0053] For example, two consecutively represented blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions. Units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be located in a processor, and the names of these units do not necessarily constitute a limitation on the unit itself.

[0054] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0055] All technologies not described in detail in this invention are existing technologies. The above descriptions are merely some preferred embodiments of this disclosure and explanations of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalent features without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for upgrading the front-end project of an electronic bank based on multiple legal entities, characterized in that, Specifically, the following steps are included: Step S1: Based on the official Vite scaffolding, add the Vue3 development framework to generate the basic framework structure, add environment files to the Vite configuration file and automatically load the corresponding environment variables through the mode parameters of the build command, and obtain the corresponding legal entity configuration from the full legal entity configuration library through the legal entity identifier to override the default configuration. Step S2: Configure the entry path and startup parameters of each business page independently in the centralized page configuration file, convert the page configuration into the standard format required by the virtual multi-page plugin in the Vite configuration, and automatically generate the virtual HTML entry file required by the multi-page application. Step S3: During the build phase, the legal entity identifier in the environment variable is read through the configuration parsing hook of the custom plugin, and the legal entity path is parsed from the full legal entity configuration library using the Node.js API to obtain the corresponding legal entity configuration information and overwrite the default configuration. Step S4: In the hook for completing the construction of the custom plugin, the startup parameters are standardized by traversing the centralized page configuration file, and a metadata file containing the application name and all page information is generated by combining the application identifier for the native client to read. Step S5: Clean up and upgrade project dependencies, remove build tools and code inspection packages related to obsolete solutions, upgrade front-end routing, state management, UI component library and style preprocessor to versions adapted to the Vue3 ecosystem, and replace the original test toolchain with a new test framework to complete the build toolchain. Step S6: Based on the toolchain upgraded in step S5, set a volume warning threshold in the build configuration, use custom sub-packaging rules to split dependencies into independent resource packages by function, and use a pre-packaging tool implemented based on a concurrent language for processing.

2. The method for upgrading a front-end e-banking project based on multiple legal entities according to claim 1, characterized in that: In step S1, the environment files include development environment files, testing environment files, and production environment files corresponding to the development environment, testing environment, and production environment, respectively. The environment files follow the naming convention ".env.environment_name", and the environment name corresponds to the mode parameter value in the build command. Each environment file defines environment variables used to represent the workspace, legal entity, basic routing path, and interface prefix, and all environment variables begin with "VITE_". The build mode is specified in the package.json script by configuring the command "vite build --mode environment_name", so that Vite automatically loads the environment variables in the environment file with the corresponding environment name when executing the build.

3. The method for upgrading a front-end e-banking project based on multiple legal entities according to claim 2, characterized in that: In step S1, the environment file supports configurations for multiple legal entities, including a global package and a Venus package. The global package is used to output versioned public static resource addresses based on the legal entity identifier and workspace. The public static resources are directly imported into the page in the form of online URLs and do not participate in business packaging. The Venus package is a full legal entity configuration library, which stores the configurations of each legal entity in a flat manner according to the legal entity identifier.

4. The method for upgrading a front-end e-banking project based on multiple legal entities according to claim 3, characterized in that: In step S2, the entry paths and startup parameters of each business page are centralized in the src / pages-config.js file. Each page's configuration items include at least the entry path and startup parameters, with the startup parameters including a default title and permission identifier. During the conversion, all page key names in the centralized page configuration file are traversed, and a standardized object array containing page name, output file name, entry path, and title data is generated for each page. This array serves as the configuration input for the virtual multi-page plugin to generate a virtual HTML entry file. During the development phase, the business entry file is injected into the template in memory through the template engine of the virtual multi-page plugin to assemble the complete page. The assembled page is only written to disk during the build phase.

5. The method for upgrading a front-end e-banking project based on multiple legal entities according to claim 4, characterized in that: In step S3, the configuration resolution hook is the `configResolved` hook function. The custom plugin reads the legal entity identifier from the environment variables using the `configResolved` hook function, and uses the Node.js file system API to override the default configuration with the legal entity configuration corresponding to the legal entity identifier. This also includes the following steps: The Vite plugin's configResolved hook function reads the legal entity identifier and workspace information from environment variables; Based on the legal entity identifier, locate and parse the corresponding complete legal entity configuration from the Venus package in the public configuration library; Delete the default legal entity configuration directory using the Node.js file system API; Copy the current legal entity configuration to the default legal entity configuration directory, and automatically load the switched legal entity configuration during subsequent builds or runtime.

6. The method for upgrading a front-end e-banking project based on multiple legal entities according to claim 5, characterized in that: In step S4, the completion hook is the closeBundle hook function. The custom plugin generates metadata files through the closeBundle hook function. In the closeBundle hook function, the centralized page configuration files are read, the startup parameters of each page are traversed and normalized, and the readTitle is converted into a boolean value to determine the publicness and role permissions of the page. Then, the application name and application unique identifier appID obtained from package.json are combined to form an output object containing the application name and all page configurations. Finally, write it to the meta.json file in the project root directory synchronously through writeFileSync. The meta.json file is generated only during production builds and serves as a page configuration manifest delivered from the front end to the native application. It is used by the native application to parse startup parameters and control the UI behavior of the title bar and back button when navigating to a page.

7. The method for upgrading a front-end e-banking project based on multiple legal entities according to claim 6, characterized in that, In step S5, the cleanup and upgrade of project dependencies specifically includes: Remove build tools and their dependencies associated with the old build scheme; Remove the existing code inspection tools and their plugin packages, and introduce new code inspection tools based on Rust or Go as replacements; Remove the original testing framework and its ecosystem dependencies, and introduce a testing framework adapted to the Vite ecosystem as a replacement; Upgrade the front-end routing library to a version compatible with Vue 3, migrate the state management library to Pinia compatible with Vue 3, and replace the UI component library with a component library compatible with Vue 3.

8. The method for upgrading a front-end e-banking project based on multiple legal entities according to claim 7, characterized in that: In step S6, the volume warning threshold is set to 500KB, and the dependencies in node_modules are split into three independent resource packages according to the core framework, interface component library and tool library using custom splitting rules. If the package size still exceeds the volume warning threshold after splitting, a rule is added to advancedChunks for secondary splitting, and each file is controlled within the volume warning threshold through repeated packaging and verification. In addition, esbuild, which is implemented based on Go language, is used for pre-packaging to ensure build speed and stability.

9. An electronic device, characterized in that, include: At least one processor, and a memory communicatively connected to said at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the steps of the method according to any one of claims 1 to 8.

10. A computer storage medium storing a computer program thereon, characterized in that: When the computer program is executed by the processor, it performs the steps as described in any one of claims 1 to 8.

Images