Plug-in data processing method and device, equipment and storage medium
By providing a universal front-end build plugin interface, the problem of low usability and low development efficiency caused by different plugin writing methods for different build tools is solved, and seamless integration and efficient development of plugins on multiple build tools are achieved.
Patent Information
- Application Number
- CN202411178981.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-26
- Publication Date
- 2026-03-03
AI Technical Summary
Different build tools use different methods for writing plugins, resulting in low plugin usability and low development efficiency.
It provides a general front-end build plugin interface, which maps plugin code to the application interface of the target build tool through plugin abstract class, adapter and configuration converter class, and performs event-driven and configuration conversion to achieve seamless integration of plugins on multiple build tools.
It improves plugin usability, reduces development and maintenance costs, enables seamless integration of plugins across multiple build tools, and improves development efficiency.
Smart Images

Figure CN121597300A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet technology, and in particular to a plug-in data processing method, apparatus, device and storage medium. Background Technology
[0002] Front-end development refers to the use of HTML, CSS, and JavaScript, along with their derivative technologies, frameworks, and solutions, to create user interfaces for internet products. Build tools have become an indispensable part of front-end development, helping developers automate tasks, optimize code, and improve development efficiency. Build tool plugins are special software modules that enhance or extend the functionality of build tools. Build tool plugins can provide additional features, such as handling specific file types, optimizing code, performing code analysis, or performing specific tasks during the build process.
[0003] In the existing technology, different build tools have their own plugin mechanisms, and the methods for writing plugins for different build tools are different. Specific plugin adaptation code needs to be written for each build tool, resulting in low plugin usability and low development efficiency. Summary of the Invention
[0004] This application provides a plugin data processing method, apparatus, device, and storage medium, which can improve the usability of plugins and thus improve development efficiency.
[0005] Firstly, this application provides a plug-in data processing method, including:
[0006] Obtain a plugin usage request, the plugin usage request including the code of a first plugin and the identifier of a target build tool, wherein the code of the first plugin is used on the target build tool;
[0007] Based on the identifier of the target build tool, the adapter of the target build tool is found from the plugin abstract class. Based on the definition of the plugin abstract class and the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool. The plugin abstract class includes adapters for multiple build tools.
[0008] Based on the code of the first plugin, event-driven operation is implemented;
[0009] Based on the identifier of the target build tool, the configuration conversion method of the target build tool is located in the configuration converter class, and the configuration conversion method is called to convert the configuration file of the target build tool into a general-format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
[0010] Secondly, this application provides a front-end build plugin interface, including:
[0011] A plugin abstraction unit is used to obtain a plugin usage request. The plugin usage request includes the code of a first plugin and the identifier of a target build tool. The code of the first plugin is used on the target build tool. Based on the identifier of the target build tool, the adapter of the target build tool is found from the plugin abstraction class. Based on the definition of the plugin abstraction class and the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool. The plugin abstraction class includes adapters for multiple build tools.
[0012] An event-driven unit is used to perform event-driven operations based on the code of the first plugin.
[0013] The configuration conversion unit is used to find the configuration conversion method of the target build tool from the configuration converter class according to the identifier of the target build tool, and call the configuration conversion method to convert the configuration file of the target build tool into a general format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
[0014] In one embodiment, the definition of the plugin abstract class includes the code corresponding to the application methods that can be implemented by the adapter of each build tool, and the plugin abstract unit is used for:
[0015] The code corresponding to the application methods that can be implemented by running the adapter of each of the aforementioned build tools;
[0016] Using the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool.
[0017] In one embodiment, the adapter for the target build tool includes code corresponding to hooks and methods of the target build tool, as well as code corresponding to methods that call the plugin. The plugin abstraction unit is specifically used for:
[0018] Run the code corresponding to the hooks and methods of the target build tool, and run the code corresponding to the method that calls the plugin according to the code of the first plugin, so as to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool.
[0019] In one embodiment, the code of the first plugin includes an event storage object, a registration event detection function, an event triggering function, and the core functionality of the first plugin. The event storage object stores identifiers of multiple events and an array of detection functions corresponding to multiple events. The event-driven unit is used for:
[0020] Events are registered and triggered based on the event storage object, the event registration detection function, the event triggering function, and the core functionality of the first plugin.
[0021] In one embodiment, the configuration conversion unit is used for:
[0022] Retrieve the configuration file of the target build tool from local storage;
[0023] Using the configuration conversion method, the configuration file of the target build tool is converted into a general-format configuration object, which includes input attributes and output attributes.
[0024] Apply the configuration object in the general format to the first plugin.
[0025] In one embodiment, the front-end building plugin interface further includes:
[0026] A compatibility checking unit is used to obtain information about the target build tool and the first plugin, and to check the compatibility between the first plugin and the target build tool based on the information about the target build tool and the first plugin.
[0027] In one embodiment, the compatibility checking unit is specifically used for:
[0028] Based on the information of the target build tool and the information of the first plugin, determine whether the version of the first plugin is compatible with the version of the target build tool;
[0029] Determine whether the target builder supports the application programming interface required by the first plugin.
[0030] In one embodiment, the compatibility checking unit is specifically used for:
[0031] If the version of the target build tool is lower than the minimum version required by the first plugin, it is determined that the first plugin is incompatible with the target build tool;
[0032] If the version of the target build tool is greater than or equal to the minimum version required by the first plugin, the first plugin is determined to be compatible with the target build tool.
[0033] Thirdly, this application provides a plug-in data processing apparatus, comprising:
[0034] The acquisition module is used to acquire a plugin usage request, which includes the code of a first plugin and the identifier of a target build tool, wherein the code of the first plugin is used on the target build tool;
[0035] The first processing module is used to find the adapter of the target build tool from the plugin abstract class according to the identifier of the target build tool, and to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool according to the definition of the plugin abstract class and the adapter of the target build tool. The plugin abstract class includes adapters of multiple build tools.
[0036] The event-driven module is used to perform event-driven operations based on the code of the first plugin;
[0037] The second processing module is used to find the configuration conversion method of the target build tool from the configuration converter class according to the identifier of the target build tool, and call the configuration conversion method to convert the configuration file of the target build tool into a general format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
[0038] In one embodiment, the definition of the plugin abstract class includes the code corresponding to the application methods that can be implemented by the adapter of each build tool, and the first processing module is used to:
[0039] The code corresponding to the application methods that can be implemented by running the adapter of each of the aforementioned build tools;
[0040] Using the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool.
[0041] In one embodiment, the adapter for the target build tool includes code corresponding to hooks and methods of the target build tool, as well as code corresponding to methods that call the plugin. The first processing module is specifically used for:
[0042] Run the code corresponding to the hooks and methods of the target build tool, and run the code corresponding to the method that calls the plugin according to the code of the first plugin, so as to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool.
[0043] In one embodiment, the code of the first plugin includes an event storage object, a registration event detection function, an event triggering function, and the core functionality of the first plugin. The event storage object stores identifiers of multiple events and an array of detection functions corresponding to multiple events. The event-driven module is used for:
[0044] Events are registered and triggered based on the event storage object, the event registration detection function, the event triggering function, and the core functionality of the first plugin.
[0045] In one embodiment, the second processing module is used to:
[0046] Retrieve the configuration file of the target build tool from local storage;
[0047] Using the configuration conversion method, the configuration file of the target build tool is converted into a general-format configuration object, which includes input attributes and output attributes.
[0048] Apply the configuration object in the general format to the first plugin.
[0049] In one embodiment, the second processing module is further configured to:
[0050] Obtain information about the target build tool and the first plugin, and check the compatibility between the first plugin and the target build tool based on the information about the target build tool and the first plugin.
[0051] In one embodiment, the second processing module is specifically used for:
[0052] Based on the information of the target build tool and the information of the first plugin, determine whether the version of the first plugin is compatible with the version of the target build tool;
[0053] Determine whether the target builder supports the application programming interface required by the first plugin.
[0054] In one embodiment, the second processing module is specifically used for:
[0055] If the version of the target build tool is lower than the minimum version required by the first plugin, it is determined that the first plugin is incompatible with the target build tool;
[0056] If the version of the target build tool is greater than or equal to the minimum version required by the first plugin, the first plugin is determined to be compatible with the target build tool.
[0057] Fourthly, this application provides an electronic device, including: a processor and a memory, the memory for storing a computer program, and the processor for calling and running the computer program stored in the memory to perform the method of the first aspect.
[0058] Fifthly, this application provides a computer-readable storage medium including instructions that, when executed on a computer program, cause the computer to perform the method as described in the first aspect.
[0059] In a sixth aspect, this application provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method as described in the first aspect.
[0060] In summary, this application provides a generic front-end build plugin interface. Developers only need to write plugin code once, and through this interface, they can implement the plugin code on a specified build tool and use it on that tool. Specifically, the front-end build plugin interface obtains a plugin usage request, which includes the code of the first plugin and the identifier of the target build tool (the specified build tool). Then, based on the identifier of the target build tool, it searches for the adapter for the target build tool in the plugin abstract class. According to the definition of the plugin abstract class and the adapter, the behavior corresponding to the first plugin code is mapped to the application interface of the target build tool. Next, based on the first plugin code, event-driven processing is performed. Then, based on the identifier of the target build tool, it searches for the configuration conversion method of the target build tool in the configuration converter class and calls the configuration conversion method to convert the target build tool's configuration file into a generic configuration object. This enables the use of the first plugin code on the target build tool. Therefore, developers only need to write plugin code once, and this code can be used on multiple different build tools, achieving seamless integration between the plugin and the build tool. This improves plugin usability, increases development efficiency, and reduces maintenance costs. Attached Figure Description
[0061] Figure 1 This is a schematic diagram illustrating an application scenario of a plug-in data processing method provided in an embodiment of this application.
[0062] Figure 2 A flowchart illustrating a plug-in data processing method provided in an embodiment of this application;
[0063] Figure 3 This application provides a schematic diagram of the structure of a front-end building plugin interface.
[0064] Figure 4 This application provides a schematic diagram of the structure of a front-end building plugin interface.
[0065] Figure 5 This is a schematic diagram of the structure of a plug-in data processing device provided in an embodiment of this application;
[0066] Figure 6 This is a schematic block diagram of the electronic device 700 provided in the embodiments of this application. Detailed Implementation
[0067] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0068] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.
[0069] It should be noted that the terminology used in the implementation section of this application is only for explaining the embodiments of this application and is not intended to limit this application.
[0070] For example, the term "correspondence" in this article can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship of instruction and being instructed, configuration and being configured, etc.
[0071] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
[0072] The relevant knowledge involved in this application will be explained below:
[0073] 1. JavaScript (JS) is a scripting language commonly used to implement interactive functionality on web pages. It is a dynamically typed, interpreted language originally designed for manipulating web page elements and creating dynamic effects in web browsers. However, over time, JavaScript has evolved into a general-purpose programming language used for developing various applications, including front-end, back-end, and mobile applications.
[0074] 2. Build tools, also known as front-end build tools, are tools used to automate common tasks such as compiling, compressing, testing, and deploying code. These tools can help developers develop and maintain code more efficiently, while also improving code performance and readability.
[0075] 3. Build tool plugins are special software modules that enhance or extend the functionality of build tools. Plugins can provide additional features, such as handling specific file types, optimizing code, performing code analysis, or performing specific tasks during the build process. The main purpose of plugins is to provide a way for developers to customize and extend their build process to meet specific needs or optimize workflows. For example, a build tool might have a plugin for converting TypeScript code to JavaScript, or a plugin for compressing and optimizing CSS and JavaScript files.
[0076] Plugins can usually be easily added to build tools and can be configured as needed. This allows developers to choose the features they need instead of using some built-in features they don't require.
[0077] 4. The Universal Frontend Build Plugin Interface (UFBPI) is a specification for defining the interaction between build tools and plugins. This specification allows developers to create plugins for different build tools and environments, thereby improving the efficiency and maintainability of frontend application development. The frontend build plugin interface in this embodiment is a cross-build tool interface, a general-purpose frontend build plugin interface. Through this interface, developers only need to write the plugin code once, which can then be used in multiple different build tools (such as Webpack, Rollup, Parcel, etc.), greatly improving development efficiency and reducing maintenance costs.
[0078] In related technologies, specific plugin adaptation code needs to be written for each build tool, resulting in low plugin usability and low development efficiency.
[0079] To address this issue, this application provides a generic front-end build plugin interface. Developers only need to write the plugin code once, and through this interface, they can implement the plugin code on a specified build tool and use it there. Specifically, the front-end build plugin interface receives a plugin usage request, which includes the code of the first plugin and the identifier of the target build tool (the specified build tool). Then, based on the target build tool's identifier, it searches for the adapter for the target build tool in the plugin abstract class. According to the definition of the plugin abstract class and the adapter, the behavior corresponding to the first plugin code is mapped to the application interface of the target build tool. Next, based on the first plugin code, event-driven processing is performed. Then, based on the target build tool's identifier, it searches for the configuration conversion method for the target build tool in the configuration converter class and calls the configuration conversion method to convert the target build tool's configuration file into a generic configuration object. This allows the code of the first plugin to be used on the target build tool. Therefore, developers only need to write the plugin code once, and this plugin code can be used on multiple different build tools, achieving seamless integration between the plugin and the build tool. This improves plugin usability, increases development efficiency, and reduces maintenance costs.
[0080] The plugin data processing method provided in this application can be applied to various scenarios, including but not limited to front-end development scenarios, and specifically to the development and use of build tool plugins.
[0081] For example, Figure 1 This is a schematic diagram illustrating an application scenario of a plug-in data processing method provided in an embodiment of this application, such as... Figure 1 As shown, the application scenario of this application involves server 1 and terminal device 2. Terminal device 2 can communicate with server 1 through a communication network.
[0082] In some possible implementations, terminal device 2 refers to a type of device that has rich human-computer interaction methods, internet access capabilities, typically runs various operating systems, and possesses strong processing capabilities. Terminal devices can be smartphones, tablets, portable laptops, desktop computers, or smartwatches, but are not limited to these.
[0083] In some possible implementations, the terminal device 2 includes, but is not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, and vehicle terminals.
[0084] Figure 1 Server 1 in the text can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services. This application does not impose any restrictions on this.
[0085] The plugin data processing method provided in this application can be executed by a terminal device. For example, the plugin data processing method provided in this application can be used for the development and use of build tool plugins in front-end development.
[0086] For example, the technical solution of this application will be described in detail below:
[0087] Figure 2 A flowchart illustrating a plug-in data processing method provided in this application embodiment. The execution subject of this method can be a terminal device, specifically a client installed and running on the terminal device, such as... Figure 2 As shown, the method may include:
[0088] S101. Obtain a plugin usage request. The plugin usage request includes the code of the first plugin and the identifier of the target build tool. The code of the first plugin is used on the target build tool.
[0089] Specifically, front-end developers can use a client installed and running on a terminal device to develop plugins. Plugin developers can write plugin code based on the front-end build plugin interface provided in this application embodiment. This plugin code can be used on multiple build tools. The target build tool is the build tool to which the first plugin code will be used. The target build tool can be any of the following: Webpack (development language is JavaScript), Rollup (development language is JavaScript), Parcel (development language is JavaScript), Vite (development language is TypeScript), and Snowpack (development language is JavaScript), etc. Other build tools are also possible, and this embodiment does not limit this. In one embodiment, the plugin usage request is the input information of the front-end build interface. When it is necessary to use the first plugin on the target build tool, a plugin usage request is initiated, inputting the code of the first plugin and the identifier of the target build tool to the front-end build interface.
[0090] S102. Based on the identifier of the target build tool, find the adapter of the target build tool from the plugin abstract class. Based on the definition of the plugin abstract class and the adapter of the target build tool, map the behavior corresponding to the code of the first plugin to the application interface of the target build tool. The plugin abstract class includes adapters for multiple build tools.
[0091] Specifically, the front-end build plugin interface in this embodiment includes a plugin abstraction layer. This layer abstracts the core functionalities and application programming interfaces (APIs) of different build tools, allowing plugin developers to program against this abstraction layer rather than against a specific build tool. The plugin abstraction layer defines a set of generic APIs that can be mapped to the corresponding functionalities of different build tools.
[0092] In one embodiment, the plugin abstraction layer includes a plugin abstract class that includes adapters for multiple build tools. The plugin abstract class defines the application methods that all adapters need to implement. Taking a target build tool as an example, the adapter for the target build tool is used to implement the capabilities that the target build tool provides to developers.
[0093] Specifically, after obtaining the plugin usage request, the adapter of the target build tool is found in the plugin abstract class. Based on the definition of the plugin abstract class and the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool.
[0094] Optionally, in one implementable approach, the definition of the plugin abstract class includes the code corresponding to the application methods that can be implemented by the adapter of each build tool. In S102, based on the definition of the plugin abstract class and the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool. Specifically, this can be:
[0095] S1021. The code corresponding to the application methods that can be implemented by running the adapter of each build tool.
[0096] S1022. Using the target build tool's adapter, map the behavior corresponding to the code of the first plugin to the application interface of the target build tool.
[0097] Optionally, in one embodiment, the adapter of the target build tool includes code corresponding to the hooks and methods of the target build tool and code corresponding to the method of calling the plugin. Specifically, S1022 can be: running the code corresponding to the hooks and methods of the target build tool, and running the code corresponding to the method of calling the plugin according to the code of the first plugin, so as to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool.
[0098] For example, here is an example of a plugin abstraction layer:
[0099]
[0100]
[0101] In the example above, `BuildToolpluginterface` is an abstract class that defines the application methods that all adapters should implement. This example has two adapter classes: `WebpackAdapter` and `RollupAdapter`. Understandably, other examples may have multiple other adapter classes.
[0102] For example, the following is a code example for the first plugin, which is the generic plugin in the code below.
[0103]
[0104]
[0105] In the example above, MyUniversalplugin is a universal plugin that contains the core logic of the plugin. In this code example, the performAction method is the core function of the plugin, and it will be called during the build process.
[0106] For example, here is a code example of how to use the above-mentioned general plugin:
[0107] / / Usage example
[0108] const myplugin=new MyUniversalplugin();
[0109] / / For Webpack
[0110] const WebpackCompiler = { / *…* / }; / / Assuming this is a Webpack compiler instance.
[0111] const WebpackAdapter = new WebpackAdapter(myplugin); / / Creates an instance of WebpackAdapter and passes in a plugin object myplugin.
[0112] WebpackAdapter.apply(Webpackcompiler); / / Calls the apply method of the WebpackAdapter instance, passing in the Webpackcompiler instance.
[0113] / / For Rollup
[0114] const RollupOptions = { / *…* / }; / / Assuming this is a Rollup configuration object
[0115] const Rollup Adapter = new Rollup Adapter(myplugin); / / Creates an instance of RollupAdapter and passes in a plugin object myplugin.
[0116] Rollup Adapter.Apply(RollupOptions) / / Calls the apply method of the Rollup Adapter instance and passes in the RollupOptions instance.
[0117] In the example above, a MyUniversalPlugin instance is created and applied to different build tools via adapters, such as applying it to the Webpack build tool via the Webpack adapter and applying it to the Rollup build tool via the Rollup adapter. Plugin developers only need to focus on the implementation of the MyUniversalPlugin instance. It is understood that this embodiment uses two adapters as an example, and adapters for other build tools can also be included; this embodiment is not limited to this.
[0118] S103. Based on the code of the first plugin, implement event-driven operation.
[0119] Specifically, the event-driven mechanism of the front-end build plugin interface design in this embodiment allows the plugin to respond to events at key points in the build process, such as module parsing, code compression, and file output.
[0120] Optionally, the code of the first plugin includes an event storage object, a registration event detection function, a trigger event function, and the core functionality of the first plugin. The event storage object stores the identifiers of multiple events and an array of detection functions corresponding to multiple events. As an implementable approach, S103 can specifically be: registering events and triggering events based on the event storage object, the registration event detection function, the trigger event function, and the core functionality of the first plugin.
[0121] The event storage object stores identifiers for multiple events and an array of corresponding event detection functions. Registering event detection functions allows external events to register detection functions for the events stored in the event storage object. Triggering event functions trigger these events stored in the event storage object at appropriate times. When the target build tool runs, the registered event detection functions will be called at the appropriate time, thus implementing a basic event-driven mechanism.
[0122] The following code is an example of the content of a general plugin class called MyUniversalplugin:
[0123] General plugin definition:
[0124] First, initialize an event storage object to store the event name and the corresponding detection function. It can be defined to trigger before the build starts, after compilation ends, or before file output. More events can also be defined as needed.
[0125] Next, register the event detection function and add the callback function to the detection queue of the corresponding event.
[0126] Define an error to be thrown if the event does not exist.
[0127] Otherwise, an event is triggered, invoking all registered detection functions.
[0128] Next, the array of detection functions is traversed and called one by one. The core functionality of the plugin can be divided according to the event.
[0129] Trigger the event and invoke all registered detection functions.
[0130] Next, check if the hook list exists. Specifically, iterate through the hook list and execute the callback for each callback function in the list.
[0131] The core functionality of the plugin can be segmented based on events. In the Webpack adapter class, the `emit` hook is an asynchronous hook that allows certain operations to be performed before Webpack outputs resources to disk. Here, a callback function is registered using the `tapAsync` method, passing in an additional `callback` parameter. Inside the callback function, `this.plugin.performAction(compilation.assets)` is called to perform some operations, which may modify, inspect, or log the resources to be output. Once these operations are complete, `callback()` is called to notify Webpack that it can continue outputting resources to disk.
[0132] In the Rollup adapter class, the Rollup adapter class uses the extends keyword to inherit from another class, BuildToolPluginInterface.
[0133] In the WebpackAdapter and RollupAdapter classes, the `trigger` method is called to trigger pre-build events, post-build events, and other events. This ensures that the common plugin can respond to the same set of events in both the Webpack and Rollup build processes.
[0134] In the usage example, some event detection functions were registered to demonstrate how to respond to events triggered by MyUniversal-Plugin. These function checks will then be invoked at appropriate times when the build tool runs, thus implementing a basic event-driven mechanism.
[0135] S104. Based on the identifier of the target build tool, find the configuration conversion method of the target build tool in the configuration converter class, call the configuration conversion method to convert the configuration file of the target build tool into a general format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
[0136] Specifically, the configuration converter class can convert the configuration file of the target build tool into a common-format configuration object, ensuring the consistency of plugin configuration across different build tools. In this embodiment, the configuration converter class includes configuration conversion methods for multiple build tools. First, based on the identifier of the target build tool, the configuration conversion method corresponding to the identifier of the target build tool is searched in the configuration converter class. Then, this configuration conversion method is called to convert the configuration file of the target build tool into a common-format configuration object.
[0137] Specifically, in one feasible approach, S104 calls a configuration transformation method to convert the target build tool's configuration file into a common-format configuration object, which can be:
[0138] S1041. Retrieve the configuration file of the target build tool from local storage.
[0139] S1042. Use the configuration conversion method to convert the target build tool's configuration file into a common format configuration object, which includes input properties and output properties.
[0140] Specifically, the converted, generic configuration object includes input and output properties, which are extracted and standardized from the original configuration so that generic plugins can use them.
[0141] S1043. Apply the configuration object in a general format to the first plugin.
[0142] In one example of configuring a converter class, the Webpack configuration is first converted to a generic format, and then a new generic configuration object is created (assuming that only the entry and output parts are of interest).
[0143] If the webpack configuration object has an `entry` property and its value is not false, the `entry` configuration is copied directly. If the webpack configuration object has an `output` property and this property also contains a filename property, the filename is copied to the `outputFile` property of another configuration object for use elsewhere, and the transformed general configuration is returned.
[0144] Next, the Rollup configuration is converted to a generic format. Specifically, a new generic configuration object is created, and a function is defined that accepts the Rollup configuration as a parameter. Assuming we only care about the `input` and `output.file` parts, the function checks if the `input` property exists in the Rollup configuration. If it does, the value of the `input` property is directly copied to the `entry` property of the generic configuration, using the copied `input` configuration as the entry. Then, it checks if the `output` property exists in the Rollup configuration, and if the `output` property contains a `file` property. If both exist, the value of the `output.file` property is converted to the value of the `outputfile` property of the generic configuration, and the converted generic configuration is returned. Finally, the converted configuration is applied to the plugin. Assuming the plugin has a `setConfig` method that accepts the generic configuration, the generic configuration is applied to the plugin.
[0145] Optionally, in one usage example, a Webpack configuration and a Rollup configuration are created, and then the converter's methods are called to convert them to a common format. This way, both Webpack and Rollup users can use the same common plugin without worrying about differences in configuration formats.
[0146] It should be noted that there is no restriction on the order of execution of S102, S103 and S104.
[0147] Furthermore, in one embodiment, the method of this embodiment may further include:
[0148] S105. Obtain information about the target build tool and the first plugin.
[0149] S106. Based on the information of the target build tool and the information of the first plugin, check the compatibility between the first plugin and the target build tool.
[0150] In this embodiment, through S105 and S106, compatibility issues between plugins and build tools can be automatically detected, and repair suggestions or automatic repair functions can be provided.
[0151] Optionally, as an implementable approach, in S106, based on the information of the target build tool and the information of the first plugin, the compatibility between the first plugin and the target build tool is checked. Specifically, this can be done as follows:
[0152] S1061. Based on the information of the target build tool and the information of the first plugin, determine whether the version of the first plugin is compatible with the version of the target build tool.
[0153] Optionally, in one embodiment, S1061 may specifically be:
[0154] If the version of the target build tool is lower than the minimum version required by the first plugin, it is determined that the first plugin is incompatible with the target build tool.
[0155] If the version of the target build tool is greater than or equal to the minimum version required by the first plugin, then the first plugin is considered compatible with the target build tool.
[0156] S1062. Determine whether the target builder supports the application programming interface required by the first plugin.
[0157] Optionally, the method in this embodiment may further include: S107, displaying repair suggestions or performing automatic repair based on the compatibility check results between the first plugin and the target build tool.
[0158] In one example of performing the above compatibility checks, a constructor is first constructed to receive information about the build tool and plugins, storing the build tool information and plugin information. Next, a method for checking version compatibility compares the version numbers of the build tool and plugins. If the build tool version is lower than the minimum required version, it returns an incompatibility message; otherwise, it returns a compatibility message. A method for checking API compatibility iterates through the list of APIs required by the plugin. If the build tool does not support a certain API (e.g., a necessary API is missing), it returns an incompatibility message; if all APIs are supported, it returns a compatibility message. Finally, all checks are run, including the version compatibility check. If the versions are incompatible, the function immediately returns a version check object; if the versions are compatible, the `checkAPICompatibility` method is called, and the returned result is stored in the `apiCheck` constant, returning an API check object.
[0159] In the example above, a CompatibilityChecker class is defined to check the compatibility between plugins and build tools. The class contains several methods: a constructor for initializing information, code for checking version and API compatibility, and code for performing all checks and returning the results.
[0160] In this embodiment, developers only need to write the plugin code once, which can be used on multiple different build tools. There's no need to write specific adaptation code for each build tool. For front-end developers, they can learn one set of plugin interfaces and use it in different build tools without needing to learn different interfaces for each tool. Furthermore, plugin developers only need to maintain one set of code to ensure compatibility with multiple build tools, significantly reducing maintenance costs and the complexity of updates.
[0161] The plugin data processing method provided in this embodiment obtains a plugin usage request, which includes the code of a first plugin and the identifier of a target build tool, which is the specified build tool. Then, based on the identifier of the target build tool, the adapter for the target build tool is searched from the plugin abstract class. According to the definition of the plugin abstract class and the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application programming interface (API) of the target build tool. Next, event-driven processing is performed based on the code of the first plugin. Then, based on the identifier of the target build tool, the configuration conversion method for the target build tool is searched from the configuration converter class, and the configuration conversion method is called to convert the configuration file of the target build tool into a general-format configuration object. This enables the use of the code of the first plugin on the target build tool. Therefore, developers only need to write the plugin code once, and this plugin code can be used on multiple different build tools, achieving seamless integration between the plugin and the build tool. This improves plugin usability, increases development efficiency, and reduces maintenance costs.
[0162] Figure 3 This is a schematic diagram of the structure of a front-end building plugin interface provided in an embodiment of this application, such as... Figure 3 As shown, the front-end plugin building interface may include: a plugin abstraction unit 11, an event-driven unit 12, and a configuration conversion unit 13.
[0163] The plugin abstraction unit 11 is used to obtain a plugin usage request. The plugin usage request includes the code of the first plugin and the identifier of the target build tool. The code of the first plugin is used on the target build tool. Based on the identifier of the target build tool, the adapter of the target build tool is found from the plugin abstraction class. Based on the definition of the plugin abstraction class and the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool. The plugin abstraction class includes adapters for multiple build tools.
[0164] Specifically, front-end developers can use a client installed and running on a terminal device to develop plugins. Plugin developers can write plugin code based on the front-end build plugin interface provided in this application embodiment. This plugin code can be used on multiple build tools. The target build tool is the build tool to which the first plugin code will be used. The target build tool can be any of the following: Webpack (development language is JavaScript), Rollup (development language is JavaScript), Parcel (development language is JavaScript), Vite (development language is TypeScript), and Snowpack (development language is JavaScript), etc. Other build tools are also possible, and this embodiment does not limit this. In one embodiment, the plugin usage request is the input information of the front-end build interface. When it is necessary to use the first plugin on the target build tool, a plugin usage request is initiated, inputting the code of the first plugin and the identifier of the target build tool to the front-end build interface. Specifically, the plugin abstraction unit 11 obtains this plugin usage request.
[0165] Specifically, the front-end build plugin interface in this embodiment includes a plugin abstraction layer. This layer abstracts the core functionalities and APIs of different build tools, allowing plugin developers to program against this layer rather than against a specific build tool. The plugin abstraction layer defines a set of generic APIs that can be mapped to the corresponding functionalities of different build tools.
[0166] In one embodiment, the plugin abstraction layer includes a plugin abstract class that includes adapters for multiple build tools. The plugin abstract class defines the application methods that all adapters need to implement. Taking a target build tool as an example, the adapter for the target build tool is used to implement the capabilities that the target build tool provides to developers.
[0167] Specifically, after the plugin abstraction unit 11 obtains the plugin usage request, it searches for the adapter of the target build tool in the plugin abstraction class, and maps the behavior corresponding to the code of the first plugin to the application interface of the target build tool according to the definition of the plugin abstraction class and the adapter of the target build tool.
[0168] The event-driven unit 12 is used to perform event-driven operations based on the code of the first plugin.
[0169] Specifically, the event-driven mechanism of the front-end build plugin interface design in this embodiment allows the plugin to respond to events at key points in the build process, such as module parsing, code compression, and file output.
[0170] The configuration conversion unit 13 searches for the configuration conversion method of the target build tool in the configuration converter class based on the identifier of the target build tool, and calls the configuration conversion method to convert the configuration file of the target build tool into a general-format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
[0171] Specifically, the configuration converter class can convert the configuration file of the target build tool into a common-format configuration object, ensuring the consistency of plugin configuration across different build tools. In this embodiment, the configuration converter class includes configuration conversion methods for multiple build tools. First, based on the identifier of the target build tool, the configuration conversion method corresponding to the identifier of the target build tool is searched in the configuration converter class. Then, this configuration conversion method is called to convert the configuration file of the target build tool into a common-format configuration object.
[0172] In one embodiment, the definition of the plugin abstract class includes the code corresponding to the application methods that can be implemented by the adapter of each build tool, and the plugin abstract unit 11 is used for:
[0173] The code corresponding to the application methods that can be implemented by the adapter for each build tool;
[0174] Using the target build tool's adapter, the behavior corresponding to the code of the first plugin is mapped to the target build tool's application interface.
[0175] In one embodiment, the adapter for the target build tool includes code corresponding to hooks and methods of the target build tool, as well as code corresponding to methods that call the plugin. The plugin abstraction unit 11 is specifically used for:
[0176] Run the code corresponding to the hooks and methods of the target build tool, and run the code corresponding to the method that calls the plugin based on the code of the first plugin, so as to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool.
[0177] In one embodiment, the code of the first plugin includes an event storage object, a registration event detection function, an event triggering function, and the core functionality of the first plugin. The event storage object stores identifiers of multiple events and an array of detection functions corresponding to multiple events. The event driving unit 12 is used for:
[0178] Based on the event storage object, the event detection function, the event triggering function, and the core functionality of the first plugin, events are registered and triggered.
[0179] The event storage object stores identifiers for multiple events and an array of corresponding event detection functions. Registering event detection functions allows external events to register detection functions for the events stored in the event storage object. Triggering event functions trigger these events stored in the event storage object at appropriate times. When the target build tool runs, the registered event detection functions will be called at the appropriate time, thus implementing a basic event-driven mechanism.
[0180] In one embodiment, the configuration conversion unit 13 is used for:
[0181] Retrieve the configuration file for the target build tool from local storage;
[0182] The configuration transformation method is used to convert the target build tool's configuration file into a common format configuration object, which includes input and output properties.
[0183] Apply a configuration object in a generic format to the first plugin.
[0184] The front-end build plugin interface provided in this embodiment allows developers to write plugin code only once. Through this interface, the plugin code can be implemented on a specified build tool and then used on that tool. Specifically, the front-end build plugin interface obtains a plugin usage request, which includes the code of a first plugin and the identifier of the target build tool (the specified build tool). Then, based on the identifier of the target build tool, it searches for the adapter for the target build tool in the plugin abstract class. According to the definition of the plugin abstract class and the adapter, the behavior corresponding to the first plugin code is mapped to the application interface of the target build tool. Next, based on the first plugin code, event-driven processing is performed. Then, based on the identifier of the target build tool, it searches for the configuration conversion method of the target build tool in the configuration converter class and calls the configuration conversion method to convert the target build tool's configuration file into a generic configuration object. This enables the use of the first plugin code on the target build tool. Therefore, developers only need to write the plugin code once, and this code can be used on multiple different build tools, achieving seamless integration between the plugin and the build tool. This improves plugin usability, increases development efficiency, and reduces maintenance costs.
[0185] The front-end build plugin interface provided in this embodiment allows developers to write plugin code only once, which can be used on multiple different build tools. Front-end developers can learn one plugin interface and use it across different build tools without needing to learn different plugin systems for each tool. A unified plugin interface helps standardize the front-end development process, reducing the cost of switching between different build tools. It also reduces plugin instability caused by differences in build tools, improving overall plugin reliability. Plugin developers only need to maintain one set of code to be compatible with multiple build tools, significantly reducing maintenance costs and the complexity of updates.
[0186] Figure 4 This is a schematic diagram of the structure of a front-end building plugin interface provided in an embodiment of this application, such as... Figure 4 As shown, the front-end building plugin interface in this embodiment may further include:
[0187] The compatibility check unit 14 is used to obtain information about the target build tool and the first plugin, and check the compatibility between the first plugin and the target build tool based on the information about the target build tool and the first plugin.
[0188] In one embodiment, the compatibility checking unit 14 is specifically used for:
[0189] Based on the information of the target build tool and the information of the first plugin, determine whether the version of the first plugin is compatible with the version of the target build tool;
[0190] Determine whether the target builder supports the application programming interface required by the first plugin.
[0191] In one embodiment, the compatibility checking unit 14 is specifically used for:
[0192] If the version of the target build tool is lower than the minimum version required by the first plugin, it is determined that the first plugin is incompatible with the target build tool.
[0193] If the version of the target build tool is greater than or equal to the minimum version required by the first plugin, then the first plugin is considered compatible with the target build tool.
[0194] Figure 5 This is a schematic diagram of the structure of a plug-in data processing device provided in an embodiment of this application, as shown below. Figure 5 As shown, the device may include: an acquisition module 21, a first processing module 22, an event-driven module 23, and a second processing module 24.
[0195] The acquisition module 21 is used to acquire a plugin usage request. The plugin usage request includes the code of the first plugin and the identifier of the target build tool. The code of the first plugin is used on the target build tool.
[0196] The first processing module 22 is used to find the adapter of the target build tool from the plugin abstract class according to the identifier of the target build tool, and to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool according to the definition of the plugin abstract class and the adapter of the target build tool. The plugin abstract class includes adapters of multiple build tools.
[0197] The event-driven module 23 is used to perform event-driven operations based on the code of the first plugin.
[0198] The second processing module 24 is used to find the configuration conversion method of the target build tool from the configuration converter class according to the identifier of the target build tool, and call the configuration conversion method to convert the configuration file of the target build tool into a general format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
[0199] In one embodiment, the definition of the plugin abstract class includes the code corresponding to the application methods that can be implemented by the adapter of each build tool, and the first processing module 22 is used for:
[0200] The code corresponding to the application methods that can be implemented by the adapter for each build tool;
[0201] Using the target build tool's adapter, the behavior corresponding to the code of the first plugin is mapped to the target build tool's application interface.
[0202] In one embodiment, the adapter for the target build tool includes code corresponding to hooks and methods of the target build tool, as well as code corresponding to methods that call the plugin. The first processing module 22 is specifically used for:
[0203] Run the code corresponding to the hooks and methods of the target build tool, and run the code corresponding to the method that calls the plugin based on the code of the first plugin, so as to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool.
[0204] In one embodiment, the code of the first plugin includes an event storage object, a registration event detection function, an event triggering function, and the core functionality of the first plugin. The event storage object stores identifiers of multiple events and an array of detection functions corresponding to multiple events. The event-driven module 23 is used for:
[0205] Based on the event storage object, the event detection function, the event triggering function, and the core functionality of the first plugin, events are registered and triggered.
[0206] In one embodiment, the second processing module 24 is used to:
[0207] Retrieve the configuration file for the target build tool from local storage;
[0208] The configuration transformation method is used to convert the target build tool's configuration file into a common format configuration object, which includes input and output properties.
[0209] Apply a configuration object in a generic format to the first plugin.
[0210] In one embodiment, the second processing module 24 is further configured to:
[0211] Obtain information about the target build tool and the first plugin, and based on the information about the target build tool and the first plugin, check the compatibility between the first plugin and the target build tool.
[0212] In one embodiment, the second processing module 24 is specifically used for:
[0213] Based on the information of the target build tool and the information of the first plugin, determine whether the version of the first plugin is compatible with the version of the target build tool;
[0214] Determine whether the target builder supports the application programming interface required by the first plugin.
[0215] In one embodiment, the second processing module 24 is specifically used for:
[0216] If the version of the target build tool is lower than the minimum version required by the first plugin, it is determined that the first plugin is incompatible with the target build tool.
[0217] If the version of the target build tool is greater than or equal to the minimum version required by the first plugin, then the first plugin is considered compatible with the target build tool.
[0218] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be found in the method embodiments. To avoid repetition, further details are omitted here. Specifically, Figure 5 The plug-in data processing device shown can execute the method embodiment corresponding to the electronic device, and the foregoing and other operations and / or functions of each module in the device are respectively for implementing the method embodiment corresponding to the electronic device. For the sake of brevity, they will not be described in detail here.
[0219] The abnormal text detection model training device and abnormal text detection device of this application embodiments have been described above from the perspective of functional modules, with reference to the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by the integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiments can be directly manifested as execution by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.
[0220] Figure 6 This is a schematic block diagram of the electronic device 700 provided in the embodiments of this application.
[0221] like Figure 6 As shown, the electronic device 700 may include:
[0222] The system includes a memory 710 and a processor 720. The memory 710 stores computer programs and transfers the program code to the processor 720. In other words, the processor 720 can retrieve and run the computer program from the memory 710 to implement the methods described in the embodiments of this application.
[0223] For example, the processor 720 can be used to execute the above-described method embodiments according to instructions in the computer program.
[0224] In some embodiments of this application, the processor 720 may include, but is not limited to:
[0225] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
[0226] In some embodiments of this application, the memory 710 includes, but is not limited to:
[0227] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).
[0228] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 710 and executed by the processor 720 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.
[0229] like Figure 6 As shown, the electronic device may also include:
[0230] Transceiver 730, which can be connected to processor 720 or memory 710.
[0231] The processor 720 can control the transceiver 730 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 730 may include a transmitter and a receiver. The transceiver 730 may further include antennas, and the number of antennas may be one or more.
[0232] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.
[0233] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.
[0234] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).
[0235] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0236] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.
[0237] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.
[0238] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A plug-in data processing method, characterized in that, include: Obtain a plugin usage request, the plugin usage request including the code of a first plugin and the identifier of a target build tool, wherein the code of the first plugin is used on the target build tool; Based on the identifier of the target build tool, the adapter of the target build tool is found from the plugin abstract class. Based on the definition of the plugin abstract class and the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool. The plugin abstract class includes adapters for multiple build tools. Based on the code of the first plugin, event-driven operation is implemented; Based on the identifier of the target build tool, the configuration conversion method of the target build tool is located in the configuration converter class, and the configuration conversion method is called to convert the configuration file of the target build tool into a general-format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
2. The method according to claim 1, characterized in that, The definition of the plugin abstract class includes the code corresponding to the application methods that can be implemented by the adapter of each build tool. The step of mapping the behavior corresponding to the code of the first plugin to the application programming interface of the target build tool based on the definition of the plugin abstract class and the adapter of the target build tool includes: The code corresponding to the application methods that can be implemented by running the adapter of each of the aforementioned build tools; Using the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool.
3. The method according to claim 2, characterized in that, The adapter for the target build tool includes code corresponding to hooks and methods of the target build tool, as well as code corresponding to methods that call the plugin. The step of using the adapter to map the behavior corresponding to the code of the first plugin to the application programming interface (API) of the target build tool includes: Run the code corresponding to the hooks and methods of the target build tool, and run the code corresponding to the method that calls the plugin according to the code of the first plugin, so as to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool.
4. The method according to claim 1, characterized in that, The code of the first plugin includes an event storage object, a registration event detection function, an event triggering function, and the core functionality of the first plugin. The event storage object stores identifiers for multiple events and an array of detection functions corresponding to multiple events. The event-driven mechanism based on the code of the first plugin includes: Events are registered and triggered based on the event storage object, the event registration detection function, the event triggering function, and the core functionality of the first plugin.
5. The method according to claim 1, characterized in that, The step of calling the configuration conversion method to convert the target build tool's configuration file into a common-format configuration object includes: Retrieve the configuration file of the target build tool from local storage; Using the configuration conversion method, the configuration file of the target build tool is converted into a general-format configuration object, which includes input attributes and output attributes. Apply the configuration object in the general format to the first plugin.
6. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain information about the target build tool and the first plugin; Based on the information of the target build tool and the information of the first plugin, check the compatibility between the first plugin and the target build tool.
7. The method according to claim 6, characterized in that, The step of checking the compatibility between the first plugin and the target build tool based on the information of the target build tool and the information of the first plugin includes: Based on the information of the target build tool and the information of the first plugin, determine whether the version of the first plugin is compatible with the version of the target build tool; Determine whether the target builder supports the application programming interface required by the first plugin.
8. The method according to claim 7, characterized in that, The step of determining whether the version of the first plugin is compatible with the version of the target build tool based on the information of the target build tool and the information of the first plugin includes: If the version of the target build tool is lower than the minimum version required by the first plugin, it is determined that the first plugin is incompatible with the target build tool; If the version of the target build tool is greater than or equal to the minimum version required by the first plugin, the first plugin is determined to be compatible with the target build tool.
9. A front-end build plugin interface, characterized in that, include: A plugin abstraction unit is used to obtain a plugin usage request. The plugin usage request includes the code of a first plugin and the identifier of a target build tool. The code of the first plugin is used on the target build tool. Based on the identifier of the target build tool, the adapter of the target build tool is found from the plugin abstraction class. Based on the definition of the plugin abstraction class and the adapter of the target build tool, the behavior corresponding to the code of the first plugin is mapped to the application interface of the target build tool. The plugin abstraction class includes adapters for multiple build tools. An event-driven unit is used to perform event-driven operations based on the code of the first plugin. The configuration conversion unit is used to find the configuration conversion method of the target build tool from the configuration converter class according to the identifier of the target build tool, and call the configuration conversion method to convert the configuration file of the target build tool into a general format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
10. The front-end building plugin interface according to claim 9, characterized in that, Also includes: A compatibility checking unit is used to obtain information about the target build tool and the first plugin, and to check the compatibility between the first plugin and the target build tool based on the information about the target build tool and the first plugin.
11. A plug-in data processing device, characterized in that, include: The acquisition module is used to acquire a plugin usage request, which includes the code of a first plugin and the identifier of a target build tool, wherein the code of the first plugin is used on the target build tool; The first processing module is used to find the adapter of the target build tool from the plugin abstract class according to the identifier of the target build tool, and to map the behavior corresponding to the code of the first plugin to the application interface of the target build tool according to the definition of the plugin abstract class and the adapter of the target build tool. The plugin abstract class includes adapters of multiple build tools. The event-driven module is used to perform event-driven operations based on the code of the first plugin; The second processing module is used to find the configuration conversion method of the target build tool from the configuration converter class according to the identifier of the target build tool, and call the configuration conversion method to convert the configuration file of the target build tool into a general format configuration object. The configuration converter class includes configuration conversion methods for multiple build tools.
12. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the method of any one of claims 1 to 8.
13. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer program, cause the computer to perform the method as described in any one of claims 1 to 8.
14. A computer program product containing instructions, characterized in that, When the instructions are executed on a computer, the computer causes the computer to perform the method of any one of claims 1 to 8.