Project code dynamic sharing method and device, equipment and storage medium

Abstract

The invention discloses a project code dynamic sharing method and device, equipment and a storage medium, and relates to the technical field of computers. The method comprises the steps of obtaining a shared code file of a first project according to a preset configuration file in a process that the first project runs a construction command, and storing the shared code file to a static folder of the first project; receiving a first file sharing request sent by a second item, and obtaining a corresponding first shared code file in the static folder according to a first file name in the first file sharing request; and sending the first shared code file to the second item, so that the second item dynamically compiles or dynamically runs the first shared code file. By means of the technical means, dynamic sharing and multiplexing of code resources can be achieved on the premise that the project is not configured with a Webpack tool, the problem that in the prior art, the code resources are shared by depending on a module federated plug-in provided by the Webpack tool is solved, and the development and operation complexity of a small project is effectively reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and storage medium for dynamically sharing project code. Background Technology

[0002] Module Federation is a modern front-end architecture technology designed to enable dynamic code sharing and reuse across projects and applications. The core idea of ​​Module Federation is to dynamically load remote modules at runtime, allowing multiple independently built applications or projects to share code resources such as components, libraries, and business logic on demand. This allows different projects to maintain independent development and deployment while achieving fine-grained resource sharing. Module Federation technology significantly improves front-end development efficiency and reduces maintenance costs for multi-team collaborations, and has become an important technical tool in modern distributed front-end development.

[0003] In existing technologies, Webpack 5's module federation plugin enables multiple front-end applications to dynamically share code modules at runtime. Specifically, the remote application's Webpack tool exposes the shared code modules through the `exposes` field of the module federation plugin, while the host application's Webpack tool specifies the remote application and its entry file through the `remotes` field of the module federation plugin. The host application can then retrieve and execute the shared code modules from the remote application's entry file. While Webpack 5's module federation plugin offers comprehensive functionality, it requires developers to simultaneously build and maintain complex Webpack tools across multiple projects. Developers need a deep understanding of Webpack's technical details and the module federation plugin's operating mechanism, making the construction, configuration, and maintenance of Webpack tools quite complex. For small projects, most of Webpack's features are redundant, but Webpack inevitably increases the development and runtime complexity of small projects, impacting development efficiency and increasing operating costs. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for dynamically sharing project code. It specifies the shared code of a local project through a configuration file and copies the shared code to a static folder during the local project's operation. External projects can access the shared code in the static folder and dynamically compile or run the accessed shared code. It can achieve dynamic sharing and reuse of code resources even without configuring the Webpack tool in the project. It solves the problem of sharing code resources by relying on the module federation plugin provided by the Webpack tool in the prior art, and effectively reduces the development and running complexity of small projects.

[0005] Firstly, this application provides a method for dynamically sharing project code, including: During the process of running the build command in the first project, the shared code file of the first project is obtained according to the preset configuration file, and the shared code file is stored in the static folder of the first project; Receive a first file sharing request sent by the second project, and obtain the corresponding first shared code file in the static folder according to the first file name in the first file sharing request; The first shared code file is sent to the second project so that the second project can dynamically compile or run the first shared code file.

[0006] Secondly, this application provides a dynamic sharing device for project code, comprising: The code storage module is configured to retrieve the shared code file of the first project according to a preset configuration file during the process of running the build command of the first project, and store the shared code file in the static folder of the first project. The code acquisition module is configured to receive a first file sharing request sent by the second project, and to obtain the corresponding first shared code file in the static folder according to the first file name in the first file sharing request. The code-sharing module is configured to send the first shared code file to the second project, so that the second project can dynamically compile or run the first shared code file.

[0007] Thirdly, this application provides a dynamic sharing device for project code, comprising: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the dynamic sharing method of project code as described in the first aspect.

[0008] Fourthly, this application provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a dynamic sharing method of project code as described in the first aspect.

[0009] In this application, during the build process, the local project obtains a shared code file that can be shared with external projects based on a configuration file and stores it in a local static folder for external projects to access. Upon receiving an access request from an external project, the local project retrieves the first shared code file required by the external project from the static folder and sends it to the external project. The external project then dynamically compiles or runs the first shared code file. Through this technical approach, the local project can share its code externally by copying the shared code specified in the configuration file to the static folder, and the external project can reuse the code by requesting access to the shared code in the local project's static folder. Neither the local nor the external project needs to configure Webpack. Dynamic sharing and reuse of code resources can be achieved even without configuring Webpack, solving the problem of relying on Webpack's module federation plugin for sharing code resources in existing technologies, and effectively reducing the development and running complexity of small projects. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a method for dynamically sharing project code provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the process of obtaining and storing shared code files as provided in an embodiment of this application; Figure 3 This is a flowchart of the authentication process for the second item provided in an embodiment of this application; Figure 4 This is a flowchart of obtaining the first shared code file in a static folder, provided in an embodiment of this application; Figure 5 This is a schematic diagram illustrating the communication process between the first and second items provided in an embodiment of this application; Figure 6 This is a flowchart illustrating how a first project accesses a shared code file of an external project, as provided in an embodiment of this application. Figure 7 A schematic diagram of the structure of a dynamic sharing device for project code provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a dynamic sharing device for project code provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. A process can be terminated when its operation is completed, but it may also have additional steps not included in the drawings. A process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0012] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0013] In common existing implementations, the shared code modules are exposed in the local project's Webpack tool via the `exposes` field of the module federation plugin, while in the external project's Webpack tool, the local project and its entry file are specified via the `remotes` field of the module federation plugin. The external project can then retrieve and execute the shared code modules from the local project's entry file. While Webpack 5's module federation plugin offers comprehensive functionality, it requires developers to simultaneously build and maintain complex Webpack tools across multiple projects. Developers need a deep understanding of the technical details of Webpack and the operating mechanism of the module federation plugin, making the construction, configuration, and maintenance of Webpack tools quite complex. For small projects, most of Webpack's features are redundant, but Webpack inevitably increases the development and runtime complexity of small projects, impacting development efficiency and increasing operating costs.

[0014] To address the aforementioned issues, this embodiment provides a method for dynamically sharing project code. This method allows specifying shared code within a local project through a configuration file. During the local project's execution, the shared code is copied to a static folder. External projects can access the shared code in the static folder and dynamically compile or run it. This achieves dynamic sharing and reuse of code resources even without configuring Webpack, effectively reducing the development and runtime complexity of small projects. Here, a local project refers to a project with the ability to dynamically share code, while an external project refers to a project with the ability to reuse the shared code.

[0015] The dynamic sharing method for project code provided in this embodiment can be executed by a dynamic sharing device for project code. This dynamic sharing device can be implemented through software and / or hardware. The dynamic sharing device can consist of two or more physical entities, or it can consist of a single physical entity. For example, the dynamic sharing device for project code can be a computer device running a local project, or it can be a project runtime system consisting of a local project and an external project.

[0016] The dynamic sharing device for project code has at least one type of operating system installed, including but not limited to Android, Linux, and Windows. The dynamic sharing device for project code can have at least one application installed on the operating system. This application can be a built-in application of the operating system or an application downloaded from a third-party device or server. In this embodiment, the dynamic sharing device for project code has at least one application capable of executing the dynamic sharing methods of the project code. For example, if the local project is the application that executes the dynamic sharing methods of the project code, then the dynamic sharing device for the project code can also be the local project.

[0017] For ease of understanding, this embodiment uses a local project as the main example to describe the dynamic sharing method for executing project code.

[0018] Figure 1 A flowchart of a dynamic code sharing method for projects provided in an embodiment of this application is given. (Reference) Figure 1 The dynamic code-sharing methods for this project specifically include: S110. During the process of running the build command in the first project, the shared code file of the first project is obtained according to the preset configuration file, and the shared code file is stored in the static folder of the first project.

[0019] The first project is a local project that executes dynamically shared methods of the project code. The configuration file indicates which code files in the first project can be shared externally; that is, the configuration file contains the file storage path and filename of the shared code files within the first project. For example, the developer of the first project can create a JavaScript file while developing the project. This JavaScript file contains the file storage path and filename of the shared code files in the first project, and it serves as the configuration file for the first project.

[0020] When the first project runs the build command (such as npm run build), during the build process, the first project parses the configuration file to obtain the file storage path and file name of the shared code file. Based on the file storage path and file name of the shared code file, the first project copies the shared code file to the static folder of the first project. The files in the static folder can be accessed by external projects.

[0021] Optional, Figure 2 This is a flowchart illustrating the acquisition and storage of shared code files provided in an embodiment of this application. For example... Figure 2 As shown, the steps for acquiring and storing shared code files specifically include S1101-S1102: S1101. Based on the file storage path and file name in the preset configuration file, retrieve the corresponding shared code file in the directory corresponding to the first project.

[0022] For example, the first project parses the configuration file to obtain the associated file storage path and file name. The shared code file corresponding to the file name is stored in the file directory indicated by the associated file storage path. The first project can retrieve the shared code file corresponding to the file name in the corresponding directory based on the file storage path.

[0023] S1102. Based on the folder name associated with the file name in the configuration file, store the obtained shared code file to the corresponding static folder.

[0024] For example, in addition to indicating which code files are shared code files, the configuration file also indicates which static folder these code files are stored in, so that when external projects access shared code files later, they can retrieve the shared code files from the corresponding static folder based on the folder name associated with the file name in the configuration file, thereby improving the access speed of shared code files.

[0025] The configuration file associates the filename of the shared code file with the folder name of the corresponding static folder to instruct the shared code file to be stored in the associated static folder. Accordingly, when the first project copies the shared code file to the static folder, it parses the folder name associated with the shared code file name in the configuration file and stores the shared code file in the static folder corresponding to that associated folder name.

[0026] This embodiment defines the folder name of the static folder where each shared code file is stored in the configuration file. This allows external projects to quickly locate the static folder where the shared code file is located when accessing the shared code file in the future, thereby quickly accessing the shared code file in the static folder and improving the access speed of the shared code file.

[0027] S120. Receive the first file sharing request sent by the second project, and obtain the corresponding first shared code file in the static folder according to the first file name in the first file sharing request.

[0028] The second project is an external project with shared code reuse capabilities. The first shared code file is the shared code file that the second project wants to access in the first project. The first filename is the filename of the first shared code file. The first file share request is the instruction used by the second project to request the shared code file from the first project. When the second project needs to use the shared code file from the first project during its operation, it can generate a first file share request based on the filename of the required shared code file. After receiving the first file share request, the first project parses the first filename from the first file share request and retrieves the corresponding first shared code file from the static folder based on the first filename.

[0029] Optionally, to ensure the security and confidentiality of the shared code files of the first project, these files can only be shared with external projects that have reuse rights. The developers have added project identifiers for each external project to which each shared code file can be shared in the configuration file. Upon receiving a file-sharing request, the first project can authenticate the second project according to the configuration file to determine its eligibility to access the shared code files. If the second project is not qualified, the first project will refuse to send the shared code files; if the second project is qualified, the shared code files will be sent. For example, Figure 3 This is a flowchart illustrating the authentication process for the second item provided in an embodiment of this application. For example... Figure 3 As shown, the authentication process for the second item specifically includes steps S1201-S1204: S1201. Obtain the project identifier of the second project in the first file sharing request.

[0030] For example, after receiving a first file sharing request from a second project, the first project parses the project identifier of the second project from the first file sharing request.

[0031] S1202. Match the project identifier of the second project with the project identifier of the shared project in the configuration file.

[0032] Here, the shared project is the project identifier of the external project that can access the shared code file, as indicated in the configuration file. The project identifier of the second project is matched with the project identifiers of each shared project in the configuration file. If the match is successful, it is confirmed that the second project is an external project that can access the shared code file of the first project. If the match fails, it is confirmed that the second project is not an external project that can access the shared code file of the first project.

[0033] Optionally, confidentiality agreements may also exist between different external projects. To further enhance the confidentiality and security of shared code files, a project identifier for each shared code file can be specified in the configuration file. This means that the filename of the shared code file can be associated with and saved in the configuration file with the corresponding shared project identifier. The first project parses the project identifier of the second project and the first filename of the required first shared code file from the first file sharing request. Based on the first filename, it retrieves the project identifier of the corresponding shared project from the configuration file. It then matches the project name of the second project with the project identifier of the shared project. If the match is successful, the second project is confirmed as an external project that can access the first shared code file; if the match fails, the second project is confirmed as not an external project that can access the first shared code file.

[0034] S1203. If the project identifier of the second project does not match the project identifier of the shared project, a sharing rejection response is sent to the second project.

[0035] For example, when the project identifier of the second project does not match the project identifier of the shared project, i.e., the match fails, the first project sends a share denial response to the second project to notify the second project that it cannot access the required first shared code file.

[0036] S1204. If the project identifier of the second project matches the project identifier of the shared project, then obtain the corresponding first shared code file in the static folder according to the file name in the file sharing request.

[0037] For example, when the project identifier of the second project matches the project identifier of the shared project, i.e., when the match is successful, the first project retrieves the first shared code file in the static folder based on the first file name of the first shared code file.

[0038] This embodiment verifies whether the second project is qualified to access the shared code files of the first project by using the project identifier of the second project and the project identifier of the shared project in the configuration file. If the second project is not qualified to access the shared code files, access to the shared code files will be denied, thus ensuring the security and confidentiality of the shared code files.

[0039] Furthermore, Figure 4 This is a flowchart illustrating the process of obtaining a first shared code file in a static folder, as provided in an embodiment of this application. Figure 4 As shown, the step of obtaining the first shared code file in the static folder includes S1205-S1206: S1205. Based on the first file name in the first file sharing request, determine the name of the first folder associated with the first file name in the configuration file.

[0040] For example, if the first project has multiple static folders, in order to improve the query efficiency of the first shared code file, the name of the first folder associated with the first file name of the first shared code file can be determined in the configuration file. The static folder corresponding to the first folder name is the static folder where the first shared code file is stored.

[0041] S1206. Based on the name of the first folder, retrieve the first shared code file corresponding to the first file name in the corresponding static folder.

[0042] For example, after determining the name of the first folder associated with the first file name in the configuration file, the first shared code file is obtained in the static folder corresponding to the first folder name.

[0043] This embodiment quickly locates the static folder where the first shared code file is stored by querying the name of the first folder associated with the first file name of the first shared code file in the configuration file, and then obtains the first shared code file in the static folder, thereby improving the access efficiency of the first shared code file.

[0044] S130. Send the first shared code file to the second project so that the second project can dynamically compile or run the first shared code file.

[0045] For example, after obtaining the first shared code file, the first project generates a response to the first file sharing request based on the first shared code file, and sends this response to the second project. The second project then obtains the first shared code file from the response, dynamically compiles the first shared code file, and runs the first shared code file after compilation. It should be noted that since the second project obtains the first shared code file during runtime, it can reuse the first shared code file through dynamic compilation or dynamic execution.

[0046] For example, if the first shared code file is a Vue file, the second project dynamically compiles the Vue file using the Vue Compiler. The Vue Compiler (Vue.compile) is the underlying API of the Progressive JavaScript framework, and one of its functions is to dynamically compile HTML template strings into executable rendering functions. Therefore, during runtime, the second project can use the Vue Compiler to dynamically compile the code in the Vue file accessed by the first project into an executable rendering function, and then execute that rendering function to achieve Vue file reuse.

[0047] With the first shared code file being a JavaScript file, the second project dynamically runs the JavaScript file using the `eval` function. The `eval` function is a global function in JavaScript used to dynamically execute strings as code. Therefore, during runtime, the second project can compile the code from the JavaScript file accessed by the first project into a string, and then dynamically execute that string using the `eval` function to achieve reuse of the JavaScript file.

[0048] This embodiment uses the Vue encoder to dynamically compile Vue files as shared code files and the eval function to dynamically execute JavaScript files as shared code files. The Vue encoder and the eval function are respectively the underlying methods of the Vue framework and the built-in functions of the JavaScript framework. The second project does not need to use additional tools or plugins for dynamic compilation or execution, which simplifies the reuse process of shared code files and enables rapid reuse of shared code.

[0049] Understandably, for local projects sharing code, they only need to load a pre-configured configuration file to copy the shared code to a static folder and respond to the shared code access request sent by the external project to share the shared code in the static folder with the external project. Local projects can achieve code sharing without installing Webpack, effectively simplifying the local project development process. Moreover, local projects do not need to load Webpack during runtime, allowing for lightweight operation and avoiding resource waste. For external projects reusing shared code, they only need to access the shared code through a shared code access request and dynamically compile the shared code using the Vue encoder or dynamically run the shared code using the eval function. External projects can also achieve code reuse without installing Webpack, effectively simplifying the external project development process. Moreover, external projects do not need to load Webpack during runtime, allowing for lightweight operation and avoiding resource waste.

[0050] Optionally, the first file-sharing request is an HTTP request, and the response generated based on the first file-sharing request is an HTTP response. The first project can generate an HTTP response corresponding to the HTTP request based on the first shared code file; and send the HTTP response to the second project so that the second project can retrieve the first shared code file from the HTTP response. For example, Figure 5 This is a schematic diagram illustrating the communication process between the first and second items provided in an embodiment of this application. For example... Figure 5 As shown, the second project generates an HTTP request carrying the first filename of the required first shared code file and sends the HTTP request to the first project. Upon receiving the HTTP request, the first project parses the first filename from the request, retrieves the first shared code file from the static folder based on the first filename, generates an HTTP response carrying the first shared code file, and sends the HTTP response to the second project. Upon receiving the HTTP response, the second project parses the first shared code file from the response, dynamically compiles the first shared code file, runs the compiled code, and sends the execution result of the first shared code file to the first project. This allows the second project to request the first project to resend the first shared code file if the execution fails, thus improving the success rate of code sharing.

[0051] In one embodiment, the first project, in addition to having the function of sharing code externally, also has the function of accessing shared code provided by external projects. The process of accessing the shared code of external projects is similar to the process of the second project accessing the shared code of the first project. For example, Figure 6 This is a flowchart illustrating how a first project accesses shared code files of an external project, as provided in an embodiment of this application. For example... Figure 6As shown, the steps for the first project to access the shared code files of an external project specifically include S1401-S1402: S1401. Generate a second file sharing request based on the preset second file name, and send the second file sharing request to the third project so that the third project can obtain the second shared code file corresponding to the second file name in the corresponding static folder according to the second file sharing request, and send the second shared code file to the first project.

[0052] In this system, the second filename is the name of the shared code file of the external project required by the first project, and the third project is the external project accessed by the first project. The second file-sharing request is the instruction used by the first project to request the shared code file of the third project. The first project generates a second file-sharing request carrying the second filename. This request is sent to the third project. The third project parses the second filename from the request, retrieves the corresponding second shared code file from its local static folder, generates a request response carrying the second shared code file, and sends the response to the first project. Optionally, the second file-sharing request and response can be HTTP requests and responses.

[0053] It should be noted that, like the first project, the third project has the function of sharing code externally. During the execution of the build command, it loads the preset configuration information to copy the local shared code files to the static folder, so that the first project or other external projects can access the shared code files in the static folder of the third project via HTTP.

[0054] S1402: Receive the second shared code file sent by the third project, and dynamically compile or run the second shared code file.

[0055] For example, after receiving the request response from the third project, the first project parses out the second shared code file from the request response, dynamically compiles the second shared code file, and runs the second shared code file after compilation, thereby realizing the reuse of the second shared code file.

[0056] Optionally, the shared code files can be of different types, such as Vue files or JavaScript files. The first project uses different dynamic compilation methods for different types of code files.

[0057] For example, when the second shared code file is a Vue file, it is dynamically compiled using the Vue Encoder. During runtime, the first project can use the Vue Encoder to dynamically compile the code in the Vue file accessed by the third project into an executable rendering function, and then execute the rendering function to achieve reuse of the Vue file. When the second shared code file is a JavaScript file, it is dynamically executed using the eval function. During runtime, the first project can compile the code in the JavaScript file accessed by the third project into a string, and then dynamically execute the string using the eval function to achieve reuse of the JavaScript file. This embodiment dynamically compiles the Vue file (as a shared code file) using the Vue Encoder and dynamically executes the JavaScript file (as a shared code file) using the eval function. The Vue Encoder and the eval function are respectively a low-level method of the Vue framework and a built-in function of the JavaScript framework. The first project does not need to use additional tools or plugins for dynamic compilation or execution, simplifying the reuse process of shared code files and achieving rapid reuse of shared code.

[0058] In summary, the dynamic code sharing method provided in this application involves the local project obtaining a shared code file that can be shared with external projects based on a configuration file during the build command execution process. This shared code file is then stored in a local static folder for access by external projects. Upon receiving an access request from an external project, the method retrieves the required first shared code file from the static folder and sends it to the external project. The external project then dynamically compiles or runs the first shared code file. Through these techniques, the local project can share its code externally by copying the shared code specified in the configuration file to the static folder, while the external project can reuse the code by requesting access to the shared code in the local project's static folder. Neither the local nor the external project needs to configure Webpack. Dynamic sharing and reuse of code resources can be achieved even without configuring Webpack, solving the problem of relying on Webpack's module federation plugin for sharing code resources in existing technologies, and effectively reducing the development and running complexity of small projects.

[0059] Based on the above embodiments, Figure 7 This is a schematic diagram of a dynamic sharing device for project code provided in an embodiment of this application. (Reference) Figure 7 The dynamic sharing device for project code provided in this embodiment specifically includes: a code storage module 21, a code acquisition module 22, and a code sharing module 23.

[0060] Among them, the code storage module 21 is configured to obtain the shared code file of the first project according to the preset configuration file during the process of running the build command of the first project, and store the shared code file in the static folder of the first project; The code acquisition module 22 is configured to receive the first file sharing request sent by the second project, and obtain the corresponding first shared code file in the static folder according to the first file name in the first file sharing request; Code sharing module 23 is configured to send a first shared code file to a second project so that the second project can dynamically compile or run the first shared code file.

[0061] Based on the above embodiments, the code storage module 21 includes: a shared code copying unit, configured to obtain the corresponding shared code file in the directory corresponding to the first project according to the file storage path and file name in the preset configuration file; and a shared code storage unit, configured to store the obtained shared code file in the corresponding static folder according to the folder name associated with the file name in the configuration file.

[0062] Based on the above embodiments, the code acquisition module 22 includes: a project identifier acquisition unit, configured to acquire the project identifier of the second project in the first file sharing request after receiving the first file sharing request sent by the second project; a project identifier matching unit, configured to match the project identifier of the second project with the project identifier of the shared project in the configuration file; a rejection response unit, configured to send a sharing rejection response to the second project if the project identifier of the second project does not match the project identifier of the shared project; and a first code acquisition unit, configured to acquire the corresponding first shared code file in the static folder according to the first file name in the first file sharing request if the project identifier of the second project matches the project identifier of the shared project.

[0063] Based on the above embodiments, the code acquisition module 22 includes: a folder name determination unit, configured to determine, in a configuration file, a first folder name associated with and saved with the first file name in the first file sharing request; and a second code acquisition unit, configured to acquire, in the corresponding static folder, a first shared code file corresponding to the first file name based on the first folder name.

[0064] Based on the above embodiments, the first file sharing request is an HTTP request; correspondingly, the code sharing module 23 includes: a response generation unit configured to generate an HTTP response corresponding to the HTTP request based on the first shared code file; and a response sending unit configured to send the HTTP response to the second project so that the second project can obtain the first shared code file in the HTTP response.

[0065] Based on the above embodiments, the dynamic sharing device for project code further includes a code reuse module. The code reuse module includes: a third code acquisition unit, configured to generate a second file sharing request based on a preset second file name after the first project runs the build command, and send the second file sharing request to the third project so that the third project can obtain the second shared code file corresponding to the second file name in the corresponding static folder according to the second file sharing request, and send the second shared code file to the first project; and a code reuse unit, configured to receive the second shared code file sent by the third project, and dynamically compile or dynamically run the second shared code file.

[0066] Based on the above embodiments, the code reuse unit includes: a dynamic compilation subunit, configured to dynamically compile the vue file using the Vue encoder when the second shared code file is a vue file; and a dynamic execution subunit, configured to dynamically execute the JavaScript file using the eval function when the second shared code file is a JavaScript file.

[0067] The dynamic code sharing device provided in this application embodiment obtains a shared code file that can be shared with external projects according to a configuration file during the execution of the build command in the local project. This shared code file is then stored in a local static folder for access by external projects. Upon receiving an access request from an external project, the device retrieves the first shared code file required by the external project from the static folder and sends it to the external project. The external project then dynamically compiles or runs the first shared code file. Through this technical means, the local project can complete the external sharing of code by copying the shared code specified in the configuration file to the static folder. External projects can complete the code reuse by requesting access to the shared code in the local project's static folder. Neither the local nor the external project needs to configure the Webpack tool. Dynamic sharing and reuse of code resources can be achieved even without configuring Webpack, solving the problem of relying on the module federation plugin provided by Webpack for sharing code resources in the prior art, and effectively reducing the development and running complexity of small projects.

[0068] The dynamic sharing device for project code provided in this application embodiment can be used to execute the dynamic sharing method for project code provided in the above embodiment, and has corresponding functions and beneficial effects.

[0069] Figure 8 This is a schematic diagram of the structure of a dynamic sharing device for project code provided in an embodiment of this application, with reference to... Figure 8The dynamic sharing device of this project code includes: a processor 31, a memory 32, a communication device 33, an input device 34, and an output device 35. The number of processors 31 and the number of memories 32 in the dynamic sharing device of this project code can be one or more. The processors 31, memory 32, communication device 33, input device 34, and output device 35 of the dynamic sharing device of this project code can be connected via a bus or other means.

[0070] The memory 32, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the dynamic sharing method of project code in any embodiment of this application (e.g., code storage module 21, code acquisition module 22, and code sharing module 23 in the dynamic sharing device of project code). The memory 32 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory 32 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0071] The communication device 33 is used for data transmission.

[0072] The processor 31 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 32, thereby realizing the above-mentioned dynamic sharing method of project code.

[0073] Input device 34 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the device. Output device 35 may include display devices such as a display screen.

[0074] The project code dynamic sharing device provided above can be used to execute the project code dynamic sharing method provided in the above embodiments, and has corresponding functions and beneficial effects.

[0075] This application embodiment also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to execute a method for dynamically sharing project code. The method for dynamically sharing project code includes: during the execution of a build command in a first project, obtaining a shared code file of the first project according to a preset configuration file, and storing the shared code file in a static folder of the first project; receiving a first file sharing request sent by a second project, obtaining the corresponding first shared code file in the static folder according to the first file name in the first file sharing request; and sending the first shared code file to the second project so that the second project can dynamically compile or dynamically run the first shared code file.

[0076] Storage medium – any type of memory device or storage device. The term “storage medium” is intended to include: mounting media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements, etc. Storage medium may also include other types of memory or combinations thereof. Furthermore, storage medium may reside in a first computer system in which the program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term “storage medium” can include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0077] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the above-mentioned dynamic sharing method of project code, but can also execute related operations in the dynamic sharing method of project code provided in any embodiment of this application.

[0078] The dynamic sharing device, storage medium, and dynamic sharing equipment for project code provided in the above embodiments can execute the dynamic sharing method for project code provided in any embodiment of this application. For technical details not described in detail in the above embodiments, please refer to the dynamic sharing method for project code provided in any embodiment of this application.

[0079] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application. The scope of this application is determined by the scope of the claims.

Claims

1. A method for dynamically sharing project code, characterized in that, include: During the process of running the build command in the first project, the shared code file of the first project is obtained according to the preset configuration file, and the shared code file is stored in the static folder of the first project; Receive a first file sharing request sent by the second project, and obtain the corresponding first shared code file in the static folder according to the first file name in the first file sharing request; The first shared code file is sent to the second project so that the second project can dynamically compile or run the first shared code file.

2. The method for dynamically sharing project code according to claim 1, characterized in that, The step of obtaining the shared code file of the first project according to a preset configuration file and storing the shared code file in the static folder of the first project includes: Based on the file storage path and file name in the preset configuration file, obtain the corresponding shared code file in the directory corresponding to the first project; Based on the folder name associated with the file name in the configuration file, the obtained shared code file is stored in the corresponding static folder.

3. The method for dynamically sharing project code according to claim 1, characterized in that, After receiving the first file-sharing request sent by the second project, the method further includes: Obtain the project identifier of the second project from the first file sharing request; Match the project identifier of the second project with the project identifier of the shared project in the configuration file; If the project identifier of the second project does not match the project identifier of the shared project, a sharing rejection response is sent to the second project. Accordingly, obtaining the corresponding first shared code file in the static folder based on the first file name in the first file sharing request includes: If the project identifier of the second project matches the project identifier of the shared project, then the corresponding first shared code file is obtained in the static folder according to the first file name in the first file sharing request.

4. The method for dynamically sharing project code according to claim 1, characterized in that, The step of retrieving the corresponding first shared code file in the static folder based on the first file name in the first file sharing request includes: Based on the first file name in the first file sharing request, determine the name of the first folder associated with and saved in the configuration file; Based on the first folder name, retrieve the first shared code file corresponding to the first file name in the corresponding static folder.

5. The method for dynamically sharing project code according to claim 4, characterized in that, The first file sharing request is an HTTP request; correspondingly, sending the first shared code file to the second project includes: Generate the HTTP response corresponding to the HTTP request based on the first shared code file; The HTTP response is sent to the second project so that the second project can obtain the first shared code file in the HTTP response.

6. The method for dynamically sharing project code according to claim 1, characterized in that, After the first project runs the build command, the following is also included: A second file sharing request is generated based on a preset second file name, and the second file sharing request is sent to the third project so that the third project can obtain the second shared code file corresponding to the second file name in the corresponding static folder according to the second file sharing request, and send the second shared code file to the first project; Receive the second shared code file sent by the third project, and dynamically compile or run the second shared code file.

7. The method for dynamically sharing project code according to claim 6, characterized in that, The dynamic compilation or dynamic execution of the second shared code file includes: When the second shared code file is a Vue file, the Vue file is dynamically compiled using the Vue encoder; If the second shared code file is a JavaScript file, the JavaScript file is dynamically executed using the eval function.

8. A dynamic code sharing device for projects, characterized in that, include: The code storage module is configured to retrieve the shared code file of the first project according to a preset configuration file during the process of running the build command of the first project, and store the shared code file in the static folder of the first project. The code acquisition module is configured to receive a first file sharing request sent by the second project, and to obtain the corresponding first shared code file in the static folder according to the first file name in the first file sharing request. The code-sharing module is configured to send the first shared code file to the second project, so that the second project can dynamically compile or run the first shared code file.

9. A dynamic sharing device for project code, characterized in that, include: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the dynamic sharing method of project code as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the dynamic sharing method of project code as described in any one of claims 1-7.

Images