Multi-version front-end language generation method and device based on environment variables

Abstract

The invention discloses a multi-version front-end language generation method and device based on environment variables, relates to the technical field of front-end development, and mainly aims to reduce development and maintenance cost and avoid language repetition and increase of management complexity so as to improve development efficiency. According to the main technical scheme, the method comprises the steps that according to the multi-version deployment requirement corresponding to the project application, environment variables corresponding to different version environments are injected into a packaging command of a project application source language file; when the target packaging command is operated, reading a target environment variable in the target packaging command and a target version environment corresponding to the target environment variable; determining a language construction rule corresponding to the target version environment by using the target environment variable; and processing the project application source language file according to the target display logic, the target resource reference path and the target language segmentation strategy to generate a target source language file corresponding to the target version environment.

Description

Technical Field

[0001] This application relates to the field of front - end development technologies, and in particular, to a method and device for generating multi - version front - end languages based on environment variables. Background Art

[0002] With the acceleration of Internet technology and the globalization process, more and more enterprises hope that their Web applications can serve different global markets. These markets may have different user requirements, legal and regulatory requirements, cultural preferences, and technical environments, etc. To meet such diverse needs, enterprises usually need to develop and maintain multiple versions of application programs, and each version is customized for a specific market.

[0003] Currently, in the prior art, for multi - version front - end languages, independent language repositories or branches are usually created for each market and developed and maintained separately. However, this approach not only increases the development and maintenance costs, but also may lead to language duplication and increased management complexity, seriously affecting development efficiency and even causing a decline in the enterprise's market competitiveness. Summary of the Invention

[0004] In view of the above problems, this application provides a method and device for generating multi - version front - end languages based on environment variables, with the main purpose of reducing development and maintenance costs, avoiding language duplication and increased management complexity, thereby improving development efficiency.

[0005] To solve the above - mentioned technical problems, this application proposes the following solutions:

[0006] In a first aspect, this application provides a method for generating multi - version front - end languages based on environment variables, and the method includes:

[0007] According to the multi - version deployment requirements corresponding to the project application, inject the environment variables corresponding to different version environments into the packaging command of the project application source language file respectively;

[0008] When running the target packaging command, read the target environment variable in the target packaging command, and the target version environment corresponding to the target environment variable;

[0009] Use the target environment variable to determine the language construction rules corresponding to the target version environment, and the language construction rules include target display logic, target resource reference path, and target language segmentation strategy;

[0010] Process the project application source language file according to the target display logic, the target resource reference path, and the target language segmentation strategy to generate the target source language file corresponding to the target version environment.

[0011] In a second aspect, the present application provides a multi-version front-end language generation device based on environment variables, and the device includes:

[0012] An injection unit, configured to inject environment variables corresponding to different version environments into the packaging command of the project application source language file respectively according to the multi-version deployment requirements corresponding to the project application;

[0013] A reading unit, configured to read the target environment variable in the target packaging command obtained by the injection unit and the target version environment corresponding to the target environment variable when running the target packaging command;

[0014] A determination unit, configured to determine the language construction rules corresponding to the target version environment by using the target environment variable obtained by the reading unit, where the language construction rules include a target display logic, a target resource reference path, and a target language segmentation strategy;

[0015] A processing unit, configured to process the project application source language file according to the target display logic, the target resource reference path, and the target language segmentation strategy obtained by the determination unit, and generate a target source language file corresponding to the target version environment.

[0016] To achieve the above object, according to a third aspect of the present application, there is provided a storage medium, where the storage medium includes a stored program, and when the program runs, it controls the device where the storage medium is located to execute the multi-version front-end language generation method based on environment variables in the first aspect above.

[0017] To achieve the above object, according to a fourth aspect of the present application, there is provided a processor, where the processor is used to run a program, and when the program runs, it executes the multi-version front-end language generation method based on environment variables in the first aspect above.

[0018] With the above technical solution, a multi-version front-end language generation method and device provided by the present application first inject the environment variables corresponding to different version environments into the packaging command of the project source language file according to the multi-version deployment requirements corresponding to the project application. Then, when the target packaging command is run, the target environment variable in the target packaging command is read, and the target version environment corresponding to the target environment variable is obtained. Next, the language construction rules corresponding to the target version environment are determined using the target environment variable. The language construction rules include the target display logic, the target resource reference path, and the target language segmentation strategy. Finally, the project source language file is processed according to the target display logic, the target resource reference path, and the target language segmentation strategy to generate the target source language file corresponding to the target version environment, and the target source language file is distributed to the language repository of the target version environment. The technical solution provided by the present application can easily perform customized construction for multiple versions by injecting different environment variables into the packaging command. Developers only need to maintain a set of language libraries and use different environment variables to distinguish version-specific logic and resources, reducing the need for multiple language libraries. Automatically reading environment variables during the packaging process ensures that each packaging can accurately respond to the configuration requirements of the version, avoiding human errors. Determining the specific display logic, resource reference path, and language segmentation strategy based on environment variables can achieve modular design, making the finally generated source language file only contain the version source code necessary for the configuration requirements of the version, reducing language redundancy, overall avoiding the increase of language duplication and management complexity, reducing the development and maintenance costs, effectively improving the development efficiency, and ensuring the market competitiveness of the enterprise.

[0019] The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features, and advantages of the present application more obvious and understandable, the specific embodiments of the present application are specifically exemplified below. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] By reading the detailed description of the preferred embodiments below, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of the present application. And throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0021] Figure 1 Shows a flowchart of a multi-version front-end language generation method based on environment variables provided by an embodiment of the present application;

[0022] Figure 2 Shows a flowchart of another multi-version front-end language generation method based on environment variables provided by an embodiment of the present application;

[0023] Figure 3 shows a block diagram of a multi-version front-end language generation device provided by an embodiment of the present application based on environment variables;

[0024] Figure 4 shows a block diagram of another multi-version front-end language generation device provided by an embodiment of the present application based on environment variables. Detailed implementation manners

[0025] Hereinafter, exemplary embodiments of the present disclosure will be described in more detail with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be fully conveyed to those skilled in the art.

[0026] Currently, in the prior art, the management and distribution of multi-version front-end languages usually create independent language repositories or branches for each market and develop and maintain them separately. For example. However, this method not only increases the development and maintenance costs, but also may lead to language duplication and increased management complexity, seriously affecting the development efficiency, and even causing a decline in market competitiveness.

[0027] The inventor has found through research that environment variables can be set for each version environment according to multi-version requirements, and the environment variables are respectively injected into the packaging commands of the project application source language files. When it is necessary to generate the target source language files required for a certain version environment, the packaging commands can be run, and the environment variables are read from them. According to the environment variables, the corresponding language construction rules are determined, such as display logic, target resource reference paths, and target language segmentation strategies, etc. Finally, the source language files associated with the environment variables are packaged based on the language construction rules, so as to generate the target source language files required for this version environment. In this way, developers only need to maintain a set of language libraries and use different environment variables to distinguish version-specific logics and resources, reducing the need for multiple language libraries, making the finally generated target source language files only contain the version source code necessary for the configuration requirements of the version, reducing language redundancy, generally avoiding language duplication and increased management complexity, reducing the development and maintenance costs, effectively improving the development efficiency, and ensuring the market competitiveness of the enterprise.

[0028] Based on the above considerations, an embodiment of the present application provides a multi-version front-end language generation method based on environment variables. Through this method, the development and maintenance costs can be reduced, language duplication and management complexity can be avoided, thereby improving the development efficiency. The execution subjects to which it is applied include, but are not limited to, application building systems, CI / CD continuous integration systems, application operation and maintenance systems, etc. The specific execution steps are as follows Figure 1As shown, it includes at least 101 - 104.

[0029] 101. According to the multi - version deployment requirements corresponding to the project application, inject the environment variables corresponding to different version environments into the packaging command of the project application's source language file respectively.

[0030] In this step, the project application specifically refers to a Web application that needs to be deployed in multiple markets, and the project application's source language file refers to the source code file developed by the developer specifically for the project application. Before injecting the environment variables, it is necessary to deeply understand the specific requirements of the project application in different version environments. The version environment can be specifically divided according to the functional requirements of different regions, such as the overseas market version, the domestic market version, etc. Different versions may have differences in function display, resource usage, performance requirements, etc. For example, the version in the domestic market may need to display certain advertising content, while the version in the overseas market does not, or the requirements for resources such as pictures and fonts are different in different market versions. Specifically, communicate with the market team and product team to collect and analyze these requirements to provide a basis for subsequent environment variable settings.

[0031] According to the multi - version deployment requirements, set independent packaging commands for each version environment so that these packaging commands can correctly pass the environment variables. The environment variables can be strings used to identify different versions. For example, VITE_APP_ENV = market1 or VITE_APP_ENV = market2.

[0032] Inject the environment variables in the configuration files of build tools such as Webpack and Vite. Taking Vite as an example, in the vite.config.js file, the define option can be used to define the environment variables. It is also possible to define different packaging commands in the project application's package.json file and inject the environment variables into the commands.

[0033] Exemplarily,

[0034] "build:market1": "cross - env VITE_APP_ENV = market1 vite build";

[0035] "build:market2": "cross - env VITE_APP_ENV = market2 vite build".

[0036] 102. When running the target packaging command, read the target environment variables in the target packaging command.

[0037] Among them, the target environment variables correspond to the target version environment.

[0038] Select the corresponding target packaging command and run it according to the target version environment to be deployed. For example, to package for version 1, you can execute npm run build:market1 in the terminal. During the packaging process, the build tool will automatically read the target environment variables injected in the target packaging command. Specifically, there are different ways to read the injected environment variables. For example, in a JavaScript file, you can directly use the process.env object to access the environment variables. If you need to read environment variables in the build script, you can use the process.env object of Node.js.

[0039] 103. Determine the language build rules corresponding to the target version environment using the target environment variables.

[0040] In this step, for each environment variable corresponding to a version environment, set the corresponding display logic, resource reference path, and language segmentation strategy, etc. in advance. The display logic is used to adjust aspects such as the page layout, component display, and copy content of the project application. For example, in the display logic corresponding to version 1, a specific carousel may be displayed on the home page, while in the display logic corresponding to version 2, a different carousel may be displayed.

[0041] The resource reference path is used to adjust the reference path of static resources. For example, resources such as images, fonts, and style files for different versions are stored in different directories. This can be achieved through a configuration file or language logic.

[0042] The language segmentation strategy is used to improve the performance analysis results of the project application, that is, to remove the languages that are not related to the environment variables. The removal granularity can set different language removal levels according to the performance analysis results, such as level 0 (no deletion), level 1 (coarse-grained), level 2 (fine-grained), etc. Each language removal level corresponds to a different language segmentation strategy. For example, level 0 means keeping all languages without deletion. Level 1 (coarse-grained) means deleting the entire directory / file, specifically deleting by folder (such as src / market2 / ). Level 2 (fine-grained) means deleting conditional language blocks within the file, specifically deleting by comment markers (such as / / MARKER:ENV=market2). Exemplarily, in the language segmentation strategy of version 1, it may be necessary to remove all languages of other versions and package them separately to reduce the initial loading time, while in the language segmentation strategy of version 2, some languages of other versions may be removed and packaged separately. Specifically, language segmentation can be achieved through the configuration of Webpack or Vite.

[0043] The process of setting corresponding display logics, resource reference paths, and language segmentation strategies for different environment variables can be specifically achieved by adding conditional languages at the corresponding positions in the source language files of the project application. After determining the target environment variable, the language construction rules corresponding to the target version environment can be determined through the conditional language in the pre-set display logic, resource reference path, and language segmentation strategy. The language construction rules include the target display logic, target resource reference path, and target language segmentation strategy.

[0044] 104. Process the source language files of the project application according to the target display logic, target resource reference path, and target language segmentation strategy to generate the target source language files corresponding to the target version environment.

[0045] In this step, for the source language files of the project application, process them according to the target display logic, including but not limited to operations such as modifying conditional judgments in the language, replacing copywriting content, and adjusting component displays. Update the resource reference paths in the source language files of the project application to meet the requirements of the target version environment. Specifically, regular expressions or language parsing tools can be used to replace the strings of resource references. According to the target language segmentation strategy, package the source language files of the project application. Use build tools (such as Webpack, Vite) to package according to the configured language segmentation rules to generate the source language files that meet the target version environment. During the packaging process, the build tool will automatically split the language into multiple modules and generate the corresponding file names and paths according to the configuration.

[0046] After the above processing, save the processed language as the target source language file. Output these files to the specified directory for subsequent deployment.

[0047] Based on the above Figure 1As can be seen from the implementation method, a multi-version front-end language generation method based on environment variables provided by this application first injects the environment variables corresponding to different version environments into the packaging command of the project application source language file according to the multi-version deployment requirements of the project application. Then, when the target packaging command is run, the target environment variable in the target packaging command is read, and the target version environment corresponding to the target environment variable. Next, the language construction rules corresponding to the target version environment are determined using the target environment variable. The language construction rules include the target display logic, the target resource reference path, and the target language segmentation strategy. Finally, the project application source language file is processed according to the target display logic, the target resource reference path, and the target language segmentation strategy to generate the target source language file corresponding to the target version environment, and the target source language file is distributed to the language repository of the target version environment. The technical solution provided by this application can easily perform customized construction for multiple versions by injecting different environment variables into the packaging command. Developers only need to maintain a set of language libraries and use different environment variables to distinguish version-specific logic and resources, reducing the need for multiple language libraries. The environment variables are automatically read during the packaging process to ensure that each packaging can accurately respond to the version configuration requirements, avoiding human errors. By determining the specific display logic, resource reference path, and language segmentation strategy based on the environment variables, modular design can be achieved, so that the finally generated source language file only contains the version source code necessary for the version configuration requirements, reducing language redundancy. Overall, it avoids the increase of language duplication and management complexity, reduces the development and maintenance costs, effectively improves the development efficiency, and safeguards the market competitiveness of the enterprise.

[0048] Further, the preferred embodiment of this application is a detailed description of the process of multi-version front-end language generation based on environment variables on the basis of the above Figure 1 The specific steps are as follows Figure 2 shown, and at least include 201-206.

[0049] 201. According to the multi-version deployment requirements of the project application, inject the environment variables corresponding to different version environments into the packaging command of the project application source language file respectively.

[0050] This step combines the description of step 101 in the above method, and the same content will not be repeated here.

[0051] 202. When the target packaging command is run, read the target environment variable in the target packaging command.

[0052] This step combines the description of step 102 in the above method, and the same content will not be repeated here.

[0053] 203. Use the target environment variable to determine the language construction rules corresponding to the target version environment.

[0054] This step is combined with the description of step 103 in the above method, and the same content will not be repeated here.

[0055] It should be noted that before determining the language construction rules corresponding to the target version environment, it is necessary to set the display logic, resource reference path, and language segmentation strategy for each environment variable corresponding to the project application respectively. The specific implementation process is as follows: Set the display logic corresponding to different environment variables according to the functional differences between different version environments; Set the resource reference path corresponding to different environment variables according to the resource requirements of different version environments, and the resource reference path consists of the resource directory corresponding to different environment variables and the general reference alias; Set the language segmentation strategy corresponding to different environment variables according to the performance analysis results of different version environments; Based on the display logic, resource reference path, and language segmentation strategy, add conditional statements corresponding to different said environment variables to the source language file of the project application.

[0056] In this step, in the process of setting the display logic for different environment variables, market research tools, user feedback systems, and data analysis platforms can be utilized to collect information such as users' behavioral data and function usage frequencies in different versions of the environment. Data mining and machine learning algorithms are employed to analyze the collected data to identify functional differences between different versions of the environment. For example, through clustering analysis, users are grouped according to versions and function usage, and the unique functions frequently used by users in each version are identified to obtain the results of functional difference analysis. A rule engine is introduced to automatically generate display logic rules corresponding to different environment variables based on the results of functional difference analysis. This rule engine can pre-set corresponding templates and conditions, and according to the pre-set templates and conditions, convert functional differences into specific display logic rules. Specifically, for scenarios of different version environments (such as Version 1, Version 2) and functional differences (hot product recommendations, personalized product recommendations, etc.), templates containing specific content are pre-set in the rule engine. This template covers parts such as environment version definition, extraction of functional difference points, and display logic design. For these parts, specific fields such as specific version number fields, functional feature fields, and display logic fields can be set to mark template information. The specific version number field is used to match the version environment, which can be "Version 1", "Version 2", etc. The functional feature field is used to record the core functions or unique functions of this version. For example, if Version 1 emphasizes "hot product recommendations", its functional feature field can be filled with "hot product recommendations", and if Version 2 focuses on "personalized product recommendations", its functional feature field can be filled with "personalized product recommendations". The display logic field is used to define the specific display method of the function on the interface, including details such as position and form. For example, for "hot product recommendations", the display logic field in the template is set as: "Display the list of hot product recommendations in the form of cards below the carousel at the top of the home page. Each product card is marked with a red label indicating 'hot', and the list supports left and right sliding for browsing", while for "personalized product recommendations", the display logic is set as: "Display the content of personalized product recommendations in the form of a waterfall flow in the middle of the home page. Associated products are preferentially displayed based on the user's browsing history, and a dynamic logo 'Recommended for You' is displayed in the lower right corner of each product". At the same time, judgment conditions for rule generation are established. These judgment conditions can include function positioning conditions, user behavior conditions, etc. Taking the function positioning condition as an example, if the function positioning of a certain version is "highlight hot product recommendations", then the condition of "display the list of hot product recommendations in the prime position on the home page" is triggered, and if it is "strengthen personalized recommendations", then the condition of "dynamically display personalized products based on user data" is triggered. Taking the user behavior condition as an example, if data analysis finds that users of a certain version frequently click on hot products, then the condition of "strengthen the display of hot product recommendation function" is triggered, and if users spend a long time staying on personalized recommendation content, then the condition of "prioritize the display of personalized recommendations" is triggered. The generated display logic rules are stored in configuration files, and these configuration files can be dynamically loaded according to the version environment.In addition, use script tools to regularly update the configuration file to ensure that the display logic is synchronized with market changes.

[0057] Exemplarily,

[0058] Display logic rules for version 1:

[0059] The template content is:

[0060] Version identifier: Version 1; Feature: Popular product recommendation; Display logic: "Below the carousel on the top of the home page, display the popular product recommendation list in the form of cards. Each product card is marked with a red 'Popular' label, and the list supports left - right sliding for browsing."

[0061] Display logic rules for version 2:

[0062] The template content is:

[0063] Version identifier: Version 2; Feature: Personalized product recommendation; Display logic: "In the middle of the home page, display the personalized product recommendation content in the form of a waterfall flow. Prioritize the display of related products based on the user's browsing history, and display a dynamic 'Recommended for You' logo in the lower right corner of each product."

[0064] In the process of setting resource reference paths for different environment variables, a resource usage monitoring tool can be integrated into the project application to collect the resource usage in different versions of the environment in real time, including images, fonts, style sheets, etc. Statistical methods such as time series analysis and regression analysis are used to establish a demand prediction model based on historical resource usage data. This demand prediction model can predict the resource demand trends in different versions of the environment in the future for a period of time, that is, obtain the resource demand assessment results. According to the resource demand assessment results, a script tool is used to automatically classify and store the resources, create independent resource directories for each version of the environment, and configure an automated alias mapping mechanism in the project application's build tools (such as Webpack, Vite, etc.). According to the resource directories of the version environment, the corresponding general reference aliases are automatically generated and updated to the build configuration file. For example, version 1 may require specific brand icons, while version 2 may require font files in different languages. Configure the resource directories and general reference aliases in the project build tool (such as Webpack or Vite). In the project application source language file, use a unified general reference alias to reference resources. For example, the general reference alias is "@assets". When the value of the environment variable env.VITE_APP_ENV is market1, its resource reference path is src / assets-market1, that is, it is dynamically mapped to src / assets-market1 through the environment variable, and its actual resource path is src / assets-market1 / logo.png. When the value of the environment variable env.VITE_APP_ENV is market2, its resource reference path is src / assets-market2, that is, it is dynamically mapped to src / assets-market2 through the environment variable, and its actual resource path is src / assets-market2 / logo.png. In this way, in different version environments, the build tool can automatically resolve to the corresponding resource directory according to the environment variable, and achieve accessing different resources with the same resource reference path in different version environments.

[0065] For the process of setting the language segmentation path according to different environment variables, performance monitoring tools such as Google Lighthouse and WebPageTest can be integrated into the project application to regularly test the application performance in different version environments, so as to collect performance metrics such as language redundancy, loading time, and memory occupancy. The language redundancy represents the proportion of languages in non-target version environments, the memory occupancy represents the minimum memory requirement of the target version environment, and the loading time represents the maximum acceptable loading time of the target version environment. Use data analysis tools for in-depth analysis. By analyzing performance bottlenecks and resource consumption, identify the key factors affecting application performance, that is, obtain the performance analysis results. Use machine learning algorithms such as decision trees and neural networks to automatically generate code segmentation strategies according to the performance analysis results. This algorithm can optimize the language segmentation granularity according to the performance requirements of different version environments. Specifically, preset the language elimination levels for different segmentation granularities, including level 0 (no deletion), level 1 (coarse-grained), and level 2 (fine-grained). Among them, level 0 means retaining all languages without deletion. Level 1 (coarse-grained) means deleting the entire directory / file, specifically deleting by folder (such as src / market2 / ). Level 2 (fine-grained) means deleting conditional language blocks within the file, specifically deleting by comment markers (such as / / MARKER:ENV=market2). Establish a mapping relationship between performance metrics and language elimination levels, that is, set corresponding thresholds for language redundancy, loading time, and memory occupancy respectively. For example, the threshold for code redundancy is 20%, the threshold for memory occupancy is 100MB, and the threshold for loading time is 1500m. Decide which language elimination strategy to use by comparing these thresholds. The decision can be made by direct comparison. For example, if the code redundancy is greater than 20%, the language elimination level is 1; if the code redundancy is less than or equal to 20%, the language elimination level is 2. If the memory occupancy is less than 100MB, the forced language elimination level is 1. If the loading time is greater than 1500ms, the forced language elimination level is 1. If there are multiple metrics reaching the thresholds, execute the language segmentation strategy corresponding to the highest language elimination level. It is also possible to set primary and secondary metrics for language redundancy, loading time, and memory occupancy on this basis. For example, regard memory occupancy and loading time as primary metrics because they directly reflect the performance bottlenecks of different version environments and have a significant impact on the running efficiency and user experience of the project application, while code redundancy is regarded as a secondary metric, which mainly affects the size of the package. When any one or both of the memory occupancy and loading time metrics reach the corresponding thresholds, directly execute the language segmentation strategy corresponding to level 1 (coarse-grained). If the primary metrics do not reach the corresponding thresholds, then determine the elimination level according to the code redundancy, that is, when the code redundancy is greater than 20%, execute the language segmentation strategy corresponding to level 1 (coarse-grained), and when the code redundancy is less than or equal to 20%, execute the language segmentation strategy corresponding to level 2 (fine-grained).Meanwhile, establish a policy evaluation mechanism to regularly evaluate the generated language segmentation policies, and adjust and optimize the language segmentation policies according to the evaluation results. For example, in version 1, the memory occupancy is 80MB, the loading time is 2200ms, and the code redundancy is 18%. Since the memory occupancy is less than 100MB and the loading time is greater than 1500ms, according to the principle of prioritizing main indicators, execute the language segmentation policy corresponding to level 2 (fine-grained), that is, directly delete the src / market2 directory and build the language only containing the src / market1 directory.

[0066] Based on the above display logic, resource reference paths, and language segmentation policies corresponding to different environment variables, corresponding conditional statements can be added to the project application source language file. These conditional statements are used to flexibly control aspects such as the display logic, resource reference paths, and language segmentation policies of relevant languages in the project application source language file according to different environment variables. That is, use conditional statements to implement the judgment and execution of different display logic, resource reference paths, and language segmentation policies. These conditional statements can be deployed using JavaScript's if-else statements or ternary operators. Specifically, a language template for conditional statements can be created in advance. According to the configuration of the display logic, resource reference paths, and language segmentation policies, define the conditional statement structures corresponding to different environment variables. A language template for conditional statements can be set in advance, and map the display logic, resource reference paths, and language segmentation policies of different environment variables into the language template to automatically generate corresponding conditional statements. For example, the language template is if(process.env.market === '{env}'){{logic}}, where {env} and {logic} are both placeholders, representing the value of the environment variable and the corresponding logic respectively. Traverse the display logic, resource reference paths, and language segmentation policies of different environment variables, and replace the value of the environment variable and the corresponding logic into the above language template to generate the corresponding conditional statement. Use a language parsing tool (such as Babel, ESLint, etc.) to parse the project application source language file, find the positions where conditional statements need to be added, and inject the generated conditional statements into the project application source language file.

[0067] Exemplarily, assume that process.env.market is an environment variable, and the display logic, resource reference paths, and language segmentation policies of market_1 and market_2 are represented by A and B respectively. Then the conditional statement can be:

[0068] if(process.env.market ==='market_1'){A};

[0069] else if (process.env.market ==='market_2') {B}。

[0070] Based on the above description, the specific execution process of determining the language construction rules corresponding to the target version environment using the target environment variable is as follows: use the conditional statements in the project application source language file to determine the target display logic, target resource reference path, and target language segmentation strategy corresponding to the target environment variable; use the target display logic, target resource reference path, and target language segmentation strategy as the language construction rules corresponding to the target version environment.

[0071] In this step, since corresponding conditional statements are added to the project application source language file for different environment variables. Therefore, during the construction process, the construction tool will parse the conditional statements in the project application source language file and execute the corresponding language logic according to the current target environment variable. For example, when process.env.MARKET is market1, the display logic of version 1, the resource reference path of version 1, and the language segmentation strategy will be executed.

[0072] Integrate the determined target display logic, target resource reference path, and target language segmentation strategy into an object as the language construction rules corresponding to the target version environment. During the construction process, the construction tool will process the project application source language file according to these language construction rules. For example, modify the rendering logic of the page according to the target display logic, replace the resource reference path in the language according to the target resource reference path, and segment and package the language according to the target language segmentation strategy.

[0073] Through the above detailed implementation methods, corresponding language construction rules can be set according to the requirements of different version environments, and the language construction rules of the target version environment can be dynamically determined and applied using the target environment variable, so as to realize the rapid generation of multi-version front-end languages and improve development efficiency.

[0074] 204. Recursively traverse the file types corresponding to the project application source language file.

[0075] In this step, the built-in fs (file system) module of Node.js can be used in combination with the path module to traverse the project directory. For complex project structures, third-party libraries such as glob can also be used, which support using wildcards to match file paths. The file types include but are not limited to JavaScript, JSX, and Vue single-file components, etc. The file type can be determined by obtaining the file extension through the path module.

[0076] 205. Parse the project application source language file according to the parsing method corresponding to the file type to obtain the abstract syntax tree corresponding to the project application source language file.

[0077] In this step, a corresponding parsing method is set for each file type in advance. This parsing method is used to convert the project application source language files of different file types into abstract syntax trees for subsequent operations. For example, @babel / parser is used to parse JavaScript and JSX files, and @vue / compiler-sfc is used to parse Vue single-file components. Specifically, it can be achieved by maintaining a correspondence table between file types and parsing methods.

[0078] 206. Modify the abstract syntax tree according to the target display logic, target resource reference path, and target language segmentation strategy, and generate the target source language file based on the modified abstract syntax tree.

[0079] It should be noted that the specific execution process of modifying the abstract syntax tree according to the target display logic, target resource reference path, and target language segmentation strategy and generating the target source language file based on the modified abstract syntax tree is as follows: Determine the target node corresponding to the target environment variable among all nodes of the abstract syntax tree; Remove other nodes except the target node according to the target language segmentation strategy, and modify the content of the target node according to the target display logic and target resource reference path to obtain the modified abstract syntax tree; Convert the modified abstract syntax tree into the language format of the corresponding file type to obtain the target source language file.

[0080] In this step, traverse all nodes of the abstract syntax tree and determine the target node corresponding to the target environment variable among all nodes. Modify the language of the target node related to display according to the target display logic. For example, if the target display logic requires hiding a specific component on a certain page, it can be achieved by modifying the component rendering node in the AST. Find the nodes related to resource references in the AST and replace the resource reference path with the target resource reference path. According to the target language segmentation strategy, remove other nodes except the target node from the AST. That is, the abstract syntax tree is modified accordingly through the target display logic, target resource reference path, and target language segmentation strategy. For the JavaScript language, @babel / generator can be used to convert the modified AST into the source language to obtain the target source language file. For Vue single files, the modified <script>部分重新插入到Vue单文件组件中，并保存为新的文件，得到目标源语言文件。

[0081] 示例性的，

[0082] 对于js文件：

[0083] 使用fs.readFileSync读取指定文件的内容，使用@babel / parser解析JavaScript语言，生成抽象语法树(AST)。使用@babel / traverse遍历AST，加入需要生成版本1的源码，需要删除env.VITE_APP_ENV＝＝＝market2相关逻辑的语言。使用@babel / generator将修改后的AST生成新的语言，即目标源语言文件。

[0084] 对于vue单文件：

[0085] 读取文件内容：使用fs.readFileSync读取指定文件的内容，使用@vue / compiler-sfc解析VueSFC，获取模板、脚本和样式的AST。移除template模板中包含v-if＝VITE_APP_ENV＝＝＝market2的节点。解析单文件SFC解析出来的js脚本，处理与上述js文件一样，对于样式，不需要特殊处理，将处理后的模板、脚本和样式再拼接成完整的SFC(单文件组件)，得到目标源语言文件。

[0086] 根据上述的详细实施方式，通过确定目标节点，并将除目标节点外的其他节点移除，可以显著减少语言量，去除那些在目标版本环境下不需要的语言，即减少了冗余语言，降低语言的复杂度，有助于后续的开发和维护。依据目标展示逻辑对目标节点进行内容修改，能够确保应用在目标版本环境下准确展示所需的功能，提高用户体验，根据目标资源引用路径对目标节点进行内容修改，能保证应用在目标版本环境下正确引用所需的资源，实现资源的精准适配。在网络条件较差的情况下，由于移除了无关语言，以及限定了展示逻辑和资源引用路径，使得应用在运行过程中更加高效，加载速度加快，有效减少用户等待时间，提高用户满意度。且基于AST修改的方式使得应用能够根据不同的目标环境进行灵活定制，开发者只需要修改目标展示逻辑、目标资源引用路径和目标语言分割策略，就可以轻松实现不同市场环境下的应用定制，而不需要对语言进行大规模的重构，使得应用更易于维护。

[0087] 进一步的，为了减少目标源语言文件的体积，提高其在目标版本环境下的运行速度。可以在抽象语法树的所有节点中确定目标环境变量对应的目标节点之后，具体还包括：获取目标节点对应的语言逻辑以及各目标节点之间的依赖关系；将语言逻辑为死语言的目标节点作为无用节点，并根据依赖关系确定无用节点是否符合安全移除标准；若是，则将无用节点移除。

[0088] 本步骤中，使用静态分析工具来获取目标节点对应的语言逻辑以及各目标节点之间的依赖关系。例如，对于JavaScript语言，可以使用eslint或tslint等工具的底层分析能力。将语言逻辑为死语言的目标节点作为无用节点，并根据依赖关系确定无用节点是否符合安全移除标准，该安全移除标准具体指被移除的节点没有被其他任何节点引用、且不影响全局状态，以及被移除的节点在移除时不会破坏代码的逻辑完整性。该逻辑完整性的判断可以通过模拟代码执行过程，检查移除节点后是否会导致条件判断、循环等逻辑出现错误。例如，如果一个函数没有被其他任何函数调用，且不影响全局状态，那么可以认为它是无用节点。若是无用节点，则将其移除，反之则保留。

[0089] 通过上述的详细实施方式，由于死语言是指在程序执行过程中永远不会被调用或执行的语言，移除这些无用的语言可以显著减小最终生成的目标源语言文件的体积，而更小的语言体积意味着更快的文件下载速度，尤其是在网络条件较差的情况下，能够有效减少用户等待页面加载的时间，提升用户体验。并且移除无用节点后，后续生成的目标源语言文件的执行路径更加简洁，减少不必要的计算和资源消耗，进而提高项目应用在目标版本环境下的运行速度。

[0090] 进一步的，为了在开发阶段实现项目应用在不同版本环境下的灵活启动和配置，具体还包括：根据多版本部署需求，将不同版本环境各自对应的环境变量分别注入项目应用源语言文件的启动命令中。

[0091] 本步骤结合上述方法101步骤中关于打包命令的描述，在将环境变量注入打包命令的同时，根据多版本部署需求，为每个版本环境设置独立的启动命令，以使这些启动命令可以正确加载相应的环境变量，实现相应的访问行为。

[0092] 使用如Webpack、Vite等构建工具配置文件中进行环境变量的注入。以Vite为例，在vite.config.js文件中，可以使用define选项来定义环境变量。也可以在项目的package.json文件中定义不同的打包命令，并在命令中注入环境变量。环境变量可以是用于标识不同版本的字符串。例如，VITE_APP_ENV＝market1或VITE_APP_ENV＝market2。

[0093] 示例性的，

[0094] "dev:market1":"cross-env VITE_APP_ENV＝market1 vite serve",

[0095] "dev:market2":"cross-env VITE_APP_ENV＝market2 vite serve"。

[0096] 进一步的，作为对上述图1-2所示方法实施例的实现，本申请实施例提供了一种基于环境变量的多版本前端语言生成装置，该装置用于减少开发和维护的成本，避免语言重复和管理复杂度的增加，从而提高开发效率。该装置的实施例与前述方法实施例对应，为便于阅读，本实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述方法实施例中的全部内容。具体如图3所示，该装置包括：

[0097] 注入单元31，用于根据项目应用对应的多版本部署需求，将不同版本环境各自对应的环境变量分别注入项目应用源语言文件的打包命令中；

[0098] 读取单元32，用于当运行目标打包命令时，读取所述注入单元31得到的所述目标打包命令中的目标环境变量，所述目标环境变量对应的目标版本环境；

[0099] 确定单元33，用于利用所述读取单元32得到的所述目标环境变量确定所述目标版本环境对应的语言构建规则，所述语言构建规则包括目标展示逻辑、目标资源引用路径以及目标语言分割策略；

[0100] 处理单元34，用于依据所述确定单元33得到的所述目标展示逻辑、所述目标资源引用路径以及所述目标语言分割策略对所述项目应用源语言文件进行处理，生成所述目标版本环境对应的目标源语言文件。

[0101] 进一步的，如图4所示，

[0102] 所述注入单元31，还用于根据所述多版本部署需求，将不同所述版本环境各自对应的所述环境变量分别注入所述项目应用源语言文件的启动命令中。

[0103] 进一步的，如图4所示，所述装置还包括：

[0104] 第一设定单元35，用于在所述确定单元33之前，根据不同所述版本环境之间的功能差异设定不同所述环境变量对应的展示逻辑；

[0105] 第二设定单元36，用于根据不同所述版本环境的资源需求设定不同所述环境变量对应的资源引用路径，所述资源引用路径由不同所述环境变量对应的资源目录和通用引用别名构成；

[0106] 第三设定单元37，用于根据不同所述版本环境的性能分析结果设定不同所述环境变量对应的语言分割策略；

[0107] 添加单元38，用于基于所述第一设定单元35得到的所述展示逻辑、所述第二设定单元36得到的所述资源引用路径以及所述第三设定单元37得到的所述语言分割策略，在所述项目应用源语言文件中添加不同所述环境变量对应的条件语句。

[0108] 进一步的，如图4所示，所述确定单元33，包括：

[0109] 确定模块331，用于利用所述项目应用源语言文件中的所述条件语句确定所述目标环境变量对应的所述目标展示逻辑、所述目标资源引用路径以及所述目标语言分割策略；

[0110] 构成模块332，用于将所述确定模块331得到的所述目标展示逻辑、所述目标资源引用路径以及所述目标语言分割策略作为所述目标版本环境对应的所述语言构建规则。

[0111] 进一步的，如图4所示，所述处理单元34，包括：

[0112] 遍历模块341，用于递归遍历所述项目应用源语言文件对应的文件类型；

[0113] 解析模块342，用于递归遍历根据所述遍历模块341得到的所述文件类型对应的解析方式对所述项目应用源语言文件进行解析，得到所述项目应用源语言文件对应的抽象语法树；

[0114] 处理模块343，用于依据所述目标展示逻辑、所述目标资源引用路径以及所述目标语言分割策略对所述解析模块342得到的所述抽象语法树进行修改，并基于修改后的抽象语法树生成所述目标源语言文件。

[0115] 进一步的，如图4所示，所述处理模块343，具体用于，

[0116] 在所述抽象语法树的所有节点中确定所述目标环境变量对应的目标节点；

[0117] 依据所述语言分割策略将除所述目标节点外的其他节点移除，依据所述展示逻辑和所述资源引用路径对所述目标节点进行内容修改，得到所述修改后的抽象语法树；

[0118] 将所述修改后的抽象语法树转换为语言格式，得到所述目标源语言文件。

[0119] 进一步的，如图4所示，所述装置还包括：

[0120] 在所述抽象语法树的所有节点中确定所述目标环境变量对应的目标节点之后，获取所述目标节点对应的语言逻辑以及各所述目标节点之间的依赖关系；

[0121] 将所述语言逻辑为死语言的目标节点作为无用节点，并根据所述依赖关系确定所述无用节点是否符合安全移除标准；

[0122] 若是，则将所述无用节点移除。

[0123] 进一步的，本申请实施例还提供一种存储介质，所述存储介质用于存储计算机程序，其中，所述计算机程序运行时控制所述存储介质所在设备执行上述图1-2中所述的基于环境变量的多版本前端语言生成方法。

[0124] 进一步的，本申请实施例还提供一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述图1-2中所述的基于环境变量的多版本前端语言生成方法。

[0125] 在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

[0126] 可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的"第一”、"第二”等是用于区分各实施例，而并不代表各实施例的优劣。

[0127] 所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

[0128] 在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

[0129] 此外，存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和 / 或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

[0130] 本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序语言的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

[0131] 本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和 / 或方框图来描述的。应理解可由计算机程序指令实现流程图和 / 或方框图中的每一流程和 / 或方框、以及流程图和 / 或方框图中的流程和 / 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能的装置。

[0132] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能。

[0133] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能的步骤。

[0134] 在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入 / 输出接口、网络接口和内存。

[0135] 存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和 / 或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

[0136] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

[0137] 还需要说明的是，术语"包括”、"包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句"包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

[0138] 本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序语言的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

[0139] 以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。< / script>

Claims

1. A method for generating a multi-version front-end language based on environment variables, characterized in that: The method comprises: According to the multi-version deployment requirements of the project application, the environment variables corresponding to different version environments are injected into the packaging commands of the project application source language files respectively; When the target packaging command is executed, the target environment variable in the target packaging command is read, and the target version environment corresponding to the target environment variable; Determine the language construction rules corresponding to the target version environment by using the target environment variables, wherein the language construction rules include target display logic, target resource reference path and target language segmentation strategy; The project application source language file is processed according to the target display logic, the target resource reference path and the target language segmentation strategy to generate a target source language file corresponding to the target version environment.

2. The method according to claim 1, characterized in that The method further comprises: According to the multi-version deployment requirements, the environment variables corresponding to the different version environments are respectively injected into the startup commands of the project application source language files.

3. The method according to claim 1, characterized in that Before using the target environment variable to determine the language construction rule corresponding to the target version environment, the method further includes: Setting display logic corresponding to different environment variables according to functional differences between different version environments; Setting resource reference paths corresponding to different environment variables according to resource requirements of different version environments, wherein the resource reference paths are composed of resource directories and universal reference aliases corresponding to different environment variables; Setting language segmentation strategies corresponding to different environment variables according to performance analysis results of different version environments; Based on the display logic, the resource reference path and the language segmentation strategy, conditional statements corresponding to different environment variables are added in the project application source language file.

4. The method according to claim 3, characterized in that Determining the language construction rules corresponding to the target version environment by using the target environment variable includes: Determine the target display logic, the target resource reference path, and the target language segmentation strategy corresponding to the target environment variable by using the conditional statement in the project application source language file; The target presentation logic, the target resource reference path, and the target language segmentation strategy are used as the language construction rules corresponding to the target version environment.

5. The method according to claim 1, characterized in that Processing the project application source language file according to the display logic, the resource reference path, and the language segmentation strategy to generate a target application source language file corresponding to the target version environment includes: Recursively traverse the file types corresponding to the project application source language files; Parsing the project application source language file according to the parsing method corresponding to the file type to obtain an abstract syntax tree corresponding to the project application source language file; The abstract syntax tree is modified according to the target presentation logic, the target resource reference path and the target language segmentation strategy, and the target source language file is generated based on the modified abstract syntax tree.

6. The method according to claim 5, characterized in that Modifying the abstract syntax tree according to the target presentation logic, the target resource reference path, and the target language segmentation strategy, and generating the target source language file based on the modified abstract syntax tree, including: Determine a target node corresponding to the target environment variable among all nodes of the abstract syntax tree; Removing nodes other than the target node according to the target language segmentation strategy, modifying the content of the target node according to the target presentation logic and the target resource reference path, and obtaining the modified abstract syntax tree; The modified abstract syntax tree is converted into a language format corresponding to the file type to obtain the target source language file.

7. The method according to claim 6, characterized in that After determining the target node corresponding to the target environment variable among all nodes of the abstract syntax tree, the method further includes: Obtaining the language logic corresponding to the target node and the dependency relationship between the target nodes; The target node whose language logic is a dead language is regarded as a useless node, and whether the useless node meets the safety removal standard according to the dependency relationship; If so, remove the useless node.

8. A multi-version front-end language generation device based on environment variables, characterized in that: The device comprises: The injection unit is used to inject the environment variables corresponding to different version environments into the packaging commands of the source language files of the project application according to the multi-version deployment requirements corresponding to the project application; A reading unit, used for reading a target environment variable in the target packaging command obtained by the injection unit when running the target packaging command, and a target version environment corresponding to the target environment variable; A determination unit, configured to determine a language construction rule corresponding to the target version environment by using the target environment variable obtained by the reading unit, wherein the language construction rule includes a target display logic, a target resource reference path, and a target language segmentation strategy; The processing unit is used to process the project application source language file according to the target display logic, the target resource reference path and the target language segmentation strategy obtained by the determination unit to generate a target source language file corresponding to the target version environment.

9. A storage medium, characterized in that: The storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the multi-version front-end language generation method based on environment variables as described in any one of claims 1 to 7.

10. A processor, characterized in that: The processor is used to run a program, wherein the program, when running, executes the method for generating a multi-version front-end language based on environment variables as described in any one of claims 1 to 7.

Images