Device and method for supporting mixed use of different front-end frames

Abstract

The invention discloses a device and method for supporting mixed use of different front-end frameworks, and relates to the technical field of front-end engineering and multi-framework mixed use, and the device comprises a plug-in module, a sub-project used for creating and managing different front-end frameworks in a main project, and a construction tool plug-in module. And the hybrid packaging module is used for automatically executing hybrid packaging operation according to the construction tools used by the main project and the sub-projects to generate a single hybrid package. Wherein the plug-in module can conveniently create and manage sub-projects of various front-end frames in a main project, and the barriers among different frames in traditional development are broken; and the construction tool plug-in module can identify construction tools used by the main project and each sub-project, automatically execute a hybrid packaging operation, integrate the dispersed sub-projects with the main project, and finally generate a single hybrid package. The development process is simplified, the maintainability and reusability of codes are greatly improved, and more convenient and efficient development experience is provided for front-end developers.

Description

Technical Field

[0001] The present application relates to the technical field of front-end engineering and multi-framework mixing, and in particular to a device and method for supporting the mixing of different front-end frameworks. Background Art

[0002] In today's front-end development landscape, the continuous advancement of technology has led to the emergence of numerous front-end frameworks, such as React, Vue, and Angular. Each of these frameworks offers unique syntax, componentization, and development philosophies, providing developers with a wealth of options. However, this diversity also presents a range of challenges.

[0003] Specifically, front-end frameworks on the market differ significantly in their writing styles, making it impossible to directly reuse code between systems developed using different frameworks. When developers need to use functionality or components from one project in another, framework differences often require redeveloping the corresponding code, increasing development costs and reducing efficiency. Furthermore, the same functionality may need to be developed multiple times across different systems due to different frameworks, resulting in wasted resources and redundant code.

[0004] Therefore, how to break down the barriers between front-end frameworks and achieve code reuse and mixing between different frameworks has become an urgent problem to be solved in the current front-end development field. Summary of the Invention

[0005] To address the above issues, this application provides a device and method for supporting mixed use of different front-end frameworks, including the following:

[0006] In a first aspect, the present application provides a device that supports mixed use of different front-end frameworks, the device comprising:

[0007] Plugin module, used to create and manage sub-projects of different front-end frameworks in the main project;

[0008] The build tool plug-in module is used to automatically perform a hybrid packaging operation based on the build tools used by the main project and the sub-project to generate a single hybrid package.

[0009] Optionally, the plug-in module specifically includes:

[0010] The instruction encapsulation unit is used to encapsulate instructions using the commander, receive instructions from users to create sub-projects, and call the corresponding scaffolding to create the basic project according to the specified front-end framework and version;

[0011] The dependency management unit is used to automatically pull the dependencies required by sub-projects and generate a dependency tree file to record project version information.

[0012] Optionally, the plug-in module further includes:

[0013] The template pulling unit is used to pull different template files according to the front-end framework selected by the user after the basic project is created. The template file encapsulates the mounting method that can be used by the corresponding framework.

[0014] Optionally, the build tool plug-in module further includes:

[0015] The build tool configuration unit is used to configure the current build tool by type. The enumeration value of type includes webpack, vite, gulp and grunt;

[0016] The build execution unit is used to call the start instructions of the sub-project and the main project in sequence to perform the build operation.

[0017] Optionally, the construction execution unit further includes:

[0018] The sub-project packaging unit is used to call the sub-project's build command before executing the packaging operation, and delete the sub-project source code directory after the sub-project packaging is completed;

[0019] The main project packaging unit is used to call the main project's build command and package the main project after the sub-projects are packaged.

[0020] Optionally, the build tool plug-in module further includes:

[0021] The folder generation unit is used to generate corresponding folders in the main project package according to the front-end framework and version number of the sub-project, so as to distinguish multiple sub-projects.

[0022] Optionally, the build tool plug-in module further includes:

[0023] The path replacement unit is used to read the placeholders in the main project index file, replace them with the corresponding paths, and add the business version number.

[0024] In a second aspect, the present application provides a method for supporting mixed use of different front-end frameworks, the method comprising:

[0025] Install the project plugin and build tool plugin in the main project;

[0026] Use the plug-in module to create a sub-project of the front-end framework and put the component code in it;

[0027] Call the global method exposed by the sub-project in the main project business code and call the sub-project component;

[0028] After completing the configuration and calling of the sub-project components, the build tool plug-in is used to automatically perform a hybrid packaging operation based on the configuration of the build tools used by the main project and the sub-projects, integrating the main project and each sub-project to generate a single hybrid package, so as to realize the mixed deployment of different front-end frameworks in the main project.

[0029] Optionally, create a subproject including:

[0030] After installing the project plugin through npm or yarn, call the creation command provided by the plugin and specify the required front-end framework and version;

[0031] The plug-in creates a basic project using the scaffolding of the corresponding framework according to user instructions, and automatically pulls the dependencies required by the sub-project.

[0032] Optionally, the calling sub-project component includes:

[0033] Provide a container at the location of the sub-project component that the main project business code needs to reference;

[0034] Call the global method exposed by the sub-project, pass in the container name and the required sub-component name, and implement the reference and rendering of the sub-project component in the main project.

[0035] In the third aspect, the present application provides a device comprising a memory and a processor, wherein the memory is used to store instructions or codes, and the processor is used to execute the instructions or codes so that the device executes the method for supporting the mixing of different front-end frameworks introduced in any implementation of the second aspect.

[0036] In a fourth aspect, the present application provides a computer-readable storage medium storing a code. When the code is executed, the device executing the code implements the method for supporting the mixed use of different front-end frameworks described in any implementation of the second aspect.

[0037] The present application provides a device that supports the mixed use of different front-end frameworks, which includes a plug-in module for creating and managing sub-projects of different front-end frameworks in a main project, and a build tool plug-in module for automatically performing mixed packaging operations based on the build tools used by the main project and the sub-projects to generate a single mixed package. Among them, the plug-in module can easily create and manage sub-projects of multiple front-end frameworks in the main project, breaking the barriers between different frameworks in traditional development; the build tool plug-in module can identify the build tools used by the main project and each sub-project, and automatically perform mixed packaging operations, integrating the scattered sub-projects with the main project, and finally generating a single mixed package. It not only simplifies the development process, but also greatly improves the maintainability and reusability of the code, providing front-end developers with a more convenient and efficient development experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in this embodiment or the prior art, the following briefly introduces the drawings required for use in the embodiment or the prior art description. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0039] Figure 1 A schematic diagram of the structure of a device that supports mixed use of different front-end frameworks provided in an embodiment of the present application;

[0040] Figure 2 A flowchart of a method for supporting the mixed use of different front-end frameworks provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical solutions and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0042] Figure 1 A schematic diagram of the structure of a device that supports mixed use of different front-end frameworks provided in an embodiment of the present application. Figure 1 As shown, the device 100 for supporting mixed use of different front-end frameworks provided in an embodiment of the present application includes:

[0043] The plug-in module 110 is used to create and manage sub-projects of different front-end frameworks in the main project; the build tool plug-in module 120 is used to automatically perform hybrid packaging operations based on the build tools used by the main project and the sub-projects to generate a single hybrid package.

[0044] The plug-in module 110 is a key component of this device for creating and managing sub-projects based on different front-end frameworks within the main project. In practice, when developers need to introduce sub-projects based on different front-end frameworks into the main project, the plug-in module 110 provides a complete creation and management mechanism. For example, if a developer wishes to introduce a sub-project based on the Vue framework into the main project, the plug-in module 110 will provide the corresponding creation commands or interactive interface. The developer simply follows the prompts to enter the necessary information, such as the sub-project name and storage path. The plug-in module 110 will then automatically create a sub-project structure that complies with the Vue framework specifications at the specified location within the main project. This sub-project structure includes the basic files and directories required by the Vue framework, such as the src directory for source code and the public directory for static assets. Furthermore, the plug-in module 110 will also perform corresponding configuration within the main project to ensure that the main project can recognize and correctly load the sub-project. For other front-end frameworks, such as React or Angular, the plug-in module 110 can also provide similar creation and management functions. It will generate the corresponding sub-project structure and perform the corresponding configuration based on the characteristics of each framework.

[0045] In terms of management, the plug-in module 110 allows developers to view, modify, and delete created sub-projects. For example, developers can use the plug-in module 110 to view a list of all sub-projects in the current main project and understand the status and related information of each sub-project. If a sub-project needs to be modified, such as updating the version of a dependent library, the plug-in module 110 will provide the corresponding operation interface, and the developer can complete the modification by simply following the prompts. When a sub-project is no longer needed, the developer can also use the plug-in module 110 to delete it from the main project.

[0046] The main function of the build tool plug-in module 120 is to automatically perform mixed packaging operations based on the build tools used by the main project and the sub-projects, and finally generate a single mixed package.

[0047] In actual implementation, the build tool plug-in module 120 will first identify the build tools used by the main project and each sub-project. Different front-end frameworks may use different build tools. For example, a Vue project may use Vite or Webpack, and a React project may also use Webpack or other build tools. The build tool plug-in module 120 will determine the build tool used by analyzing the configuration files of the main project and sub-projects, such as the scripts field in package.json, vite.config.js or webpack.config.js, etc. Once the build tool is determined, the build tool plug-in module 120 will automatically perform mixed packaging operations based on the characteristics and configuration of these build tools. Mixed packaging means that it will integrate the source code, resource files, etc. of the main project and each sub-project. For example, for JavaScript files, it will perform code compression, merging, and other operations to reduce file size and increase loading speed; for CSS files, it will merge, add prefixes, and other processes to ensure the compatibility of styles in different browsers.

[0048] Ultimately, the build tool plug-in module 120 generates a single, hybrid package. This package contains all the necessary files for the main project and all sub-projects after processing. Developers can deploy this hybrid package to the server, and when users access it, they will see a complete application that integrates the functions of multiple front-end frameworks. Furthermore, since a single, hybrid package is generated, the deployment process is simplified, deployment efficiency is improved, and subsequent maintenance and updates are facilitated.

[0049] In one implementation of an embodiment of the present application, the plug-in module specifically includes: an instruction encapsulation unit, which is used to use commander to encapsulate instructions, receive user instructions to create sub-projects, and call the corresponding scaffolding to create a basic project according to the specified front-end framework and version; a dependency management unit, which is used to automatically pull the dependencies required for the sub-project and generate a dependency tree file to record project version information.

[0050] The command encapsulation unit uses the commander library to encapsulate user commands to provide a clear, easy-to-use command line interface. Through this interface, users can create and manage sub-projects for different front-end frameworks. Specifically, after installing a project plugin through npm or yarn, users can call the creation command provided by the plugin. For example, a user enters the command creat vue3.5.5, where creat is the command to create a sub-project, vue is the front-end framework to be used, and 3.5.5 is the framework version to be used. The command encapsulation unit parses these commands and extracts the front-end framework type and version information.

[0051] The plugin maintains a mapping map internally, mapping the user-specified framework and version to the corresponding scaffolding tool. For example, if the user specifies Vue and 3.5.5, the plugin will use vue-cli 2 to create a basic project, assuming that vue-cli2 is a scaffolding tool that supports Vue 3.5.5. The scaffolding tool is built into the plugin to ensure that it can be called correctly in different environments. Based on user instructions, the instruction encapsulation unit will call the corresponding scaffolding tool to create the basic project structure in the specified location of the main project. This structure contains the basic files and directories required by the framework, such as the src directory and configuration files.

[0052] The dependency manager automatically pulls in the dependencies required by subprojects and generates a dependency tree file to record project version information, ensuring dependency independence and compatibility. After a subproject is created, the dependency manager automatically pulls in dependencies. It uses npm yarn to install all listed dependencies based on the package.json file generated by the scaffold. After installation, the dependency manager generates a package-lock.json file. This file details all dependencies currently used by the subproject and their version information, ensuring that the same dependency versions are used during subsequent builds and deployments, avoiding compatibility issues caused by dependency version upgrades.

[0053] Each sub-project has independent dependency management, which means that dependencies between sub-projects and the main project will not interfere with each other. This design allows sub-projects to exist as independent projects, and even allow for the integration of secondary sub-projects, providing great flexibility and scalability.

[0054] In one implementation of an embodiment of the present application, the plug-in module also includes: a template pulling unit, which is used to pull different template files according to the front-end framework selected by the user after the basic project is created. The template file encapsulates the mounting method that can be used by the corresponding framework.

[0055] After the basic project is created, different template files are pulled according to the framework selected by the user. The template files encapsulate the mounting methods that can be used by the corresponding framework. These methods are responsible for mounting the components of the sub-project into the containers specified in the main project.

[0056] The mounting method generally includes the following steps:

[0057] In the project entry file, use the method provided by the build tool to read all files in the project components directory, such as webpack using require;

[0058] const files=require.context("@ / components",true, / index\.js$ / );

[0059] let components=files.keys().map(key=>{

[0060] const page=require("@ / components"+key.replace(".",""));

[0061] return page.default;

[0062] });

[0063] Get the components object containing all components.

[0064] Encapsulates the mount function createIns. The createIns function maps the components in the components object according to the componentsName passed in when used. After the mapping is completed, it creates a framework instance and mounts the instance on the window to facilitate the outer framework to call and pass data; finally, it renders the subcomponent in the container specified by the user.

[0065] By encapsulating and implementing the above mounting methods, components from different front-end frameworks can coexist in the same main project. The main project can call the mounting function to mount sub-components of different frameworks into a specified container, enabling mixed use of functions and data interaction.

[0066] In one implementation of the embodiment of the present application, the construction tool plug-in module further includes:

[0067] The build tool configuration unit is used to configure the current build tool through type. The enumeration value of type includes webpack, vite, gulp and grunt. The build execution unit is used to call the start instructions of the sub-project and the main project in sequence to perform the build operation.

[0068] The build tool configuration unit allows users to configure the currently used build tool through the type parameter. The enumeration value of type includes webpack, vite, gulp and grunt, covering several commonly used build tools in current front-end development. The user specifies the type field in the plug-in's configuration file or initialization parameters, and the plug-in selects the corresponding build tool processing logic based on the value of type. Since the processing logic for build tools such as webpack, vite, gulp and grunt has been encapsulated within the plug-in, users do not need to manually write or configure detailed configuration files for these build tools. The plug-in will automatically handle various tasks in the build process. Through the enumeration value of type, the plug-in can flexibly support multiple build tools to meet the needs of different projects or teams.

[0069] The build execution unit is responsible for calling the start commands of the subprojects and then the main project to execute the build. This design ensures an orderly and consistent build process. The build execution unit first iterates through all subprojects and calls the start command of each subproject. This typically means executing the build script defined in the subproject. After the subproject build is complete, the build execution unit calls the start command of the main project to execute the main project build. It is important to note that the order of calls does not matter during the build process.

[0070] In one implementation of the embodiment of the present application, the construction execution unit also includes: a sub-project packaging unit, which is used to call the build command of the sub-project first when executing the packaging operation, and delete the sub-project source code directory after the sub-project packaging is completed; a main project packaging unit, which is used to call the build command of the main project after the sub-project packaging is completed to package the main project.

[0071] The specific packaging process is to first call the sub-project build command. The build execution unit will first traverse all sub-projects and call the build command of each sub-project. This usually means executing the build script defined in the sub-project. The build process of the sub-project includes steps such as code compilation and resource optimization to generate static files that can be used for deployment. After the sub-project is packaged, the sub-project packaging unit will automatically delete the source code directory of the sub-project. This step helps to reduce the project size and avoid unnecessary exposure of the source code in the production environment. The deletion operation can be implemented through the file system API or command line tools (such as rm-rf) to ensure the efficiency and reliability of the operation. After the sub-project is packaged, the main project packaging unit will call the build command of the main project to execute the build process of the main project. The build process of the main project also includes steps such as code compilation and resource optimization to generate the final deployable file.

[0072] In one implementation of the embodiment of the present application, the build tool plug-in module further includes: a folder generation unit for generating corresponding folders in the main project package based on the front-end framework and version number of the sub-project, so as to distinguish multiple sub-projects. Based on the framework and version number of the sub-project, the main project packaging unit will generate corresponding folders in the main project package. For example, for a sub-project using Vue 3.3.5, a folder named vue-3.3.5 will be generated. This design enables the output files of multiple sub-projects to be clearly distinguished and managed.

[0073] In one implementation of the present application, the build tool plug-in module also includes a path replacement unit. The main function of the path replacement unit is to dynamically replace the reference path of the resource in the index file of the main project so that it points to the correct sub-project build output file and appends the business version number to achieve resource uniqueness and traceability. The specific implementation steps are as follows:

[0074] In the index.html file of the main project, insert placeholders in advance to represent the resource paths that need to be dynamically replaced. For example, for a Vue 2 project, you need to import two packaged main files to run, so insert the following placeholders in index.html:

[0075] <script src＝'bundle vue app.js'>< / script>

[0076] <link rel＝'stylesheet'href＝'bundle vue app.css'>

[0077] These placeholders are typically inserted manually by developers during development or automatically generated by build tools. To dynamically replace these placeholders, the plugin requires a mechanism to manage the mapping between different frameworks and their resource paths. To address this requirement, the plugin maintains an internal mapping map that records the resource paths corresponding to different frameworks and their versions. This map can be expanded and modified based on the project's specific needs.

[0078] During the path replacement process, the path replacement unit reads the index.html file and identifies the placeholders. Then, based on the mapping map, it replaces the placeholders with the actual resource paths and appends the service version number. For example, if the path recorded in the mapping map is dist / vue / 2.0 / app.js and the service version number is v1.2.3, the replaced path will be dist / vue / 2.0 / app.js?v1.2.3.

[0079] Through the path replacement mechanism described above, the path replacement unit works in conjunction with other parts of the build tool plugin to achieve hybrid packaging. This means it can handle sub-project resources from different frameworks, ensuring they are correctly referenced and run in the main project. By dynamically replacing resource paths and appending version numbers, the path replacement unit effectively resolves path conflicts in multi-framework resource management while ensuring resource uniqueness and traceability.

[0080] The above example describes the implementation process when the user does not select a custom framework, detailing how the plugin assists with sub-project creation, dependency management, template retrieval, build execution, and path replacement within the main project. The following describes the implementation process when the user selects a custom framework, focusing on how the plugin adapts and supports the user through the entire process, from framework retrieval, basic project construction, to hybrid packaging, ensuring that the custom framework can be smoothly integrated into the project and work collaboratively with other sub-projects.

[0081] When a user wants to use a custom framework in a project instead of a widely used mainstream framework, the device provided by this application can support the user to obtain and use the custom framework by specifying a private library address. The following are the specific steps for users to use a custom framework:

[0082] 1. Create a sub-project and pull the custom framework

[0083] When creating a subproject, the user specifies the private library address of the custom framework through a specific command (such as creat). This private library address is usually a code repository maintained by the user or team, which stores the code of the custom framework.

[0084] After receiving this command, the plugin will automatically pull the custom framework's code library from the specified private library address and place it in the root path of the main project. In this way, the custom framework's code becomes part of the project and can be used by subsequent operations.

[0085] 2. Basic project creation and template file pulling, this process needs to be implemented by the user

[0086] Since a custom framework is used, users need to create the basic project and pull the template files by themselves.

[0087] Basic project creation: Users need to manually create the basic project structure, including necessary directories and files, based on the characteristics of the custom framework. This usually involves initializing the framework configuration and setting up the project structure.

[0088] Pulling template files: Users must pull or create template files containing mounting methods from the custom framework's codebase. These template files define how to mount sub-project components into the main project and are key to enabling multi-framework runtime coexistence. The template files encapsulate the custom framework's mounting methods, ensuring that sub-project components are correctly mounted into the main project according to the custom framework's rules, enabling functional integration and interaction.

[0089] 3. Insert placeholders in the main project index file. This process needs to be implemented by the user.

[0090] Users need to manually insert placeholders in the index.html file of the main project. These placeholders are used to indicate sub-project resources that need to reference the custom framework.

[0091] The purpose of inserting placeholders is to dynamically replace these placeholders with actual resource paths in the subsequent construction process to ensure correct reference of resources.

[0092] While the plugin can maintain a mapping to record the resource paths corresponding to different frameworks and their version numbers, for custom frameworks, specific path replacement and version number management must be implemented by the user based on the characteristics of the custom framework. Users must ensure that placeholders are correctly replaced with actual resource paths during the build process, and that business version numbers can be appended to ensure resource uniqueness and traceability.

[0093] 4. Hybrid packaging implementation

[0094] Users need to ensure that the build output of the custom framework can work together with the build output of the main project and other sub-projects to achieve mixed packaging.

[0095] This usually involves configuring build tools and using plugins in conjunction with each other. Users need to configure build tools according to the build rules of the custom framework to ensure that all resources can be correctly compiled, packaged, and ultimately generate a deployable application.

[0096] Plugins provide basic build tool processing logic, but users may need to perform additional configuration and implementation to meet the specific needs of custom frameworks. Plugins strive to be compatible with user-defined build processes, but the specific build details and rules need to be defined by the user based on the characteristics of the custom framework.

[0097] In summary, when using a custom framework, users need to be more involved in and implement steps such as basic project creation, template file pull, placeholder insertion, and mixed packaging. Plugins provide basic framework pull and build tool support, but users need to implement and adjust the specific features of the custom framework based on the framework's characteristics. This design ensures plugin flexibility while supporting diverse front-end development needs, allowing users to choose and use the most suitable framework for their specific needs.

[0098] Figure 2 A flow chart of a front-end framework mixing method provided in an embodiment of the present application. Figure 2 As shown, the front-end framework mixing method provided in the embodiment of the present application may include:

[0099] S201. Install the project plug-in and the build tool plug-in in the main project.

[0100] S202. Use the plug-in module to create a sub-project of the front-end framework and put in the component code.

[0101] S203: In the main project business code, call the global method exposed by the sub-project and call the sub-project component.

[0102] S204. After completing the configuration and calling of the sub-project components, the build tool plug-in is used to automatically perform a hybrid packaging operation according to the configuration of the build tools used by the main project and the sub-projects, and the main project and each sub-project are integrated to generate a single hybrid package to achieve mixed deployment of different front-end frameworks in the main project.

[0103] In one implementation of the embodiment of the present application, creating a sub-project includes:

[0104] After installing the project plugin through npm or yarn, call the creation command provided by the plugin and specify the required front-end framework and version;

[0105] The plug-in creates a basic project using the scaffolding of the corresponding framework according to user instructions, and automatically pulls the dependencies required by the sub-project.

[0106] In one implementation of the embodiment of the present application, the calling sub-project component includes:

[0107] Provide a container at the location of the sub-project component that the main project business code needs to reference;

[0108] Call the global method exposed by the sub-project, pass in the container name and the required sub-component name, and implement the reference and rendering of the sub-project component in the main project.

[0109] The embodiments of the present application also provide corresponding devices and computer storage media for implementing the solutions provided by the embodiments of the present application.

[0110] The device includes a memory and a processor, the memory is used to store instructions or codes, and the processor is used to execute the instructions or codes so that the device executes the method described in any embodiment of the present application.

[0111] The computer storage medium stores code, and when the code is executed, the device executing the code implements the method described in any embodiment of the present application.

[0112] Through the description of the above embodiments, it can be known that those skilled in the art can clearly understand that all or part of the steps in the above embodiment methods can be implemented by means of software plus a general hardware platform. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a storage medium, such as a read-only memory (ROM) / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network communication device such as a router) to execute the methods described in each embodiment or certain parts of the embodiments of the present application.

[0113] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0114] It should also be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and apparatus embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The device and apparatus embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components indicated as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0115] The above is merely one specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A device that supports mixed use of different front-end frameworks, characterized in that: The device comprises: Plugin module, used to create and manage sub-projects of different front-end frameworks in the main project; The build tool plug-in module is used to automatically perform a hybrid packaging operation based on the build tools used by the main project and the sub-project to generate a single hybrid package.

2. The device according to claim 1, characterized in that The plug-in module specifically includes: The instruction encapsulation unit is used to encapsulate instructions using the commander, receive instructions from users to create sub-projects, and call the corresponding scaffolding to create the basic project according to the specified front-end framework and version; The dependency management unit is used to automatically pull the dependencies required by sub-projects and generate a dependency tree file to record project version information.

3. The device according to claim 2, characterized in that The plug-in module also includes: The template pulling unit is used to pull different template files according to the front-end framework selected by the user after the basic project is created. The template file encapsulates the mounting method that can be used by the corresponding framework.

4. The device according to claim 1, characterized in that The build tool plug-in module also includes: The build tool configuration unit is used to configure the current build tool by type. The enumeration value of type includes webpack, vite, gulp and grunt; The build execution unit is used to call the start instructions of the sub-project and the main project in sequence to perform the build operation.

5. The device according to claim 4, characterized in that The construction execution unit also includes: The sub-project packaging unit is used to call the sub-project's build command before executing the packaging operation, and delete the sub-project source code directory after the sub-project packaging is completed; The main project packaging unit is used to call the main project's build command and package the main project after the sub-projects are packaged.

6. The device according to claim 5, characterized in that The build tool plug-in module also includes: The folder generation unit is used to generate corresponding folders in the main project package according to the front-end framework and version number of the sub-project, so as to distinguish multiple sub-projects.

7. The device according to claim 6, characterized in that The build tool plug-in module also includes: The path replacement unit is used to read the placeholders in the main project index file, replace them with the corresponding paths, and add the business version number.

8. A front-end framework mixing method, used in the device for supporting mixed use of different front-end frameworks according to claim 1, characterized in that: The method comprises: Install the project plugin and build tool plugin in the main project; Use the plug-in module to create a sub-project of the front-end framework and put the component code in it; In the main project business code, call the global method exposed by the sub-project and call the sub-project component; After completing the configuration and calling of the sub-project components, the build tool plug-in is used to automatically perform a hybrid packaging operation based on the configuration of the build tools used by the main project and the sub-projects, integrating the main project and each sub-project to generate a single hybrid package, so as to realize the mixed deployment of different front-end frameworks in the main project.

9. The method according to claim 8, characterized in that Creating a sub-project includes: After installing the project plugin through npm or yarn, call the creation command provided by the plugin and specify the required front-end framework and version; The plug-in creates a basic project using the scaffolding of the corresponding framework according to user instructions, and automatically pulls the dependencies required by the sub-project.

10. The method according to claim 9, characterized in that The calling sub-project component includes: Provide a container at the location of the sub-project component that the main project business code needs to reference; Call the global method exposed by the sub-project, pass in the container name and the required sub-component name, and implement the reference and rendering of the sub-project component in the main project.

Images