Front-end SDK adaptation product generation method, device, equipment and medium

Abstract

This application provides a method, apparatus, device, and medium for generating front-end SDK adaptation artifacts, relating to the field of software development technology. The method includes: obtaining runtime constraints of multiple ports within the port range to be adapted by the front-end SDK; generating source code entry files for each port based on the runtime constraints of each port and the source code of the front-end SDK; generating code artifacts and code directories for each port, and type artifacts and type directories for each port based on the runtime capability constraints and the source code entry files of each port; configuring access based on the runtime capability constraints, code directories, and type directories of each port, and generating package description files for each port; generating the deployment structure of each port based on the code directories, type directories, and package description files; and generating the front-end SDK's deployment artifacts to be released based on the code artifacts, type artifacts, and deployment structure of multiple ports. This application can reduce the complexity of building multi-port SDKs.

Description

Technical Field

[0001] This application relates to the field of software development technology, and more specifically, to a method, apparatus, device, and medium for generating front-end SDK adaptation artifacts. Background Technology

[0002] With the diversification of front-end business, the same Software Development Kit (SDK) often needs to serve multiple platforms simultaneously, including the Web, UniApp, Alipay Mini Programs, WeChat Mini Programs, and browser script direct loading. These different platforms differ significantly in module parsing rules, directory access methods, module format requirements, and type definitions. For example, Alipay Mini Programs do not support exported fields in description files and can only access modules through physical file paths; while the Web environment fully supports standard path mapping.

[0003] In existing technologies, multi-entry packaging combined with statically exported field configurations is commonly used, or the system is split into multiple independent packages based on ports. However, multi-entry packaging can easily lead to a disconnect between code artifacts, type artifacts, and the release structure, making it difficult to maintain the configurations for each port; splitting the system into multiple packages based on ports results in high maintenance costs for multiple packages, duplication of shared logic, and version drift.

[0004] Therefore, how to automatically generate products adapted to the differences in runtime across multiple ports based on a single source code, while maintaining consistency and maintainability among the products, has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for generating front-end SDK adaptation artifacts, which can reduce the complexity of building multi-port SDKs.

[0006] In a first aspect, embodiments of this application provide a method for generating front-end SDK adaptation artifacts, the method comprising: Based on the range of ports to be adapted in the front-end SDK, obtain the runtime constraints of multiple ports within the range of ports to be adapted; Based on the runtime constraints of each port and the source code of the front-end SDK, generate the source code entry file of the front-end SDK for each port; Based on the runtime capability constraints of each port and the source code entry file of the port, generate the code artifacts and code directory of the port, as well as the type artifacts and type directory of the port; Based on the runtime capability constraints of each port, the code directory, and the type directory, access configuration is performed to generate a packet description file for each port; the packet description file includes at least an access policy, which is used to access the code artifacts and the type artifacts; Based on the code directory, type directory, and package description file of each port, generate the distribution structure of the port; Based on the code artifacts, type artifacts, and release structure of the multiple ports, generate the adaptation artifacts to be released for the front-end SDK.

[0007] Optionally, the runtime constraints include: runtime capability constraints and runtime interface constraints; the step of generating the code artifacts and code directory of the port, and the type artifacts and type directory of the port, based on the runtime capability constraints of each port and the source code entry file of the port, includes: Based on the runtime capability constraints of each port, the source code entry file of the port is compiled to obtain the code artifacts and code directory of the port; Based on the runtime interface constraints of each port and the source code entry file of the corresponding port, the type artifacts and type directories of the port are generated.

[0008] Optionally, the step of compiling the source code entry file of each port according to the runtime capability constraints of each port to obtain the code artifacts and code directory of the port includes: Based on the runtime capability constraints of each port, determine the code artifact format and target layout method corresponding to the port; Using the aforementioned code artifact format and target layout method, the source code entry file of the port is compiled to obtain the port's code artifact and code directory.

[0009] Optionally, generating the type artifacts and type directories for each port based on its runtime interface constraints and the corresponding port's source code entry file includes: Based on the runtime interface constraints of the port, determine the interface parameter information corresponding to the port from the source code entry file of the port; Generate the product of the type based on the interface parameter information; Generate the type directory based on the port identifier of the port.

[0010] Optionally, the step of configuring access based on the runtime capability constraints of each port, the code directory, and the type directory, and generating a packet description file for each port, includes: Based on the runtime capability constraints of each port, obtain a structured representation of the port's capabilities; Based on the code directory and the type directory, determine the code artifact path and type artifact path of the port; Based on the structured representation of the capabilities, the access strategy is determined, and the access strategy, along with the code artifact path and the type artifact path, are hierarchically encoded to generate the package description file.

[0011] Optionally, determining the access strategy based on the structured representation of the capability includes: If the capability structured expression is a first capability structured expression, then the standard path mapping strategy is determined as the access strategy; If the capability structured expression is a second capability structured expression, then the physical file path access strategy is determined as the access strategy.

[0012] Optionally, the method further includes: If the runtime constraint of the port is a browser direct-access scenario for a web page port, then the browser direct-output product of the port is generated based on the source code of the front-end SDK. The step of generating the release-ready adaptation product of the front-end SDK based on the code artifacts, type artifacts, and release structure of multiple ports includes: Based on the code artifacts, type artifacts, browser output artifacts, and release structure of the multiple ports, the release adaptation artifacts of the front-end SDK are generated.

[0013] Secondly, embodiments of this application also provide a front-end SDK adaptation product generation apparatus, the apparatus comprising: The acquisition module is used to acquire the runtime constraints of multiple ports within the port range to be adapted, based on the port range to be adapted in the front-end SDK. A generation module is used to generate the source code entry file of the front-end SDK for each port based on the runtime constraints of each port and the source code of the front-end SDK; generate the code artifacts and code directory of the port, and the type artifacts and type directory of the port based on the runtime capability constraints of each port and the source code entry file of the port; perform access configuration based on the runtime capability constraints of each port, the code directory, and the type directory, and generate the package description file of the port; the package description file includes at least an access policy, which is used to access the code artifacts and the type artifacts; generate the release structure of the port based on the code directory, type directory, and package description file of each port; and generate the adaptation artifacts to be released for the front-end SDK based on the code artifacts, type artifacts, and release structure of multiple ports.

[0014] Thirdly, embodiments of this application also provide a computer device, including: a processor, a memory, and a bus, wherein the memory stores program instructions executable by the processor, and when the computer device is running, the processor communicates with the memory via the bus, and the processor executes the program instructions to perform the steps of the front-end SDK adaptation product generation method as described in any of the first aspects. Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the front-end SDK adaptation product generation method as described in any of the first aspects.

[0015] This application provides a method, apparatus, device, and medium for generating front-end SDK adaptation artifacts. First, based on the range of ports that the front-end SDK needs to support, the runtime constraints corresponding to each port are obtained. Then, based on the runtime constraints of each port and the source code of the front-end SDK, a source code entry file bound to its runtime behavior is generated for each port. Next, based on the runtime capability constraints of each port and the corresponding source code entry file, code artifacts and their code directories, as well as type artifacts and their type directories, are constructed for each port. On this basis, combining the runtime capability constraints of each port with the generated code and type directories, access configuration is performed, generating a package description file containing access policies for each port. Then, based on the code directory, type directory, and package description file of each port, an independent release structure for that port is organized. Finally, the code artifacts, type artifacts, and release structures of all ports are summarized to obtain a complete adaptation artifact that the front-end SDK can uniformly release. By using the above methods, the same set of source code can automatically generate matching adaptation artifacts for different ports, while maintaining consistency in code, type, and release structure. This not only significantly improves the efficiency of building and releasing multi-port SDKs, but also significantly reduces the repetitive workload caused by manually maintaining multi-entry configurations and multi-package version drift. It realizes intelligent and unified distribution of front-end SDKs in multiple runtime environments, effectively reducing the complexity and maintenance cost of multi-port adaptation. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a method for generating front-end SDK adaptation artifacts provided in an embodiment of this application; Figure 2A flowchart illustrating the generation of port code artifacts and code directories in a front-end SDK adaptation artifact generation method provided in this application embodiment; Figure 3 A flowchart illustrating the generation of port type artifacts and type directories in a front-end SDK adaptation artifact generation method provided in this application embodiment; Figure 4 A flowchart illustrating the process of generating a port's packet description file in a front-end SDK adaptation artifact generation method provided in this application embodiment; Figure 5 A schematic diagram of a front-end SDK adaptation product generation device provided in an embodiment of this application; Figure 6 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0019] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] Before providing a detailed explanation of this application, let's first introduce its application scenarios.

[0022] In real-world applications that rely on multi-port distribution of front-end SDKs, such as Web engineering development, browser script direct loading, UniApp cross-platform development, Alipay mini-program development, and WeChat mini-program development, significant differences exist in the runtime environments of different ports regarding module parsing rules, directory access methods, module format requirements, and type definition support. Therefore, it is often necessary to adapt the same SDK source code to the output of multiple ports and then configure access mappings separately for each port's consumer. For example, in the Alipay mini-program development scenario, the runtime of this port does not support the `exports` field in the package description file; consumers can only access modules through physical file paths. If the standard sub-path export method is still used, module loading will fail.

[0023] Based on this, this application provides a method, apparatus, device, and medium for generating front-end SDK adaptation artifacts. First, based on the range of ports that the front-end SDK needs to support, the runtime constraints corresponding to each port are obtained. Then, based on the runtime constraints of each port and the source code of the front-end SDK, a source code entry file bound to its runtime behavior is generated for each port. Next, based on the runtime capability constraints of each port and the corresponding source code entry file, code artifacts and their code directories, type artifacts and their type directories are constructed for each port. On this basis, combined with the runtime capability constraints of each port and the generated code and type directories, access configuration is performed, generating a package description file containing access strategies for each port. Then, based on the code directory, type directory, and package description file of each port, an independent release structure for that port is organized. Finally, the code artifacts, type artifacts, and release structures of all ports are summarized to obtain a complete adaptation artifact that the front-end SDK can uniformly release. This significantly reduces the repetitive workload caused by manually maintaining multi-entry configurations and multi-package version drift, realizing intelligent unified distribution of the front-end SDK in multiple runtime environments, and effectively reducing the complexity and maintenance cost of multi-port adaptation.

[0024] The following explanation, in conjunction with the accompanying drawings, uses several embodiments to illustrate the concepts.

[0025] The front-end SDK adaptation artifact generation method provided in this application can be implemented by a computer device (such as a build server, personal computer, or cloud build platform) by executing a preset build script or build tool. This application does not impose any restrictions on the specific form of the computer device, as long as it can execute the method steps disclosed in this application.

[0026] Figure 1 This is a flowchart illustrating a method for generating front-end SDK adaptation artifacts provided in an embodiment of this application, as shown below. Figure 1 As shown, the method for generating the front-end SDK adaptation artifact includes: S101: Based on the range of ports to be adapted in the front-end SDK, obtain the runtime constraints of multiple ports within the range of ports to be adapted. First, it's necessary to define the port range that the front-end SDK needs to adapt to. The port refers to the type of consumer the SDK will support, such as Web client, UniApp, Alipay mini-program, WeChat mini-program, etc. The port range to be adapted can be pre-configured based on the SDK's business requirements, or it can be read from a configuration file (such as a port list in the configuration file or build script).

[0027] Obtain runtime constraints for multiple ports within the range of ports to be adapted. Runtime constraints include the module formats supported by the port (such as ESM, CJS, UMD), whether it supports exported fields in the package description file, and the differences in parameter types for the same functional interface on different ports (for example, the "Create Uploader" interface on the Web port receives a browser file object, while the "Create Uploader" interface on the Alipay Mini Program port receives a file path string).

[0028] For example, the Web engineering environment supports exported fields in package description files and can recognize ESM and CJS module formats; the Alipay Mini Program environment does not support exported fields and can only access modules through physical file paths; the WeChat Mini Program environment supports ESM format but not CJS format; browser direct import scenarios do not involve packaging tools and require independent executable script files. Meanwhile, differences in parameter types for the same interface across different ports are also part of runtime constraints.

[0029] By obtaining these runtime constraints, a basis can be provided for generating differentiated code artifacts and type artifacts for different ports.

[0030] S102 generates the source code entry file for each port of the front-end SDK based on the runtime constraints of each port and the source code of the front-end SDK.

[0031] After obtaining the runtime constraints of each port, an independent source code entry file is created for each port, so that each entry is directly bound to the runtime behavior corresponding to the port.

[0032] The source code of a front-end SDK typically contains common code that implements business logic, as well as specific implementation code for different runtime environments. Based on the runtime constraints of each port, the specific implementation code that the port needs to call is determined, and a corresponding source code entry file is generated, ensuring that the source code entry file only contains the runtime code actually needed by that port.

[0033] For example, in the general toolkit named `@rrzu / utils`, separate source code entry files can be created for Node.js (common), browser (web), mini-program (mp), UniApp cross-platform framework (uniapp), and third-party integration scenarios (integrations). Similarly, in the object storage upload toolkit named `@rrzu / oss-sdk`, separate source code entry files can be created for browser (web), Alipay mini-program (mp-alipay), WeChat mini-program (mp-weixin), and UniApp (uniapp). Taking `@rrzu / oss-sdk` as an example, the `main-web.ts` file corresponds to the upload behavior in the browser environment (calling the browser's network request interface), while the `main-mp-alipay.ts` file corresponds to the upload behavior in the Alipay mini-program environment (calling the Alipay mini-program platform's upload interface). These two files reflect the differences in actual capabilities under different runtime environments. The entry files for different ports are independent of each other, each bound to the actual runtime capabilities under its respective port.

[0034] Optionally, the source code entry file can be generated based on a preset entry template, or it can be automatically generated from the source code directory by the build tool. By generating a separate source code entry file for each port, the build entry for each port can reflect the unique implementation logic of that port.

[0035] S103 generates the port's code artifacts and code directory, as well as the port's type artifacts and type directory, based on the runtime capability constraints of each port and the port's source code entry file.

[0036] After obtaining the source code entry file for each port, perform a build operation independently for each port.

[0037] Specifically, based on the runtime capability constraints of the port, the source code entry file of the port is used as the build entry point, and corresponding code artifacts are generated through operations such as compilation and packaging. The code artifacts include executable JavaScript files, the format of which (such as ESM, CJS, UMD, etc.) matches the module loading capability of the port.

[0038] Meanwhile, based on the runtime interface constraints of each port, the source code entry file of the same port is used as the type source to generate corresponding type artifacts (i.e., TypeScript type definition files) for each port. The type artifacts of different ports are independent of each other, avoiding type mismatch problems caused by sharing the same type file.

[0039] When generating code artifacts and type artifacts, corresponding storage directories are created for them: the code directory is used to store code artifacts, and the type directory is used to store type artifacts. The type directory and the code directory of the same port are corresponding in the path (for example, when the code directory is es / web / , the type directory is types / web / ).

[0040] S104. Based on the runtime capability constraints, code directory, and type directory of each port, configure access and generate a packet description file for the port. The packet description file includes at least an access policy, which is used to access code artifacts and type artifacts.

[0041] After generating the code artifacts and type artifacts for each port, a package description file (package.json file) needs to be configured so that users on different ports can correctly access the code artifacts and type artifacts they need. The package description file is a standard file in the Node.js ecosystem used to describe package metadata and export mappings.

[0042] Specifically, based on the runtime capability constraints of each port and the directory locations of its code and type artifacts (i.e., the code directory and type directory), a corresponding access strategy is generated. The access strategy defines the mapping relationship between external import paths and actual file paths within the package. For example, for ports that support exported fields, subpath mapping can be configured in the fields of the package description file; for ports that do not support exported fields, access is achieved through other methods (such as physical path conventions). Subpath mapping refers to mapping the port identifier as a subpath of the import path to the corresponding code and type directories.

[0043] The package description file must contain at least an access policy to guide the build tools or runtime environment on how to locate the code artifacts and type artifacts of the corresponding ports based on the import path.

[0044] In this way, consumers on different ports do not need to care about the specific directory structure inside the package; they only need to import it according to the agreed subpath or file path.

[0045] S105 generates the port distribution structure based on the code directory, type directory, and package description file for each port.

[0046] After generating the code directory, type directory, and package description file, they need to be compiled according to a reproducible organizational structure to form the release structure for each port. The release structure refers to the external release organization method composed of the artifact directory, the exports field and typesVersions field in the package.json file, and publisherConfig.directory.

[0047] Specifically, the code directory and type directory for each port are placed in the artifact directory, and the corresponding access entry is configured for that port in the package description file. The configuration method for different ports varies depending on their runtime capabilities: for ports that support path mapping, sub-path mapping is configured in the exports field, pointing the port identifier to the code directory and type directory within the artifact directory; for ports that do not support path mapping, no exports entry is configured, and access is directly via the physical path in the artifact directory.

[0048] Additionally, regardless of whether the port supports path mapping, the mapping path of the type directory is configured in the typesVersions field to ensure compatibility with older TypeScript toolchains.

[0049] Finally, specify the artifact directory as the publishing source using the publishConfig.directory field.

[0050] In this way, different ports of the same SDK can coexist within the same package, and each can be accessed in the way most suitable for that port.

[0051] S106 generates the front-end SDK's adaptable artifacts to be released based on the code artifacts, type artifacts, and release structure of multiple ports.

[0052] After generating the deployment structure for all ports, the deployment structures for each port are summarized, and the corresponding code artifacts and type artifacts are added to form the deployment adaptation artifacts for the front-end SDK. The deployment adaptation artifacts include the code artifacts, type artifacts, package description files, and the storage directories for the code and type artifacts for all ports to be adapted.

[0053] When generating the adaptation artifacts to be released, it is also necessary to uniformly control the version number.

[0054] Specifically, the current version number is read from the front-end SDK's package.json file and written into the code artifacts of each port (e.g., by adding a version number comment at the beginning of the code artifact file). Then, the adaptation artifacts to be released are uniformly output to a release directory named after the package name (e.g., dist / ). <package>By uniformly writing version numbers and uniformly aggregating directories, we ensure that the outputs from different ports are consistent in both version and directory dimensions.

[0055] After compiling the adaptation artifacts, the unified release directory is directly published to the private npm repository using a scaffolding tool or a release script. Since the release directory already contains code artifacts, type artifacts, package description files, and corresponding directories for multiple ports, a single release can complete the unified distribution of the same SDK across multiple ports.

[0056] In this embodiment, the same set of source code can automatically generate matching adaptation artifacts for different ports, and maintain the consistency of code, type and release structure. This not only greatly improves the efficiency of building and releasing multi-port SDKs, but also significantly reduces the repetitive workload caused by manually maintaining multi-entry configurations and multi-package version drift. It realizes intelligent unified distribution of front-end SDKs in multiple runtime environments, and effectively reduces the complexity and maintenance cost of multi-port adaptation.

[0057] In the above Figure 1 Based on the corresponding embodiments, to more clearly illustrate the process of generating port code artifacts and code directories, type artifacts and type directories, this application also provides a possible implementation of generating port code artifacts and code directories, type artifacts and type directories in the front-end SDK adaptation artifact generation method. Optionally, in the above S103, according to the runtime capability constraints of each port and the port's source code entry file, generating port code artifacts and code directories, port type artifacts and type directories includes: S210 compiles the source code entry file of each port according to the runtime capability constraints of each port, and obtains the port's code artifacts and code directory.

[0058] The runtime capability constraints include at least the module formats supported by the port (such as ESM, CJS, UMD) and whether it supports exported fields in the package description file.

[0059] Specifically, the source code entry file of the specified port is used as the compilation entry point. Build tools (such as Rollup, Vite, etc.) are called to read the contents of the source code entry file and compile it. Based on the module format requirements specified in the runtime capability constraints, the build tool packages the source code entry file and its dependent modules into one or more executable files, i.e., code artifacts. During compilation, the underlying logic code shared between different ports is automatically identified and extracted, stored in a unified public directory. The advantage of this is that when each port generates its own code artifact, it only needs to retain the unique logic related to its own port and can complete the function implementation by referencing the shared code in the public directory. This avoids the same logic being repeatedly packaged in the artifacts of different ports and maintains the independence and maintainability of each port's artifacts. The code artifact contains all the runnable logic of the SDK under that port. However, due to differences in runtime capabilities between different ports, their code artifacts only contain the implementation code actually needed by that port (for example, the artifact on the browser side does not contain the platform interface calls of the mini-program), thus ensuring that the artifact size of each port is minimized and that no code that cannot run on that port is introduced.

[0060] After compilation, the code artifacts are stored in the corresponding code directory based on whether the port supports the exported fields in the package descriptor file. This directory decision is automatically made during the build phase based on the port's runtime capabilities, rather than being handled by the consumer. Each port's code directory is associated with its identifier, allowing subsequent location of the corresponding code directory based on the port identifier.

[0061] S220 generates the port type artifacts and type directories based on the runtime interface constraints of each port and the corresponding port's source code entry file.

[0062] Among them, runtime interface constraints include differences in parameter types for the same interface on different ports.

[0063] Specifically, using the source code entry file of the corresponding port as the type source, and combining it with the runtime interface constraints of that port, the actual parameter type information of each interface exposed by that port is extracted from the source code entry file. Based on the extracted type information, an independent type artifact is generated for that port. Each port's type artifact only describes the interface constraints under that port, and they do not interfere with each other.

[0064] Simultaneously, a corresponding type directory is created for each port to store the type artifacts for that port. The type directory and the code directory are associated using the same port identifier, and there is a one-to-one correspondence between them in the path. This one-to-one correspondence is automatically derived from the same port entry configuration during the build phase, rather than being manually maintained, thus ensuring that there will be no path misalignment. When a consumer references the code artifact of a certain port, the editor can automatically match the type artifact of the same port, thereby providing accurate type hints.

[0065] In this way, each port obtains a type artifact that matches its runtime capabilities. Type differences of the same interface across different ports are accurately recorded in their respective type artifacts, avoiding the ambiguity in type definitions caused by sharing the same type file. Each port's type artifact reflects the actual parameter constraints for that port, allowing developers to obtain type hints consistent with the current port environment during the coding phase, eliminating the need to manually determine parameter types from shared types across multiple ports. This design ensures strict consistency between type artifacts and code artifacts at the port level, providing a reliable type-level guarantee for the unified distribution of multi-port SDKs.

[0066] In this embodiment, code artifacts and type artifacts are generated based on runtime capability constraints and runtime interface constraints, respectively. This enables the same SDK to automatically obtain code files and type files with matching formats on different ports, and the directory structures of the two maintain a corresponding relationship, effectively avoiding the problem of misaligned paths between code artifacts and type artifacts.

[0067] Based on the embodiment corresponding to S210 above, in order to more clearly demonstrate the process of generating port code artifacts and code directories, this application also provides a possible implementation of generating port code artifacts and code directories in the front-end SDK adaptation artifact generation method. Figure 2 This is a flowchart illustrating the process of generating port code artifacts and code directories in a front-end SDK adaptation artifact generation method provided in an embodiment of this application. Figure 2 As shown, in step S210 above, based on the runtime capability constraints of each port, the source code entry file of the port is compiled to obtain the port's code artifacts and code directory, including: S310 determines the code artifact format and target layout method corresponding to each port based on the runtime capability constraints of each port.

[0068] Specifically, determine the appropriate code artifact format for the current port. Different ports have different requirements for module formats: for example, a web engineering environment needs to support both ESM and CJS formats to ensure compatibility with different build tools; the WeChat Mini Program environment only supports ESM format and not CJS; the UniApp port is compatible with both ESM and CJS formats; and web browser direct-entry scenarios do not have a module system and need to be packaged into a standalone executable file in UMD format. Based on the specific requirements of the port, determine the corresponding artifact format; if necessary, multiple code artifact formats can be generated simultaneously for a single port.

[0069] Simultaneously, the target layout of the code artifacts is determined based on whether the port supports the `exports` field in the package description file. If the port supports the `exports` field, i.e., supports path mapping (such as in Web engineering environments, WeChat Mini Program environments, and UniApp environments), the target layout is a subdirectory layout, storing the code artifacts in a subdirectory named after the port identifier (e.g., the code artifacts for the web port are stored in the `es / web / ` directory), and subsequent path mapping is performed through the `exports` field. If the port does not support the `exports` field, i.e., does not support path mapping (such as in the Alipay Mini Program environment), the target layout is a root directory layout, storing the code artifacts directly in the root directory of the SDK so that consumers can access them directly through physical file paths.

[0070] The S320 uses a code artifact format and target layout method to compile the port's source code entry file, resulting in the port's code artifacts and code directory.

[0071] After determining the code artifact format and target layout, the build tool (such as Rollup, Vite, etc.) is invoked to use the port's source code entry file as the build entry point and compile and package the artifacts according to the determined artifact format.

[0072] For ports that need to retain the source code module structure (such as the general utility class ports in @rrzu / utils and @rrzu / biz-utils), the original source code module structure can be preserved through the Rollup's preserveModules and preserveModulesRoot configurations, while simultaneously outputting the root directory ESM artifacts, CJS directory artifacts, and browser-direct artifacts.

[0073] For ports that need to be distributed by port (such as upload ports in @rrzu / oss-sdk), the output is a port-specific directory structure named after the port identifier (such as es / web / index.js), as well as a UMD file for browser script consumption. For some ports that rely more on direct directory access (such as Alipay mini-program ports that do not support the exports field), the root directory ESM structure is also retained to ensure compatibility with accessing modules via physical paths.

[0074] During compilation, code artifacts are stored according to the target layout: if the target layout is a subdirectory layout, the code artifacts are stored in a subdirectory named after the port identifier (e.g., the code artifacts for the web port are stored in the es / web / directory); if the target layout is a root directory layout, the code artifacts are stored directly in the SDK's root directory, and the files are organized according to the physical path naming rules. After storage, the code directory for that port is obtained, thus each port obtains code artifacts and a code directory that conform to its runtime capability constraints.

[0075] In this embodiment, by dynamically determining the code artifact format and layout based on runtime capability constraints, the code artifacts of different ports can adaptively match their respective runtime loading requirements, thereby improving the distribution compatibility of the SDK in multi-port scenarios.

[0076] Based on the embodiment corresponding to S220 above, in order to more clearly demonstrate the process of generating port type artifacts and type directories, this application also provides a possible implementation of generating port type artifacts and type directories in the front-end SDK adaptation artifact generation method. Figure 3 This is a flowchart illustrating the process of generating port type artifacts and type directories in a front-end SDK adaptation artifact generation method provided in an embodiment of this application. For example... Figure 3 As shown, S220 above generates the port type artifacts and type directory based on the runtime interface constraints of each port and the corresponding port's source code entry file, including: S410 determines the interface parameter information corresponding to the port from the port's source code entry file based on the port's runtime interface constraints.

[0077] Specifically, using the source code entry file of the corresponding port as the type source, the type declarations of the exposed interfaces in the file are read, and combined with the runtime interface constraints of the port, the key information such as the actual parameter type and return value type of each interface under the port is identified.

[0078] For example, for the web port, the "Create Uploader" interface parameter information extracted from the source code entry file is a browser file object; for the Alipay mini-program port, the same interface parameter information is a file path string. After extraction, a complete set of interface parameter information for each interface under that port is obtained. Optionally, the interface parameter information may include parameter name, parameter type, return value type, etc.

[0079] S420 generates type artifacts based on interface parameter information.

[0080] Based on the extracted interface parameter information, a type artifact (i.e., a TypeScript type definition file with the .d.ts extension) is generated for that port. Optionally, the application programming interface provided by the TypeScript compiler can be called or the corresponding type artifact can be generated using a build tool (such as Rollup).

[0081] Specifically, the interface parameter information is converted into TypeScript type syntax structures. For example, for the "Create Uploader" interface, if the interface parameter information is a browser file object, then the parameter is marked as a file object type when generating the corresponding type artifact; if the interface parameter information is a file path string, then the parameter is marked as a string type when generating the corresponding type artifact. Optional parameters and return value types of the interface are also converted accordingly according to TypeScript type syntax.

[0082] In this way, each port's type artifact only describes the interface constraints under that port, and they do not interfere with each other. When importing the Web port, the development tool suggests that the parameter is a browser file object type; when importing the Alipay mini-program port, the parameter is suggested to be a string type (file path). If an incorrect parameter type is passed under the wrong port, an error message will be received during the code writing stage, rather than being discovered only at runtime.

[0083] S430 generates a type directory based on the port identifier of the port.

[0084] The type directory corresponds one-to-one with the directory structure of the code artifacts.

[0085] Specifically, for any port, its code artifacts are stored in the code directory named after the port identifier, and its type artifacts are stored in the type directory named after the same port identifier. This one-to-one correspondence is not manually maintained, but automatically derived from the same port entry configuration. The code directory construction and type directory construction read the same port list, only the output directory prefixes are different (code artifacts are output to the code directory named after the port name, and type artifacts are output to the type directory named after the same port name), which ensures that there will be no path misalignment between the two.

[0086] For example, in the general toolkit named @rrzu / utils, separate type directories can be created for the Node.js client (common), browser client (web), mini-program client (mp), UniApp cross-platform framework client (uniapp), and third-party integration scenario client (integrations), namely types / common, types / web, types / mp, types / uniapp, and types / integrations, corresponding to the type artifacts of each port. Similarly, in the object storage upload toolkit named @rrzu / oss-sdk, separate type directories can be created for the browser client (web), Alipay mini-program client (mp-alipay), WeChat mini-program client (mp-weixin), and UniApp client (uniapp), namely types / web, types / mp-alipay, types / mp-weixin, and types / uniapp, corresponding to the type artifacts of each port.

[0087] The correspondence between code artifacts and type artifacts is as follows: For the web port, the code artifacts are in the es / web / directory, and the type artifacts are in the types / web / directory; for the Alipay mini-program (mp-alipay), the code artifacts are in the es / mp-alipay / directory, and the type artifacts are in the types / mp-alipay / directory; for the WeChat mini-program (mp-weixin), the code artifacts are in the es / mp-weixin / directory, and the type artifacts are in the types / mp-weixin / directory; for the Node.js (common) client, the code artifacts are in the es / common / directory, and the type artifacts are in the types / common / directory, and so on.

[0088] With this one-to-one directory structure, when referencing code artifacts of a certain port, the development tool can automatically match the type directory of the same port based on the path of the code directory, thereby providing accurate type hints and avoiding type mismatch problems caused by sharing the same type file.

[0089] In this embodiment, the same SDK has its own type definitions on different ports, and the directory structure of type artifacts and code artifacts is aligned, avoiding type path misalignment problems and effectively reducing type errors caused by port misuse.

[0090] In the above Figure 1 Based on the corresponding embodiments, in order to more clearly demonstrate the process of generating the packet description file of the port, this application also provides a possible implementation of generating the packet description file of the port in the front-end SDK adaptation artifact generation method. Figure 4 This is a flowchart illustrating the process of generating a port's packet description file in a front-end SDK adaptation artifact generation method provided in an embodiment of this application. Figure 4 As shown, in step S104 above, access configuration is performed based on the runtime capability constraints, code directory, and type directory of each port, generating a packet description file for the port, including: S510 obtains a structured representation of the port's capabilities based on the runtime capability constraints of each port.

[0091] Runtime constraints include at least information such as whether the port supports exported fields in the packet description file. Structured capability representation organizes this constraint information according to a predetermined format, forming structured data.

[0092] For example, for a Web engineering port that supports the `exports` field, its capabilities can be structurally expressed as "supports exports, supports subpath mapping access"; for an Alipay mini-program port that does not support the `exports` field and can only be accessed via a physical path, its capabilities can be structurally expressed as "does not support path mapping, requires physical path access". By transforming runtime capability constraints into a structured expression, the differences in access capabilities between different ports can be identified and handled.

[0093] S520 determines the code artifact path and type artifact path of the port based on the code directory and type directory.

[0094] The code directory and type directory store the port's code artifacts and type artifacts, respectively. The code artifact path refers to the relative path of the code directory within the distribution package (e.g., es / web / ), and the type artifact path refers to the relative path of the type directory within the distribution package (e.g., types / web / ).

[0095] Specifically, for each port, the code artifact path is determined based on the location of its code directory, and the type artifact path is determined based on the location of its type directory. For ports using a subdirectory layout (such as Web ports, WeChat Mini Program ports, and UniApp ports that support path mapping), both the code artifact path and the type artifact path are named using port identifiers (such as es / web / and types / web / ); for ports using a root directory layout (such as Alipay Mini Program ports that do not support path mapping), the code artifact path and the type artifact path directly point to the corresponding files or directories under the root directory.

[0096] S530 determines the access strategy based on the structured representation of capabilities, and encodes the access strategy with code artifact paths and type artifact paths in a hierarchical manner to generate a package description file.

[0097] Specifically, for ports whose capabilities are structured as "supporting exports, with ESM and CJS module formats" (such as Web ports, WeChat Mini Program ports, and UniApp ports), the access strategy is to access them through standard path mapping. For example, consumers can locate code artifacts and type artifacts by importing from the port identifier '@scope / sdk / '. In the package description file, the corresponding sub-path entries need to be configured in the exports field to map the port identifier to the specific code artifact path and type artifact path.

[0098] For ports whose capabilities are structured as "path mapping not supported, physical path access required, module format ESM" (such as Alipay mini-program ports), the access strategy is to access via physical file paths. For example, the consumer needs to directly import the SDK by file path. The dependency root directory layout is specified in the package description file.

[0099] In addition, considering that some extreme environments (such as very old packaging tools or custom build scripts) may not recognize the exports field, this solution also retains the traditional main and module fields as default fallback entry points to ensure that even in these extreme environments, the basic functions of the SDK can be obtained through the default entry points.

[0100] Through hierarchical information encoding, the package description file not only records the code path and type path of each port, but also the port's capability hierarchy information. The range of ports to be adapted determines the entries in the exports field, the code directory determines the code artifact path, and the type directory determines the type artifact path. These three elements work together to generate a mapping structure that requires no manual maintenance. This binds the code entry point and the type entry point to the same port identifier, structurally preventing path misalignment across ports.

[0101] When a new port needs to be added, its classification is determined based on the runtime capability constraints of the new port: if path mapping is supported, simply add exports and typesVersions records; if not, the artifact is placed in the root directory, and existing port configurations are not affected.

[0102] In this embodiment, by transforming the runtime capability constraints of the port into a structured expression of capabilities, and automatically determining the access policy based on this expression, and then hierarchically encoding the policy with the code path and type path to generate a package description file, the structured binding of access mapping and port capabilities is realized, which ensures the consistency of code entry point, type entry point and release directory from a mechanism perspective.

[0103] In the above Figure 4 Based on the corresponding embodiments, to more clearly illustrate the process of determining the access policy, this application also provides a possible implementation of determining the access policy in the front-end SDK adaptation artifact generation method. Optionally, in the above S530, determining the access policy according to the capability structured expression includes: S610, if the capability structured expression is the first capability structured expression, then the standard path mapping strategy is determined as the access strategy.

[0104] The first capability structured expression is used to describe ports with standard path mapping capabilities. Its characteristics include: support for the `exports` field in the package description file, the ability to identify sub-path mappings, and the ability of the runtime environment to locate the corresponding code and type artifacts based on this mapping. Examples include Web engineering environments, WeChat Mini Program ports, and UniApp ports. When a port's capability structured expression matches the first capability structured expression, the standard path mapping strategy is determined as the access strategy for that port. The standard path mapping strategy involves configuring sub-path mappings through the `exports` field in the package description file and configuring the corresponding type file lookup path through the `typesVersions` field, allowing consumers to access the port's code and type artifacts via sub-paths (e.g., `import xxx from "@rrzu / sdk / web"`).

[0105] S620, if the capability structured expression is the second capability structured expression, then the physical file path access strategy is determined as the access strategy.

[0106] The second capability structured expression is used to describe ports that lack standard path mapping capabilities. Its characteristics include: not supporting the `exports` field in the package description file; the runtime environment cannot recognize sub-path mappings; and modules can only be imported through actual physical file paths. For example, the Alipay mini-program port belongs to this category; its runtime does not recognize the `exports` field, and consumers must import it according to the actual storage path of the file within the package. When the port's capability structured expression matches the second capability structured expression, the physical file path access strategy is determined as the port's access strategy. The physical file path access strategy means that the port's code artifacts and type artifacts are directly stored in the root directory of the published package. Consumers access the port by directly specifying the file path, while a default entry point is provided through the `main` field in the package description file as a fallback.

[0107] In this embodiment, by structurally representing port capabilities and mapping them to access policy types, it is ensured that consumers in different runtime environments can correctly access the required modules, effectively improving the compatibility of the SDK in multi-port distribution scenarios.

[0108] In the above Figure 1 Based on the corresponding embodiments, to more clearly demonstrate the process of generating the browser-output product of the port, this application also provides a possible implementation of the method for generating the browser-output product of the port in the front-end SDK adaptation product generation method. Optionally, based on the above S101-S106, the method further includes: S710: If the runtime constraint of the port is a browser direct access scenario for the web port, then the browser direct output product of the port is generated based on the source code of the front-end SDK.

[0109] In the browser direct loading scenario, there is no bundling tool involved, and the runtime directly loads the independent script file from the browser. Therefore, the entire port's code needs to be packaged into a single executable file, i.e., the browser's direct output.

[0110] When the runtime constraints of a port indicate that the current port belongs to a browser direct-loading scenario, an additional browser direct-loading artifact needs to be generated in addition to the aforementioned standard module artifacts (such as ESM and CJS).

[0111] Specifically, the source code entry file corresponding to this port is used as the build entry point. The code is packaged using a module format suitable for direct browser execution (such as UMD) to generate a separate script file. After packaging, a global access interface is automatically attached to the end of the browser's output, allowing consumers to directly call SDK functions through global variables.

[0112] At the same time, version information is added to the browser's output artifacts. Specifically, the current version number is read from the front-end SDK's package description file and written as a comment in the artifact file header (version banner), or the version number is directly used as part of the file name, making it easier for consumers to identify the version and manage the cache.

[0113] In actual builds, the browser output formats may differ between different toolkits. For example, the general toolkit named `@rrzu / utils` can generate `index.global.min.js` (providing access to global variables) and `index.esm-browser.min.js` (providing access to the browser's ESM module); while the object storage upload toolkit named `@rrzu / oss-sdk` can generate `oss.sdk.umd.v`. <version>The .js file (in UMD format with version number) allows for both modular consumption and browser script direct import consumption within the same build process.

[0114] Accordingly, in step S106 above, based on the code artifacts, type artifacts, and release structure of multiple ports, the adaptation artifacts for the front-end SDK to be released are generated, including: S720 generates the front-end SDK's release-ready adaptation product based on the code artifacts, type artifacts, browser direct output artifacts, and release structure of multiple ports.

[0115] After generating the browser-output artifacts, they are combined with the standard code artifacts, type artifacts, and release structures of other ports.

[0116] Specifically, the browser-direct output artifacts are stored in the root directory of the SDK, ensuring that their paths in the SDK are consistent with the access configurations in the package description file (such as the browser entry configuration in the exports field). Then, the code artifacts, type artifacts, browser-direct output artifacts, and the release structure for each port are unified into a unified release-ready adaptation artifact for the front-end SDK. This artifact includes standard artifacts for modular consumption environments and independent script artifacts for browser-direct import scenarios. Both artifacts are completed in the same build process, sharing the same version number, thus avoiding version drift issues.

[0117] In this embodiment, by identifying browser-direct-loading scenarios and generating additional browser-direct-output artifacts in the same build process, standard module artifacts and browser-direct-output artifacts are generated and released uniformly under the same version control, avoiding version inconsistency issues caused by maintaining independent scripts separately, and further improving the consistency and integrity of the SDK in multi-scenario distribution.

[0118] The following describes the front-end SDK adaptation product generation apparatus and computer equipment provided in this application for execution. The specific implementation process and technical effects are described above and will not be repeated below.

[0119] Figure 5 A schematic diagram of a front-end SDK adaptation product generation device provided in this application embodiment is shown below. Figure 5 As shown, the front-end SDK adaptation product generation device includes: The acquisition module 1000 is used to obtain the runtime constraints of multiple ports within the port range to be adapted, based on the port range to be adapted in the front-end SDK.

[0120] The generation module 2000 is used to generate the source code entry file of the front-end SDK for each port based on the runtime constraints of each port and the source code of the front-end SDK; to generate the code artifacts and code directory of each port, and the type artifacts and type directory of each port based on the runtime capability constraints of each port and the source code entry file of each port; to configure access based on the runtime capability constraints, code directory and type directory of each port, and generate the package description file of the port; the package description file includes at least: an access policy, which is used to access the code artifacts and type artifacts; to generate the release structure of each port based on the code directory, type directory and package description file of each port; and to generate the adaptation artifacts to be released for the front-end SDK based on the code artifacts, type artifacts and release structure of multiple ports.

[0121] Optionally, the generation module 2000 is specifically used to compile the source code entry file of each port according to the runtime capability constraints of each port, to obtain the code artifacts and code directory of the port; and to generate the type artifacts and type directory of the port according to the runtime interface constraints of each port and the source code entry file of the corresponding port.

[0122] Optionally, the generation module 2000 is specifically used to determine the code artifact format and target layout method corresponding to each port based on the runtime capability constraints of each port; and to compile the source code entry file of the port using the code artifact format and target layout method to obtain the port's code artifact and code directory.

[0123] Optionally, the generation module 2000 is specifically used to determine the interface parameter information corresponding to the port from the source code entry file of the port according to the runtime interface constraints of the port; generate type artifacts according to the interface parameter information; and generate a type directory according to the port identifier of the port.

[0124] Optionally, the acquisition module 1000 is also used to acquire a structured representation of the port's capabilities based on the runtime capability constraints of each port.

[0125] Optionally, the generation module 2000 is specifically used to determine the code artifact path and type artifact path of the port based on the code directory and type directory; determine the access strategy based on the capability structured expression; and perform hierarchical information encoding of the access strategy with the code artifact path and type artifact path to generate a package description file.

[0126] Optionally, the generation module 2000 is specifically used to determine the standard path mapping strategy as the access strategy if the capability structured expression is a first capability structured expression; and to determine the physical file path access strategy as the access strategy if the capability structured expression is a second capability structured expression.

[0127] Optionally, the generation module 2000 is specifically used to generate browser-direct output products for the port based on the source code of the front-end SDK if the runtime constraint of the port is a browser direct link scenario for the web port; and to generate the front-end SDK's release-ready adaptation product based on the code products, type products, browser direct output products and release structure of multiple ports.

[0128] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more digital signal processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0129] Figure 6 This is a schematic diagram of a computer device provided in an embodiment of this application. The device may be a computing device or a server with computing processing capabilities.

[0130] The computer device 10 includes a processor 11, a storage medium 12, and a bus 13. The storage medium 12 stores program instructions executable by the processor 11. When the computer device 10 is executed, the processor 11 communicates with the storage medium 12 via the bus 13, and the processor 11 executes the program instructions to perform the above-described method embodiment. The specific implementation and technical effects are similar and will not be described in detail here.

[0131] Optionally, this application also provides a program product, such as a computer-readable storage medium, including a program that, when executed by a processor, performs the above-described method embodiments.

[0132] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units 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 units may be electrical, mechanical, or other forms.

[0133] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0134] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0135] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0136] 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 technical scope 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.< / version> < / package>

Claims

1. A method for generating front-end SDK adaptation artifacts, characterized in that, The method includes: Based on the range of ports to be adapted in the front-end SDK, obtain the runtime constraints of multiple ports within the range of ports to be adapted; Based on the runtime constraints of each port and the source code of the front-end SDK, generate the source code entry file of the front-end SDK for each port; Based on the runtime capability constraints of each port and the source code entry file of the port, generate the code artifacts and code directory of the port, as well as the type artifacts and type directory of the port; Based on the runtime capability constraints of each port, the code directory, and the type directory, access configuration is performed to generate a packet description file for each port; the packet description file includes at least an access policy, which is used to access the code artifacts and the type artifacts; Based on the code directory, type directory, and package description file of each port, generate the distribution structure of the port; Based on the code artifacts, type artifacts, and release structure of the multiple ports, generate the adaptation artifacts to be released for the front-end SDK.

2. The method according to claim 1, characterized in that, The runtime constraints include runtime capability constraints and runtime interface constraints; the step of generating the code artifacts and code directory of each port, and the type artifacts and type directory of each port, based on the runtime capability constraints of each port and the source code entry file of each port, includes: Based on the runtime capability constraints of each port, the source code entry file of the port is compiled to obtain the code artifacts and code directory of the port; Based on the runtime interface constraints of each port and the source code entry file of the corresponding port, the type artifacts and type directories of the port are generated.

3. The method according to claim 2, characterized in that, The step of compiling the source code entry file of each port according to the runtime capability constraints of each port to obtain the code artifacts and code directory of the port includes: Based on the runtime capability constraints of each port, determine the code artifact format and target layout method corresponding to the port; Using the aforementioned code artifact format and target layout method, the source code entry file of the port is compiled to obtain the port's code artifact and code directory.

4. The method according to claim 2, characterized in that, The step of generating the type artifacts and type directories for each port based on the runtime interface constraints of each port and the corresponding port's source code entry file includes: Based on the runtime interface constraints of the port, determine the interface parameter information corresponding to the port from the source code entry file of the port; Generate the product of the type based on the interface parameter information; Generate the type directory based on the port identifier of the port.

5. The method according to claim 1, characterized in that, The step of configuring access based on the runtime capability constraints of each port, the code directory, and the type directory, and generating a packet description file for each port, includes: Based on the runtime capability constraints of each port, obtain a structured representation of the port's capabilities; Based on the code directory and the type directory, determine the code artifact path and type artifact path of the port; Based on the structured representation of the capabilities, the access strategy is determined, and the access strategy, along with the code artifact path and the type artifact path, are hierarchically encoded to generate the package description file.

6. The method according to claim 5, characterized in that, Determining the access strategy based on the structured representation of the capabilities includes: If the capability structured expression is a first capability structured expression, then the standard path mapping strategy is determined as the access strategy; If the capability structured expression is a second capability structured expression, then the physical file path access strategy is determined as the access strategy.

7. The method according to claim 1, characterized in that, The method further includes: If the runtime constraint of the port is a browser direct-access scenario for a web page port, then the browser direct-output product of the port is generated based on the source code of the front-end SDK. The step of generating the release-ready adaptation product of the front-end SDK based on the code artifacts, type artifacts, and release structure of multiple ports includes: Based on the code artifacts, type artifacts, browser output artifacts, and release structure of the multiple ports, the release adaptation artifacts of the front-end SDK are generated.

8. A front-end SDK adaptation product generation device, characterized in that, The device includes: The acquisition module is used to acquire the runtime constraints of multiple ports within the port range to be adapted, based on the port range to be adapted in the front-end SDK. A generation module is used to generate the source code entry file of the front-end SDK for each port based on the runtime constraints of each port and the source code of the front-end SDK; generate the code artifacts and code directory of the port, and the type artifacts and type directory of the port based on the runtime capability constraints of each port and the source code entry file of the port; perform access configuration based on the runtime capability constraints of each port, the code directory, and the type directory, and generate the package description file of the port; the package description file includes at least an access policy, which is used to access the code artifacts and the type artifacts; generate the release structure of the port based on the code directory, type directory, and package description file of each port; and generate the adaptation artifacts to be released for the front-end SDK based on the code artifacts, type artifacts, and release structure of multiple ports.

9. A computer device, characterized in that, include: The system includes a processor, a memory, and a bus. The memory stores program instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus, and the processor executes the program instructions to perform the steps of the front-end SDK adaptation product generation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which is executed by a processor to perform the front-end SDK adaptation product generation method as described in any one of claims 1-7.

Images