A method and device for automatically publishing a web component library

Abstract

The application relates to the technical field of automatic deployment and release of component libraries, and provides a method and equipment for automatically releasing web end component libraries, which comprises the following steps: parsing a command line parameter input by a user to obtain a version update type and a component identification to be released; verifying a working state of a current code warehouse to provide a clean code benchmark for subsequent version updating; uniformly updating version numbers of each component part in the component library according to the version update type to generate corresponding version change records; performing a release operation on a specified component according to the version change records and the component identification to be released to create traceable version marks and restore to a state before release when an exception occurs. The application can improve release efficiency, ensure version consistency, standardize a release process, provide release flexibility, enhance error processing capability, optimize document quality and strengthen version tracing.

Description

Technical Field

[0001] This invention relates to the field of automated deployment and publishing technology of component libraries, and in particular to a method and device for automatically publishing web-based component libraries. Background Technology

[0002] In modern front-end development, managing and releasing component libraries is a common but tedious task. With the increasing popularity of micro-frontend architecture and modular development, enterprise-level front-end projects typically maintain multiple independent component packages, which need to be released collaboratively to ensure version consistency.

[0003] Existing component library publishing technologies have the following main defects and shortcomings:

[0004] 1. Cumbersome manual operation: The traditional component release process usually requires developers to manually perform multiple steps, including updating the version number, generating change logs, creating Git tags, and executing release commands, which is prone to human error.

[0005] 2. Version consistency is difficult to guarantee: In projects with multiple packages, the version numbers of each sub-package need to be consistent, but manual maintenance can easily lead to version mismatch and dependency conflicts.

[0006] 3. Non-standardized release process: The lack of a unified release process standard means that different developers may use different release methods, resulting in messy release records and difficulty in tracking.

[0007] 4. Inadequate error handling mechanism: When errors occur during the release process, there is a lack of an effective rollback mechanism, which may result in some components being released successfully while others fail, causing version fragmentation.

[0008] 5. Inability to selectively release: Existing technologies typically only allow the release of all components or a single component, lacking the flexible capability for selective release, leading to unnecessary duplicate releases.

[0009] Chinese patent CN115357272A discloses a method for publishing front-end public components. This method proposes the idea of ​​independent storage and selective publishing. However, its technical solution has obvious shortcomings in terms of automated version management, standardized change records, complete error handling, and standardized process. It fails to form a complete automated closed loop from version management to component publishing, and it is difficult to meet the needs of modern front-end engineering for efficient, reliable, and standardized component publishing.

[0010] Therefore, how to provide a solution that can automate the entire process of component library release, ensure version consistency, provide flexible release options, and have a sound error handling mechanism to improve the efficiency and quality of component library management and release has become an urgent technical problem to be solved. Summary of the Invention

[0011] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a method and device for automatically publishing web component libraries.

[0012] According to a first aspect of the present invention, a method for automatically publishing a web-based component library is provided, the method comprising:

[0013] Step S1: Parse the command-line parameters entered by the user to obtain the version update type and the identifier of the component to be released;

[0014] Step S2: Verify the current working status of the code repository to provide a clean code baseline for subsequent version updates;

[0015] Step S3: Based on the version update type, uniformly update the version number of each component in the component library and generate the corresponding version change record;

[0016] Step S4: Based on the version change record and the identifier of the component to be released, perform the release operation on the specified component, create a traceable version tag, and restore the state before release in case of an exception.

[0017] Optionally, in the method for automatically publishing a web-based component library of the present invention, step S1, parsing the command-line parameters input by the user, includes: receiving update type parameters and a list of components to be published input by the user through a command-line interface, parsing the received parameters through a parameter parsing library, and generating a structured version update type identifier and a set of component names to be published.

[0018] Optionally, in the method for automatically publishing a web-based component library of the present invention, in step S1, the update type parameter includes three values: major version number update, minor version number update, or revision number update, which respectively correspond to version change requirements in the semantic version control specification for incompatible API changes, backward compatible feature additions, and backward compatibility issue corrections. The component list parameter to be published supports specifying a single component name, a combination of multiple component names, or using the default method to indicate the publication of all components.

[0019] Optionally, in the method for automatically publishing web-based component libraries of the present invention, step S2 verifies the current working status of the code repository in the following manner:

[0020] By calling the status query command provided by the version control system, the file change status information of the current working area and the staging area can be obtained;

[0021] Parse the file's change status information to determine if there are any uncommitted code modifications.

[0022] If there are no uncommitted changes, continue with the subsequent release process;

[0023] If there are uncommitted changes, output an error message to the user containing information about the uncommitted files, record the status exception identifier, and trigger the exception handling logic to terminate the current release process.

[0024] Optionally, in the method for automatically publishing a web-based component library of the present invention, step S3 involves uniformly updating the version numbers of each component in the component library in the following manner:

[0025] Read the current version number from the package description file in the root directory, increment the corresponding bits of the current version number according to the version update type, reset the low bits of the version number to zero, and generate a new version number that conforms to the semantic versioning specification.

[0026] The system iterates through all sub-package directories in the project, reads the package description files of each sub-package, and writes the new version number into the version number field of the root package and all sub-package package description files respectively, thereby achieving consistent version number updates across the multi-package architecture of the entire component library.

[0027] Optionally, in the method for automatically publishing a web-based component library of the present invention, step S3 involves generating a corresponding version change record in the following manner:

[0028] Invoke the pre-configured change log generation tool, which extracts commit information that conforms to the convention commit specification from the commit history of the version control system;

[0029] Submitted information is categorized and formatted according to classification dimensions to generate or update standardized change log files. Classification dimensions include new features, bug fixes, and incompatible changes.

[0030] Based on the system's preset document storage path configuration, the generated change log files will be copied and migrated to the specified document directory or component directory.

[0031] Optionally, in the method for automatically publishing a web-based component library of the present invention, step S4, based on the version change record and the identifier of the component to be published, includes performing a publishing operation on the specified component, including:

[0032] The set of target components to be published is determined based on the identifier of the component to be published. The set of target components is traversed. For each component to be published, the package server is logged in and authenticated through the identity authentication mechanism of the package manager. After successful login, a trusted connection session with the package server is established.

[0033] Switch to the directory corresponding to the component, read the latest version number in the component package description file, and call the package publishing command to push the component package to the preset package server;

[0034] Record the release status of each component and output a summary release log after all components have been released.

[0035] Optionally, in the method for automatically publishing a web-based component library of the present invention, step S4 involves creating a traceable version tag in the following manner:

[0036] Based on the new version number, generate a tag name that the version control system can recognize according to the preset tag naming rules;

[0037] The file addition operation adds the updated package description file and change log file to the version management; the commit operation creates a commit record containing version update information, with the new version number and change summary automatically embedded in the commit information; the tag creation operation associates and binds the generated tag with the current commit record; and the push operation synchronously pushes the new commit and associated tag to the remote code repository.

[0038] Optionally, in the method for automatically publishing a web-based component library of the present invention, step S4 is implemented to restore the state to before publication in the event of an error as follows:

[0039] The system maintains a global exception monitoring flag to track the execution status of each step in the entire release process; when an exception is thrown during the execution of any release step, the exception is captured and detailed error information is recorded.

[0040] Determine whether the current exception is an exception that occurred during the release process. If it is, call the state reset command of the version control system to undo all file modifications and commits made in this release process, and restore the working area, staging area and repository to the state before this release started.

[0041] The entire release process is terminated with an error status code, and a message is displayed to the user indicating the reason for the error and the automatic recovery completion status.

[0042] According to a second aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect of the present invention.

[0043] The method and apparatus for automatically publishing web-based component libraries of the present invention have the following beneficial technical effects:

[0044] I. Significantly improve the automation level of component library release, reducing manual intervention and operational errors.

[0045] It significantly reduces the manual workload of developers, improves release efficiency, and fundamentally eliminates human errors such as missing version numbers, missing change log content, and incorrect Git tag creation caused by human negligence, thereby significantly improving the accuracy and reliability of release operations.

[0046] Second, ensure version consistency under a multi-package architecture to fundamentally avoid dependency conflicts.

[0047] This fundamentally eliminates technical issues such as runtime dependency conflicts, type definition mismatches, and style overriding anomalies caused by inconsistent component versions, thereby improving system stability and maintainability.

[0048] Third, standardize and unify the release process to improve the traceability of version management and the efficiency of team collaboration.

[0049] Change logs are automatically generated based on convention-based commit specifications, ensuring complete content and a consistent format for easy reading and auditing. Git tags are automatically associated with version numbers, forming a clear version evolution trajectory that facilitates subsequent version backtracking and historical queries. Unified release records facilitate version review, issue investigation, and accountability within the team, significantly improving development efficiency and code maintainability in multi-person collaboration scenarios.

[0050] IV. Provides flexible selective publishing capabilities to meet diverse business needs.

[0051] It not only saves resources for building and releasing, and shortens the release cycle, but also provides technical support for complex release strategies.

[0052] 5. Establish a sound exception handling and automatic rollback mechanism to ensure system state consistency.

[0053] It effectively avoids the fragmentation problem caused by "partial success and partial failure" common in traditional release methods, ensuring that the code repository is always in a consistent and predictable state regardless of whether the release is successful or not, and providing reliable security for the development team.

[0054] 6. Implement automated generation and migration of change logs to improve document quality and readability.

[0055] It eliminates the tedious work of developers manually writing change logs, ensuring the completeness, accuracy, and timeliness of change logs, improving the overall quality and readability of project documentation, and making it easier for team members, project managers, and component users to quickly understand the details of changes in each version.

[0056] 7. Enable automatic creation and push of version tags to enhance version tracking capabilities.

[0057] When developers need to locate the code state of a specific historical version, they can quickly switch to the corresponding code snapshot directly by tag name, without having to manually search through massive commit histories. This makes version tracking simple and reliable, further improving the manageability and maintainability of the codebase. Attached Figure Description

[0058] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 This is a flowchart illustrating a method for automatically publishing a web-based component library according to an exemplary embodiment 1 of the present invention.

[0060] Figure 2 A schematic diagram of the system architecture for implementing the method of automatically publishing a web-based component library according to Exemplary Example 2 of the present invention;

[0061] Figure 3 This is a schematic diagram illustrating the execution flow of a method for automatically publishing a web-based component library according to an exemplary embodiment 2 of the present invention;

[0062] Figure 4 This is a schematic diagram of the structure of the device provided by the present invention. Detailed Implementation

[0063] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0064] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0065] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0066] Example 1

[0067] Exemplary embodiment 1 of the present invention provides a method for automatically publishing a web-based component library. Figure 1 This is a flowchart illustrating a method for automatically publishing a web-based component library according to an exemplary embodiment 1 of the present invention, as shown below. Figure 1As shown in this embodiment, the method for automatically publishing the web-based component library is as follows:

[0068] Step S1: Parse the command-line parameters entered by the user to obtain the version update type and the identifier of the component to be released.

[0069] In this embodiment, the update type parameter and the list of components to be released are received by the user through the command line interface. The received parameters are parsed by the parameter parsing library to generate a structured version update type identifier and a set of component names to be released. The parsing result is used as the input parameter for subsequent steps.

[0070] As an optional example, the update type parameter includes three values: major version number update, minor version number update, or revision number update. These correspond to version change requirements in different scenarios in the semantic versioning specification, such as changes to incompatible APIs, addition of backward compatible features, and fixes of backward compatible issues. The list of components to be released parameter supports specifying a single component name, a combination of multiple component names, or using the default method to indicate the release of all components.

[0071] In this embodiment, the Semantic Versioning specification is a software version naming convention that uses the XYZ (major version number.minor version number.revision number) format, where:

[0072] X (Major): Major version number, incremented when incompatible API changes are made;

[0073] Y (Minor): Minor version number, incremented when backward-compatible features are added;

[0074] Z (Patch): Revision number, incremented when fixing backward compatibility issues;

[0075] Step S2: Verify the current working status of the code repository to provide a clean code baseline for subsequent version updates.

[0076] In this embodiment, the file change status information of the current working area and the staging area is obtained by calling the status query command provided by the version control system; the file change status information is parsed to determine whether there are any uncommitted code modifications; if there are no uncommitted changes, the subsequent release process continues; if there are uncommitted changes, an error message containing specific uncommitted file information is output to the user, and the status exception identifier is recorded. The exception handling logic is triggered to terminate the release process, ensuring that the version release operation is always based on a complete code commit status.

[0077] Step S3: Based on the version update type, uniformly update the version number of each component in the component library and generate the corresponding version change record.

[0078] In this embodiment, the version numbers of each component in the component library are updated uniformly in the following manner:

[0079] Read the current version number from the package description file in the root directory, and increment the corresponding bits of the current version number (such as the revision number, minor version number, or major version number) according to the version update type, set the low-order version number to zero, and generate a new version number that conforms to the semantic versioning specification.

[0080] The system iterates through all sub-package directories in the project, reads the package description files of each sub-package, and writes the new version number into the version number field of the root package and all sub-package package description files respectively, thereby achieving consistent version number updates across the multi-package architecture of the entire component library.

[0081] In this embodiment, the corresponding version change record is generated in the following manner:

[0082] Invoke the pre-configured change log generation tool, which extracts commit information that conforms to the convention commit specification from the commit history of the version control system;

[0083] Submitted information is categorized and formatted according to classification dimensions to generate or update standardized change log files. Classification dimensions include new features, bug fixes, and incompatible changes.

[0084] Based on the system's preset document storage path configuration, the generated change log files are copied and migrated to the specified document directory or component directory, thereby achieving automated archiving, persistent storage, and multi-directory synchronization management of version change information.

[0085] Step S4: Based on the version change record and the identifier of the component to be released, perform the release operation on the specified component, create a traceable version tag, and restore the state before release in case of an exception.

[0086] In this embodiment, the set of target components to be published is determined based on the identifier of the component to be published. The set of target components is traversed. For each component to be published, the package manager's authentication mechanism is used to log in to the package server. This authentication process supports multiple authentication methods such as interactive username and password filling, automatic injection of authentication tokens, or reading of configuration files. After successful login, a trusted connection session with the package server is established. Then, the directory corresponding to the component is switched, the latest version number in the component package description file is read, and the package publishing command is called to push the component package to the preset package server. The publishing result status of each component is recorded, including success, failure, and failure reason. After all components are published, a summary publishing log information is output, realizing the ability to selectively publish single components, multiple components, or all components.

[0087] After the release operation is performed, this embodiment creates a traceable version tag in the following manner:

[0088] Based on the new version number, a tag name recognizable by the version control system is generated according to a preset tag naming rule. In practical applications, this naming rule usually adopts the format of version number prefix plus version number. The file addition operation is performed to include the updated package description file and change log file into version management. The commit operation is performed to create a commit record containing version update information, and the new version number and change summary are automatically embedded in the commit information. The tag creation operation is performed to associate and bind the generated tag with the current commit record. The push operation is performed to synchronously push the new commit and associated tag to the remote code repository, realizing version traceability and permanent tag management in a distributed collaborative environment.

[0089] It should be noted that in this embodiment, the restoration to the state before release is achieved in the event of an anomaly in the following manner:

[0090] The system maintains a global exception monitoring flag to track the execution status of each step in the entire release process; when an exception is thrown during the execution of any release step, the exception is captured and detailed error information is recorded, including the exception type, location of occurrence, and stack trace.

[0091] The system determines whether the current anomaly occurred during the release process. If so, it invokes the version control system's state reset command to undo all file modifications and commits made during the current release process, restoring the working directory, staging area, and repository to their state before the release began. It should be noted that the state reset command in this embodiment can forcibly undo all file modifications, staging area changes, and commit records made during the current release process, restoring the complete state of the working directory, staging area, and repository to the precise point in time before the release began.

[0092] The entire release process is terminated with an error status code, and a message is output to the user including the reason for the error and the status of automatic recovery, ensuring strong consistency of system status and recoverability of operations.

[0093] Example 2

[0094] Exemplary embodiment 2 of the present invention provides a method for automatically publishing a web-based component library.

[0095] Figure 2 This is a schematic diagram of the system architecture for implementing the method of automatically publishing a web-based component library according to Exemplary Example 2 of the present invention. Figure 2 As shown, the system architecture includes: a parameter parsing module, a Git status checking module, a version management module, a change log generation module, a component deployment module, a version tag management module, and an error handling and rollback module. Figure 3 This is a schematic diagram illustrating the execution flow of a method for automatically publishing a web-based component library according to an exemplary embodiment 2 of the present invention, as follows: Figure 2 and Figure 3 As shown, in the method of this embodiment, each module operates in the following manner:

[0096] The parameter parsing module is used to parse command-line arguments, supporting the specification of update type (major / minor / patch) and the list of components to be released. This module is based on the yargs library and can flexibly handle various combinations of user-input parameters.

[0097] The parameter parsing module takes the following input parameters: command-line startup parameters, including the required parameter --update (which can be major, minor, or patch) and the optional parameter --publish (which specifies the name of the component to be published; if not specified, it means that all components will be published).

[0098] The parameter parsing module outputs the following parameters: the parsed update type identifier updateType and the target component name list componentNames, which are then used by the subsequent version management module and component release module.

[0099] The Git status check module automatically checks the Git working directory status before deployment, ensuring there are no uncommitted changes and preventing the release of incomplete code. This module obtains the working directory status by executing the `git status --porcelain` command and interrupts the deployment process if uncommitted changes are detected. In this embodiment, Git is a distributed version control system used to track file changes and facilitate collaborative development.

[0100] The input parameters for the Git status check module are: the working directory and staging area status of the Git repository where the current execution directory is located (implicitly obtained by executing the command git status --porcelain).

[0101] The output parameters of the Git status check module are as follows: when there are no uncommitted changes in the working directory, it returns to a normal state and allows the subsequent process to proceed; when an uncommitted change is detected, it outputs an error message and throws an exception, interrupting the release process, and internally marks the Git status exception, which is used by the subsequent error handling module to decide whether to perform a rollback.

[0102] The version management module is used to automatically update the version numbers of the root package and all sub-packages according to the specified update type to ensure version consistency. This module implements the automatic increment logic of semantic version control and supports three update types: major, minor, and patch.

[0103] The input parameters for the version management module are: the update type (major / minor / patch) output by the parameter parsing module, and the version number information in the current root package's package.json.

[0104] The output parameter of the version management module is: the new version number newVersion calculated according to the semantic version control rules, and the version number is written back to the root package and the package.json of the sub-packages that meet the conditions, so as to form a consistent version number state throughout the entire component library.

[0105] The change log generation module is used to automatically generate standardized change logs and supports migrating change logs to a specified document directory. This module uses the conventional-changelog tool to generate standardized change logs based on Git commit records.

[0106] The input parameters for the changelog generation module are: the current Git commit history and a pre-configured changelog generation script in the system (e.g., calling the conventional-changelog tool via `pnpm run changelog`), and the target document directory path (such as a specified document package directory). In this embodiment, pnpm is a fast JavaScript package manager that provides a more efficient dependency management method than npm and yarn. A changelog is a document that records software version changes, typically including new features, bug fixes, and incompatible changes.

[0107] The output parameters of the change log generation module are: automatically generate or update a standardized CHANGELOG.md file in the root directory, and copy (migrate) the change log file to the specified document or component directory, provided that the file and target directory exist, to form a documented change record for the corresponding version.

[0108] The component publishing module is used to automatically execute the command `npm login` to log in to the npm server and fill in the username and password, and automatically execute the command `npm publish` to publish the component library to the npm server. In this embodiment, npm (Node PackageManager) is the package manager for Node.js, used to manage and distribute JavaScript code packages.

[0109] The input parameters for the component publishing module are: the target component list componentNames (if empty, it means all components) output by the parameter parsing module, the package description file package.json in the directory corresponding to each component and its version number information, and the account credentials (username, password or equivalent authentication configuration) used to connect to the npm server.

[0110] The output parameters of the component publishing module are as follows: After completing npm login authentication for each component to be published, execute the npmpublish command to publish the component package to the preset npm server, and output the publishing result status (log information of successful or failed publishing) for each component, forming the external availability status of the published components and their versions.

[0111] The version tag management module is used to automatically create Git tags and push them to remote repositories for easy version rollback and management. This module creates and pushes tags by executing the `git tag` and `git push` commands.

[0112] The input parameters for the version tag management module are: the new version number (newVersion) output by the version management module, the commit history of the current Git repository, and the remote repository address information.

[0113] The output parameters of the version tag management module are: create a corresponding version commit record and a Git tag with a version number prefix (such as vX.YZ) based on the new version number, and push the commit and tag to the remote repository, thereby forming traceable tag information of the corresponding version in the remote repository.

[0114] The error handling and rollback module automatically performs a rollback operation when errors occur during the release process, ensuring system consistency. This module undoes changes made by executing the `git reset --hard` command, guaranteeing that the system returns to its pre-release state.

[0115] The input parameters for the error handling and rollback module are: the exception information thrown during the execution of each functional module, and the Git status flag set by the Git status check module (to distinguish whether the interruption is caused by uncommitted changes in the working directory or an exception occurs in the middle of the release process).

[0116] The error handling and rollback module outputs the following parameters: while recording and outputting detailed error information, when an exception that occurred during the release process is detected, the git reset --hard command is automatically executed to undo the version file modifications and commits that have been performed but not yet successfully completed in the current release process, so that the code repository is restored to a consistent state before release, and the release process is terminated with an error status code.

[0117] The method for automatically publishing web-based component libraries according to embodiments of the present invention has the following beneficial technical effects:

[0118] I. Significantly improve the automation level of component library release, reducing manual intervention and operational errors.

[0119] The system automates multiple steps that developers previously had to perform manually during component release. Developers only need to input simple command-line parameters (specifying the update type and the component to be released), and the system can automatically complete all subsequent operations. This significantly reduces the manual workload for developers, improves release efficiency, and fundamentally eliminates human errors such as missing version numbers, missing change log content, and incorrect Git tag creation caused by human negligence, thereby significantly improving the accuracy and reliability of release operations.

[0120] Second, ensure version consistency under a multi-package architecture to fundamentally avoid dependency conflicts.

[0121] For application scenarios using Monorepo to manage multiple component packages, a unified version update module automatically calculates the new version number based on the specified update type and atomically writes this version number to the package description files of the root package and all sub-packages. This ensures that regardless of the number of independent component packages in the component library, and regardless of whether the release includes only some or all components, the version numbers of all component packages remain strictly consistent. This guarantee of version consistency enables upper-layer applications or micro-frontend sub-applications that depend on these components to reliably manage version dependencies, fundamentally eliminating technical issues such as runtime dependency conflicts, type definition mismatches, and style overriding anomalies caused by inconsistent component versions, thus improving system stability and maintainability.

[0122] Third, standardize and unify the release process to improve the traceability of version management and the efficiency of team collaboration.

[0123] By designing a standardized release process, a series of operations, including version updates, change logs, code commits, tag creation, and component releases, are incorporated into a unified framework. All developers, regardless of their personal habits, must follow the same release process, use the same commit message format, and generate change logs in the same standardized manner. Change logs are automatically generated based on agreed-upon commit specifications, ensuring complete content and a consistent format for easy reading and auditing. Git tags are automatically associated with version numbers, forming a clear version evolution trajectory, facilitating subsequent version rollback and historical queries. Unified release records facilitate version reviews, issue investigation, and accountability within the team, significantly improving development efficiency and code maintainability in multi-person collaborative scenarios.

[0124] IV. Provides flexible selective publishing capabilities to meet diverse business needs.

[0125] The parameter parsing module allows users to specify a list of components to be released, enabling flexible on-demand release capabilities. Developers can choose to release a single component, a specific group of components, or all components using the default method, based on actual needs. When only a defect in a component needs to be fixed, it can be released separately, avoiding unnecessary releases and version updates of other components. When developing a group of interdependent new functional components, collaborative release of these components can be chosen to ensure version consistency. When some components are under development or do not meet the release conditions, they can be excluded from the release scope, enabling canary releases or phased releases. This not only saves build and release resources and shortens the release cycle but also provides technical support for complex release strategies.

[0126] 5. Establish a sound exception handling and automatic rollback mechanism to ensure system state consistency.

[0127] Integrating global anomaly monitoring and automatic rollback capabilities into the release process significantly enhances the system's robustness and reliability. When an anomaly occurs at any stage of the release process, the system can automatically capture the anomaly, record error information, and determine whether a rollback is necessary. For anomalies requiring rollback, the system automatically invokes the version control system's state reset command, undoing all file modifications, staging area changes, and commit records made during the current release process. This precisely restores the working directory, staging area, and repository to their state before the release began. This effectively avoids the version fragmentation problem common in traditional release methods caused by "partial success, partial failure," ensuring that the code repository remains in a consistent and predictable state regardless of release success or failure, providing reliable security for the development team.

[0128] 6. Implement automated generation and migration of change logs to improve document quality and readability.

[0129] By integrating a changelog generation tool, and based on conventional commit information from Git commit history, the system automatically generates standardized changelogs with clear content and categorization. The changelogs are organized according to dimensions such as new features, bug fixes, and incompatibility changes, making version changes readily apparent. Simultaneously, the system supports automatically copying and migrating the generated changelog files to specified document or component directories, achieving automated archiving and multi-point synchronization of change information. This eliminates the tedious work of developers manually writing changelogs, ensuring the completeness, accuracy, and timeliness of the changelogs, improving the overall quality and readability of project documentation, and enabling team members, project managers, and component users to quickly understand the details of changes in each version.

[0130] 7. Enable automatic creation and push of version tags to enhance version tracking capabilities.

[0131] After a version update and component release, a corresponding Git tag is automatically created based on the new version number, and the tag is pushed to the remote code repository. These Git tags, strictly corresponding to version numbers, form milestone nodes in the code evolution process, providing precise reference points for subsequent version rollback, issue investigation, and code review. When it is necessary to locate the code status of a certain historical version, developers can quickly switch to the corresponding code snapshot directly by tag name, without having to manually search through massive commit histories. This makes version tracking simple and reliable, further improving the manageability and maintainability of the code repository.

[0132] This invention's method is implemented based on a JavaScript runtime environment and integrates a high-performance build system to optimize the parallel execution and incremental caching of build tasks for multi-package component libraries. Simultaneously, it employs efficient package management tools for dependency installation and module linking management, reducing disk space usage and installation time through content-addressed storage and hard linking mechanisms, thereby improving the overall operational efficiency of the build and execution phases during component library deployment. It is suitable for front-end projects using a micro-frontend architecture or modular development model, enabling unified version management and collaborative deployment of multiple independent component packages within a project. By ensuring strict consistency in the versions of components depended upon by each micro-frontend sub-application or functional module during deployment, it effectively avoids runtime dependency conflicts and module compatibility issues caused by version inconsistencies, significantly improving the maintainability, deployment reliability, and team collaboration efficiency of large-scale front-end projects.

[0133] like Figure 4 As shown, the present invention also provides a device including a processor 310, a communication interface 320, a memory 330 for storing processor-executable computer programs, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 implements the aforementioned method for automatically publishing a web-based component library by running the executable computer program.

[0134] The computer program in memory 330, when implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0135] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected based on actual needs to achieve the purpose of this embodiment. Those skilled in the art can understand and implement this without any creative effort.

[0136] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0137] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention 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 the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for automatically publishing a web-based component library, characterized in that, The method includes: Step S1: Parse the command-line parameters entered by the user to obtain the version update type and the identifier of the component to be released; Step S2: Verify the current working status of the code repository to provide a clean code baseline for subsequent version updates; Step S3: Based on the version update type, uniformly update the version number of each component in the component library and generate the corresponding version change record; Step S4: Based on the version change record and the identifier of the component to be released, perform the release operation on the specified component, create a traceable version tag, and restore the state before release in case of an exception.

2. The method for automatically publishing a web-based component library according to claim 1, characterized in that, In step S1, parsing the command-line parameters input by the user includes: receiving the update type parameter and the list of components to be released input by the user through the command-line interface, parsing the received parameters through the parameter parsing library, and generating a structured version update type identifier and a set of component names to be released.

3. The method for automatically publishing a web-based component library according to claim 2, characterized in that, In step S1, the update type parameter includes three values: major version number update, minor version number update, or revision number update. These correspond to version change requirements in the semantic version control specification for incompatible API changes, backward compatible feature additions, and backward compatibility issue corrections. The list of components to be released parameter supports specifying a single component name, a combination of multiple component names, or using the default method to indicate the release of all components.

4. The method for automatically publishing a web-based component library according to claim 1, characterized in that, In step S2, verify the current working status of the code repository as follows: By calling the status query command provided by the version control system, the file change status information of the current working area and the staging area can be obtained; Parse the file's change status information to determine if there are any uncommitted code modifications. If there are no uncommitted changes, continue with the subsequent release process; If there are uncommitted changes, output an error message to the user containing information about the uncommitted files, record the status exception identifier, and trigger the exception handling logic to terminate the current release process.

5. The method for automatically publishing a web-based component library according to claim 1, characterized in that, In step S3, the version numbers of each component in the component library are updated uniformly in the following manner: Read the current version number from the package description file in the root directory, increment the corresponding bits of the current version number according to the version update type, reset the low bits of the version number to zero, and generate a new version number that conforms to the semantic versioning specification. The system iterates through all sub-package directories in the project, reads the package description files of each sub-package, and writes the new version number into the version number field of the root package and all sub-package package description files respectively, thereby achieving consistent version number updates across the multi-package architecture of the entire component library.

6. The method for automatically publishing a web-based component library according to claim 1, characterized in that, In step S3, the corresponding version change record is generated as follows: Invoke the pre-configured change log generation tool, which extracts commit information that conforms to the convention commit specification from the commit history of the version control system; Submitted information is categorized and formatted according to classification dimensions to generate or update standardized change log files. Classification dimensions include new features, bug fixes, and incompatible changes. Based on the system's preset document storage path configuration, the generated change log files will be copied and migrated to the specified document directory or component directory.

7. The method for automatically publishing a web-based component library according to claim 1, characterized in that, In step S4, based on the version change record and the identifier of the component to be released, a release operation is performed on the specified component, including: The set of target components to be published is determined based on the identifier of the component to be published. The set of target components is traversed. For each component to be published, the package server is logged in and authenticated through the identity authentication mechanism of the package manager. After successful login, a trusted connection session with the package server is established. Switch to the directory corresponding to the component, read the latest version number in the component package description file, and call the package publishing command to push the component package to the preset package server; Record the release status of each component and output a summary release log after all components have been released.

8. The method for automatically publishing a web-based component library according to claim 1, characterized in that, In step S4, a traceable version tag is created as follows: Based on the new version number, generate a tag name that the version control system can recognize according to the preset tag naming rules; The file addition operation adds the updated package description file and change log file to version management; the commit operation creates a commit record containing version update information, with the new version number and change summary automatically embedded in the commit information; the tag creation operation associates and binds the generated tags with the current commit record. Perform a push operation to synchronously push the new commit and associated tags to the remote code repository.

9. The method for automatically publishing a web-based component library according to claim 1, characterized in that, In step S4, the restoration to the pre-release state is achieved in the event of an exception as follows: The system maintains a global exception monitoring flag to track the execution status of each step in the entire release process; when an exception is thrown during the execution of any release step, the exception is captured and detailed error information is recorded. Determine whether the current exception is an exception that occurred during the release process. If it is, call the state reset command of the version control system to undo all file modifications and commits made in this release process, and restore the working area, staging area and repository to the state before this release started. The entire release process is terminated with an error status code, and a message is displayed to the user indicating the reason for the error and the automatic recovery completion status.

10. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method according to any one of claims 1-9.

Images