SAAS-oriented online car-hailing component dependency management method and system

Abstract

The invention discloses an SAAS-oriented online car-hailing component dependency management method and system. The invention relates to the technical field of online car hailing. The method comprises the following steps: reading a pnpm-workspace. Yaml file and a pacge.json file under a root directory of Monorepo, and identifying and loading a global dependency and a script; according to the configuration, a basic directory structure of the Monorepo project is created or verified, and the basic directory structure comprises each sub-project and a shared public dependent package in a packet folder; according to the invention, the dependency management of a plurality of sub-projects is unified into one Monorepo environment, so that the installation, updating and maintenance of dependencies become more centralized and efficient. By sharing the public dependent package, repeated installation and storage are reduced, and the disk space is saved. The lock file mechanism ensures that all the sub-projects use dependencies of the same version, and construction or operation errors caused by version inconsistency are avoided. This improves the stability and repeatability of the project such that dependency behavior in development, test and production environments remains consistent.

Description

Technical Field

[0001] The present invention relates to the technical field of online car-hailing, specifically to the technical field of operation and maintenance management of online car-hailing platforms, and particularly to a method and system for component dependency management of online car-hailing oriented to SAAS. Background Art

[0002] In the technological development of the travel field, with the continuous evolution of intelligent transportation systems, shared travel models, and autonomous driving technologies, front-end technologies such as SAAS (Software as a Service) online car-hailing platforms play an increasingly crucial role in travel-related applications. To ensure the consistency of dependency relationships between different sub-projects and significantly improve development efficiency, many enterprises in the travel industry have begun to prefer using npm (Node Package Manager) package management tools to manage the dependencies of multiple front-end sub-projects.

[0003] In this context, pnpm has gradually emerged as an efficient JavaScript package management tool. Through innovative symbolic linking technology, pnpm enables the sharing of dependencies, thereby greatly optimizing the use of disk space and accelerating the installation speed of dependencies. In addition, pnpm also ensures the consistency of dependency versions between sub-projects, which is crucial for maintaining the stability and reliability of large-scale projects.

[0004] At the same time, the Monorepo (single repository for multiple projects) architecture approach has also been widely applied in the front-end development of the travel field. Monorepo integrates multiple projects in the same code repository, enabling these sub-projects to share the same development tools and dependency libraries. This architecture approach not only simplifies the project management process but also promotes collaborative development among teams and improves overall development efficiency.

[0005] However, traditional dependency management tools (such as npm or yarn) often face many challenges when dealing with large-scale project architectures. These tools are prone to causing dependency conflicts, resulting in inconsistent dependency versions between different sub-projects; at the same time, they also reinstall dependencies repeatedly, leading to waste of disk space and extension of installation time. Especially in the case where multiple sub-projects need to share dependencies, the problems of traditional tools are more prominent, seriously affecting the build and development efficiency.

[0006] Therefore, the travel field urgently needs an innovative solution to effectively manage and optimize front-end dependencies. Such a solution should be able to avoid repeated installation of dependencies, improve build efficiency, and ensure the consistency of dependency versions between multiple sub-projects. For this reason, the present invention proposes a method and system for component dependency management of online car-hailing oriented to SAAS. Summary of the Invention

[0007] In view of this, the present invention hopes to provide a method and system for component dependency management of online car-hailing services oriented to SAAS to solve or alleviate the technical problems existing in the prior art, that is, how to solve the problems in multi-subproject dependency management, ensure the consistency of dependency versions, optimize the build and development efficiency, and achieve automatic processing of dependency conflicts. The technical solution of the present invention is implemented as follows:

[0008] In a first aspect, a method for component dependency management of online car-hailing services oriented to SAAS:

[0009] (1) Overview:

[0010] Based on pnpm and the Monorepo architecture, the present invention realizes the unified management of front-end dependencies. By building a Monorepo environment, multiple front-end projects are integrated into a single code repository. Utilizing the efficient symbolic link mechanism and cache mechanism of pnpm, the installation and management process of dependencies are optimized. The pnpm-workspace.yaml file and the package.json file jointly define the dependency relationships and configurations of the project, enabling sub-projects to conveniently reference shared common dependency packages while maintaining the consistency of dependency versions. By generating an exact version lock file (shrinkwrap), the repeatability and stability of the build are ensured. In addition, the ability to monitor and automatically handle dependency conflicts is provided. When potential dependency conflicts are detected, it is possible to automatically attempt to update the dependency version or adjust the dependency relationship, thereby simplifying the development process, improving development efficiency, and providing strong support for the continuous integration and delivery of front-end projects.

[0011] (2) Technical solution:

[0012] After receiving an instruction to start a front-end dependency unified management system based on the pnpm architecture and the Monorepo architecture, the following operation steps are started:

[0013] 2.1 Step S1, initialize the Monorepo environment:

[0014] Read the pnpm-workspace.yaml file and the package.json file in the Monorepo root directory, identify and load global dependencies and scripts; according to the configuration, create or verify the basic directory structure of the Monorepo project, including each sub-project and shared common dependency packages under the packages folder.

[0015] 2.1.1 Step S100, read the configuration file:

[0016] Identify which sub-projects and shared common dependencies are included in the Monorepo: Open the pnpm-workspace.yaml file located in the root directory of the Monorepo and parse the packages field in its content (which lists the directory paths of all sub-projects that need to be managed by pnpm). Then identify and load the global dependencies and scripts.

[0017] Identify and load the global dependencies and scripts: Ensure that all sub-projects can access the global dependencies. Install the global dependencies according to the dependencies and devDependencies fields in the package.json file. pnpm will automatically handle the flattening and symlinking of dependencies to avoid duplicate installations.

[0018] Load the global scripts: Parse the scripts field in the package.json file and add the global script commands to the pnpm command list. For example, you can use the pnpm run build command to uniformly execute the build tasks of all sub-projects.

[0019] 2.1.2 Step S101, Create or verify the basic directory structure of the Monorepo project

[0020] Ensure that all sub-projects are placed in the correct directories. Check if there is a packages folder in the root directory of the Monorepo. If not, create this folder. The packages folder is used to store all sub-projects.

[0021] According to the packages field in the pnpm-workspace.yaml file, check if the corresponding sub-project directories exist under the packages folder. If not, create these directories according to the configuration or requirements.

[0022] 2.1.3 Step S102, Verify or create the shared dependency package directory:

[0023] Ensure that all shared common dependency packages are placed in the correct directories. According to the requirements and project structure, other folders (such as libs, common, etc.) can be created in the root directory of the Monorepo to store the shared common dependency packages.

[0024] 2.2 Step S2, Load sub-project dependencies:

[0025] For each sub-project (such as app1, app2, etc.), read its package.json file and identify and load its specific dependencies and the common dependency packages referenced through the workspace pointer;

[0026] Utilize pnpm's efficient symlink mechanism to avoid duplicate installations of the same dependencies and optimize disk space usage.

[0027] 2.2.1 Step S200, traverse sub-project directories:

[0028] According to the Monorepo configuration (such as the pnpm-workspace.yaml file), traverse all sub-project directories (such as app1, app2, etc.) under the packages folder; for each sub-project directory, open its package.json file and parse its content. This file contains fields such as dependencies and devDependencies, listing the dependencies specific to the sub-project.

[0029] 2.2.2 Step S201, identify and load specific dependencies:

[0030] Based on the dependencies and devDependencies fields in the package.json file, identify the dependencies specific to the sub-project and install them via pnpm. pnpm will install these dependencies into the node_modules directory of the sub-project.

[0031] 2.2.3 Step S202, identify and load common dependency packages referenced through workspace pointers:

[0032] When parsing the package.json file of the sub-project, check if there are references to common dependency packages in the Monorepo (usually achieved through regular dependency declarations, as pnpm's workspace mechanism will automatically handle these dependencies). pnpm will, according to the Monorepo configuration, use the symlink mechanism to link the common dependency packages to the node_modules directory of the sub-project, avoiding duplicate installations.

[0033] 2.2.4 Step S203, utilize pnpm's efficient symlink mechanism:

[0034] When pnpm installs dependencies, it checks if the same dependencies already exist in the Monorepo. If so, pnpm will create a symlink pointing to the installed dependency instead of downloading and installing it again. This greatly saves disk space and speeds up the dependency installation process.

[0035] 2.3 Step S3, generate a lock file and ensure version consistency:

[0036] Generate or update pnpm's lock file (shrinkwrap) that records the exact versions of dependencies in all sub-projects and common dependency packages;

[0037] Through the lock file mechanism, the system ensures that all sub-projects use the same version of dependencies, thus avoiding build or runtime errors caused by version inconsistencies.

[0038] 2.3.1 Step S300, generate or update the pnpm-lock.yaml file:

[0039] Run the pnpm install command in the Monorepo root directory; pnpm will automatically parse the package.json files of all sub-projects, install all dependencies, and generate or update the pnpm-lock.yaml file; the pnpm-lock.yaml file contains the exact version numbers, source information, and verification hashes of the dependencies required for all sub-projects and common dependency packages in the Monorepo.

[0040] 2.3.2 Step S301, verify the content of the lock file:

[0041] Open the pnpm-lock.yaml file and check its structure and content. The file contains multiple sections, each corresponding to a sub-project or a common dependency package, listing all its dependencies and their version information. Ensure that the dependencies of all sub-projects and common dependency packages are correctly recorded in the lock file.

[0042] 2.3.3 Step S302, the role and mechanism of the lock file:

[0043] The pnpm-lock.yaml file locks the exact version of each dependency, ensuring that pnpm uses the same version every time dependencies are installed. This avoids build or runtime errors caused by upgrades or downgrades of dependency versions;

[0044] When other developers or CI / CD systems run pnpm install in the same Monorepo, pnpm will use the pnpm-lock.yaml file to resolve and install dependencies, ensuring that everyone uses the same version of dependencies.

[0045] The lock file also contains cache information for dependencies, which can speed up subsequent dependency installations.

[0046] 2.3.3 Step S302, ensure version consistency:

[0047] In the Monorepo, all sub-projects and common dependency packages share the same pnpm-lock.yaml file; when any sub-project updates its dependency version, it will affect the lock file and thus affect other sub-projects.

[0048] 2.3.4 Step S303, Integrate the lock file into the version control system:

[0049] Add the pnpm-lock.yaml file to the version control system (such as Git) of the Monorepo; ensure that the lock file is also updated and committed accordingly each time the code is committed. This helps to track changes in dependency versions and roll back to previous versions when needed.

[0050] 2.4 Step S4, Execute build and development tasks:

[0051] When a user or an automated tool executes build and development tasks in the Monorepo environment, trigger the caching mechanism of pnpm, and the system accelerates the installation and build process of dependencies.

[0052] 2.4.1 Step S400, Trigger the caching mechanism of pnpm:

[0053] When pnpm installs dependencies, it automatically caches the dependencies in the local or remote cache. In subsequent installation processes, if the dependency versions have not changed, pnpm can directly obtain the dependencies from the cache without having to redownload them. When executing build and development tasks, pnpm utilizes this caching mechanism to quickly obtain the required dependencies, thereby accelerating the build process.

[0054] 2.4.2 Step S401, Execute the build task:

[0055] According to the build scripts of the sub-projects (defined in the scripts field of package.json), run the corresponding build commands. For example, you can run pnpm run build to execute the build task; pnpm will parse and execute the build scripts, utilize the caching mechanism to accelerate the installation of dependencies, and execute the build process. During the build process, pnpm will ensure that all sub-projects use the same version of dependencies, thus avoiding problems caused by version inconsistencies.

[0056] 2.4.3 Step S402, Execute the development task:

[0057] According to the development scripts of the sub-projects (also defined in the scripts field of package.json), run the corresponding development commands. For example, you can run pnpm run dev to start the development server. pnpm will parse and execute the development scripts, utilize the caching mechanism to accelerate the installation of dependencies, and start the development process. During the development process, pnpm will continuously monitor file changes and automatically rebuild or refresh the development server to provide instant feedback and development experience.

[0058] 2.4.4 Step S403, Optimize build and development performance:

[0059] Utilize the parallel execution feature of pnpm to handle the build and development tasks of multiple sub-projects simultaneously. This can be achieved by using the pnpm -r (recursive) flag in the build and development scripts; configure the caching strategy of pnpm, such as setting the local cache directory, enabling remote caching, etc., to further optimize the installation speed of dependencies. Regularly clean up useless caches and dependencies to free up disk space and improve performance.

[0060] 2.5 Step S5, Monitor and Automatically Handle Dependency Conflicts:

[0061] Continuously monitor the changes in dependencies in the Monorepo environment; when potential dependency conflicts are detected, automatically resolve the conflicts by updating the dependency versions or adjusting the dependency relationships; if the automatic resolution fails, issue a warning to the user.

[0062] (III) Mechanisms for Solving Technical Problems:

[0063] 3.1 Solve the Dependency Management Problem of Multiple Sub-Projects

[0064] Integrate all sub-projects into a single codebase for unified management and code sharing. Through the pnpm-workspace.yaml file, it is possible to clearly specify which directories contain sub-projects to achieve the division of the workspace.

[0065] Utilize the symbolic link mechanism of pnpm to avoid duplicate installation of the same dependencies, save disk space, and improve the installation speed. At the same time, the flattened dependency structure of pnpm reduces the depth of the dependency tree, further optimizing dependency management.

[0066] 3.2 Ensure Dependency Version Consistency

[0067] By generating a pnpm-lock.yaml (or a similar file, the specific name may vary depending on the version) lock file, record the exact versions of dependencies in all sub-projects and common dependency packages. When installing dependencies each time, pnpm will check the lock file to ensure that the installed dependency versions are consistent with those recorded in the lock file, thus avoiding build or runtime errors caused by version inconsistencies.

[0068] 3.3 Optimize Build and Development Efficiency

[0069] pnpm utilizes the caching mechanism to accelerate the installation process of dependencies. For dependencies that have already been downloaded and installed, pnpm will directly obtain them from the cache, reducing the time for network downloads and disk writes, and improving build and development efficiency.

[0070] 3.4 Implement Automatic Handling of Dependency Conflicts

[0071] When multiple sub-projects in a Monorepo depend on the same third-party library but have inconsistent versions, pnpm will try to select the most appropriate version through an arbitration mechanism. If the arbitration fails, pnpm can also provide a detailed conflict report to help developers resolve the conflict manually. In addition, by continuously monitoring changes in dependencies, pnpm can issue warnings before dependency conflicts occur and attempt to automatically adjust dependencies or update dependency versions to resolve conflicts.

[0072] In a second aspect, a ride-hailing component dependency management system for SAAS:

[0073] As Figure 2 shown, this system is used to implement a ride-hailing component dependency management method for SAAS as described above, and it includes:

[0074] (1) Monorepo Management Module: Responsible for the initialization, configuration, and management of the entire Monorepo environment. Read the pnpm-workspace.yaml and package.json files in the root directory to identify and load global dependencies and scripts; create or verify the basic directory structure of the Monorepo project, including each sub-project under the packages folder and shared common dependency packages.

[0075] (2) Dependency Loading Module: Responsible for loading and parsing the dependencies of each sub-project. For each sub-project, read its package.json file to identify and load its specific dependencies and the common dependency packages referenced through workspace pointers. Utilize pnpm's efficient symbolic link mechanism to avoid duplicate installation of the same dependency and optimize disk space usage.

[0076] (3) Version Control Module: Responsible for ensuring the version consistency of dependencies. Generate or update pnpm's lock file to record the exact versions of dependencies in all sub-projects and common dependency packages. When installing dependencies each time, check the lock file to ensure that the installed dependency versions are consistent with those recorded in the lock file.

[0077] (4) Build and Development Support Module: Provide support for build and development tasks. When a user or an automated tool executes build and development tasks in the Monorepo environment, trigger pnpm's caching mechanism to accelerate the installation and build process of dependencies.

[0078] (5) Dependency Conflict Handling Module: Responsible for monitoring and automatically handling dependency conflicts. Continuously monitor changes in dependencies in the Monorepo environment. When a potential dependency conflict is detected, attempt to automatically update dependency versions or adjust dependencies to resolve the conflict. If the automatic resolution fails, issue a warning to the user.

[0079] Among them:

[0080] (1) Monorepo Management Module and Dependency Loading Module: After the Monorepo management module initializes and configures the Monorepo environment, the dependency loading module loads the dependencies of each sub-project according to the information provided by the Monorepo management module.

[0081] (2) Dependency Loading Module and Version Control Module: After the dependency loading module loads the dependencies, the version control module is responsible for generating or updating the lock file to record the exact versions of the dependencies. During subsequent dependency installation, the version control module checks the lock file to ensure that the installed dependency versions are consistent with those recorded in the lock file.

[0082] (3) Version Control Module and Build and Development Support Module: After the version control module ensures the version consistency of the dependencies, the build and development support module can use the cache mechanism more efficiently when performing build and development tasks, accelerating the installation and build process of the dependencies.

[0083] (4) Build and Development Support Module and Dependency Conflict Handling Module: During the build and development process, the dependency conflict handling module continuously monitors changes in the dependency relationships. If a potential dependency conflict is detected, the dependency conflict handling module attempts to automatically resolve the conflict to ensure the smooth progress of the build and development tasks. If the automatic resolution fails, a warning is issued to the user, and the build and development support module may pause or interrupt the current task, waiting for the user to resolve the conflict.

[0084] (5) Dependency Loading Module and Dependency Conflict Handling Module: When the dependency loading module loads the dependencies, if a potential dependency conflict is detected (for example, multiple sub-projects depend on the same third-party library but with inconsistent versions), it immediately notifies the dependency conflict handling module. The dependency conflict handling module attempts to automatically resolve the conflict to ensure the smooth progress of the dependency loading.

[0085] Compared with the prior art, the beneficial effects of the present invention are:

[0086] I. Unified Dependency Management: The present invention unifies the dependency management of multiple sub-projects into a single Monorepo environment, making the installation, update, and maintenance of dependencies more centralized and efficient. By sharing common dependency packages, duplicate installations and storage are reduced, saving disk space. The lock file mechanism ensures that all sub-projects use the same version of dependencies, avoiding build or runtime errors caused by version inconsistencies. This improves the stability and repeatability of the project, making the dependency behavior consistent in the development, testing, and production environments.

[0087] II. Improvement in construction and development efficiency: The efficient symbolic link mechanism and caching mechanism of pnpm accelerate the installation process of dependencies and reduce the construction time. The Monorepo architecture makes code sharing and reuse more convenient and improves development efficiency.

[0088] III. Automatic handling of dependency conflicts: The present invention provides the ability to automatically handle dependency conflicts. When potential dependency conflicts are detected, it can automatically attempt to update the dependency versions or adjust the dependency relationships. This reduces the time and effort required for manual conflict resolution and improves the smoothness of the development process. The Monorepo architecture makes the overall structure of the project clearer, facilitating understanding and maintenance. Through unified dependency management and construction processes, the complexity of the project is reduced and maintainability is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0090] Figure 1 It is a schematic diagram of the method of the present invention;

[0091] Figure 2 It is a schematic diagram of the system composition of the present invention;

[0092] Figure 3 It is a schematic diagram of the solution configuration of the present invention;

[0093] Figure 4 It is a schematic diagram of the method flow of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0094] In order to make the above objects, features, and advantages of the present invention more obvious and understandable, the following will provide a detailed description of the specific embodiments of the present invention with reference to the drawings. Many specific details are set forth in the following description in order to fully understand the present invention. However, the present invention can be implemented in many other ways different from those described herein. Those skilled in the art can make similar improvements without departing from the spirit of the present invention. Therefore, the present invention is not limited by the specific embodiments disclosed below;

[0095] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts among the various embodiments can be referred to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

[0096] Explanation of related terms:

[0097] (1) pnpm architecture: Refers to the system architecture that uses pnpm as a dependency management tool and utilizes the features of pnpm to optimize dependency management.

[0098] (2) Monorepo architecture: A code repository management method that stores multiple projects (sub-projects) in a single code repository, facilitating unified management and code sharing.

[0099] (3) Monorepo environment: Refers to the development environment that runs the Monorepo architecture code repository.

[0100] (4) Monorepo root directory: The top-level directory of the Monorepo code repository, containing all sub-projects and global configurations.

[0101] (5) pnpm-workspace.yaml file: The configuration file used by pnpm to define the Monorepo workspace, specifying which directories contain sub-projects.

[0102] (6) package.json file: The configuration file for Node.js projects, containing information such as project dependencies, scripts, and metadata.

[0103] (7) Configuration: The process or result of setting up and adjusting a system, software, or device to meet specific requirements or optimize performance. In this solution, the configuration may involve settings for Monorepo and pnpm.

[0104] (8) Monorepo project: The entire project collection based on the Monorepo architecture, containing multiple sub-projects and shared code.

[0105] (9) packages folder: In Monorepo, the folder used to store each sub-project.

[0106] (10) workspace pointer: A pointer used in the package.json file to reference other sub-projects or shared packages in the Monorepo, usually expressed as "workspace:*".

[0107] (11) Efficient symbolic link mechanism of pnpm: pnpm uses symbolic links to avoid reinstalling the same dependencies, thus saving disk space and installation time.

[0108] (12) Exact version lock file (shrinkwrap): A file generated by pnpm that records the exact versions of project dependencies, ensuring build consistency and reproducibility.

[0109] (13) Lock file mechanism: Use a lock file to ensure version consistency of dependencies in a project, avoiding build or runtime errors caused by version changes.

[0110] (14) pnpm's caching mechanism: pnpm utilizes caching to accelerate the installation process of dependencies, reducing download and installation time.

[0111] (15) Update dependency versions: Upgrade the dependencies used in a project to new versions according to requirements or to resolve dependency conflicts.

[0112] (16) Adjust dependency relationships: Modify the dependency relationships between dependencies in a project to resolve conflicts or optimize the project structure.

[0113] Example 1: As Figure 1 、 3 and shown in 4, this example discloses a method for managing component dependencies of online car-hailing for SAAS:

[0114] In the field of online car-hailing in the SAAS platform, with the rapid development of cutting-edge technologies such as intelligent transportation, shared mobility, and autonomous driving, front-end technologies play a core role in building diverse travel applications. These applications often consist of multiple sub-projects with complex dependency relationships. However, traditional dependency management tools (such as npm or yarn) face many challenges when dealing with this multi-sub-project architecture: Different sub-projects may use different versions of the same dependency, resulting in build or runtime errors. The same dependency may be repeatedly installed in multiple sub-projects, causing waste of disk space and extension of installation time. Due to improper dependency management, the build and development processes may become long and inefficient. Manually handling dependency conflicts is not only time-consuming and laborious but also prone to introducing new errors. Therefore, the solution provided in this example will address the above situations:

[0115] In this example, regarding step S1: Initialize the Monorepo environment:

[0116] Read the configuration file (S100): In the Monorepo root directory of the SAAS online car-hailing platform, open the pnpm-workspace.yaml file, which lists the directory paths of all sub-projects (such as driver-app, rider-app, admin-dashboard, etc.). At the same time, parse the package.json file and install global dependencies (such as typescript, eslint, etc.), which will be shared by all sub-projects.

[0117] pnpm automatically handles the flattening and symbolic linking of dependencies to ensure that global dependencies are not reinstalled.

[0118] Create or verify the basic directory structure (S101): Check and create the packages folder to store all sub-projects. Verify or create sub-project directories according to the configuration in pnpm-workspace.yaml.

[0119] Verify or create the shared dependency package directory (S102): Create a libs folder under the Monorepo root directory to store shared common dependency packages (such as api-client, utils, etc.).

[0120] It can be understood that by centrally managing the configuration files, the consistency and maintainability of all sub-projects are ensured. Using pnpm's symbolic linking mechanism, the repeated installation of global dependencies is avoided, saving disk space.

[0121] The management efficiency of dependencies is improved, and manual configuration errors are reduced. The setup process of the development environment is accelerated.

[0122] In this embodiment, regarding step S2: Loading sub-project dependencies:

[0123] Traverse the sub-project directories (S200): Traverse all sub-project directories under the packages folder, such as driver-app, rider-app, etc. Open the package.json file of each sub-project and parse its dependencies.

[0124] Identify and load specific dependencies (S201): Install the dependencies specific to the sub-project according to the dependencies and devDependencies fields in the package.json.

[0125] Identify and load the shared dependency packages (S202): Check the references of the sub-project to the shared dependency packages in the libs. pnpm automatically handles these dependencies and links them to the node_modules directory of the sub-project through the symbolic linking mechanism.

[0126] Utilize the symbolic linking mechanism (S203): pnpm checks if the same dependency already exists in the Monorepo. If it exists, a symbolic link is created to avoid reinstallation.

[0127] Through the symbolic linking mechanism, it is ensured that the same dependency is installed only once, greatly saving disk space. The installation speed of dependencies is accelerated, and the development efficiency is improved.

[0128] Reduces the installation time of dependencies and enhances the development experience. Reduces disk space occupancy.

[0129] In this embodiment, regarding step S3: Generate a lock file and ensure version consistency:

[0130] Generate or update the lock file (S300): Run the pnpm install command in the Monorepo root directory. Pnpm automatically parses the package.json files of all sub-projects, installs the dependencies, and generates or updates the pnpm-lock.yaml file.

[0131] Verify the content of the lock file (S301): Open the pnpm-lock.yaml file, check its structure and content to ensure that the dependencies of all sub-projects and common dependency packages are correctly recorded.

[0132] The role and mechanism of the lock file (S302): The pnpm-lock.yaml file locks the exact version of each dependency, ensuring that the same version is used every time dependencies are installed. When other developers or the CI / CD system runs, the lock file is used to resolve and install the dependencies to ensure version consistency.

[0133] Ensure version consistency (S302): All sub-projects and common dependency packages share the same lock file. Any update to the dependency version in a sub-project will affect the lock file, thus ensuring version consistency across the entire Monorepo.

[0134] Integrate the lock file into the version control system (S303): Add the pnpm-lock.yaml file to the Git version control system and ensure that the lock file is updated and committed every time the code is committed.

[0135] The lock file ensures the consistency of dependency versions, avoiding build or runtime errors caused by version inconsistencies. By managing the lock file through the version control system, changes in dependency versions can be tracked and rolled back to previous versions when needed. Improves the stability and maintainability of the project. Facilitates team collaboration and the implementation of the CI / CD process.

[0136] In this embodiment, regarding step S4: Execute build and development tasks:

[0137] Trigger the caching mechanism of pnpm (S400): Pnpm automatically caches the dependencies locally or remotely when installing the dependencies. When executing build and development tasks, pnpm utilizes the caching mechanism to quickly obtain the required dependencies.

[0138] Execute the build task (S401): Run the pnpm run build command. pnpm parses and executes the build script, accelerates the installation of dependencies using the cache mechanism, and executes the build process. During the build process, pnpm ensures that all sub-projects use the same version of dependencies.

[0139] Execute the development task (S402): Run the pnpm run dev command. pnpm parses and executes the development script, and starts the development server. During development, pnpm continuously monitors file changes and automatically rebuilds or refreshes the development server.

[0140] Optimize build and development performance (S403): Utilize the parallel execution feature of pnpm to handle the build and development tasks of multiple sub-projects simultaneously. Configure the cache policy of pnpm, such as setting the local cache directory, enabling remote caching, etc. Regularly clean up unused caches and dependencies to free up disk space and improve performance.

[0141] Through the cache mechanism, the installation of dependencies and the build process are accelerated. The parallel execution feature improves the execution efficiency of build and development tasks. The development efficiency and experience are enhanced. Resource utilization is optimized, and development costs are reduced.

[0142] In this embodiment, regarding step S5: Monitor and automate the handling of dependency conflicts:

[0143] Continuously monitor changes in dependencies:

[0144] Use tools (such as the dependency management tool built into pnpm or third-party tools) to continuously monitor changes in dependencies in the Monorepo environment. When potential dependency conflicts are detected, the tool automatically attempts to update the dependency version or adjust the dependency relationship to resolve the conflict. If the automatic resolution fails, a warning is issued to the user, prompting manual intervention.

[0145] Through continuous monitoring and automated handling, dependency conflicts are detected and resolved in a timely manner, ensuring the stability and maintainability of the project. The time and effort required for manual handling of dependency conflicts are reduced. The reliability and stability of the project are improved.

[0146] Embodiment 2: On the basis of Embodiment 1, this embodiment further provides the following Python execution program for this solution:

[0147]

[0148]

[0149]

[0150]

[0151]

[0152]

[0153]

[0154]

[0155] In the above program:

[0156] Step S1: Initialize the Monorepo environment:

[0157] Read the configuration: Check and create pnpm-workspace.yaml to define the package paths of the Monorepo.

[0158] Install global dependencies: Use pnpm's global installation mechanism to install shared dependencies (such as typescript).

[0159] Create the directory structure: Ensure that the packages and libs directories exist and create the basic structure of the sub-projects (including the package.json file).

[0160] Step S2: Load sub-project dependencies:

[0161] Traverse the sub-projects: Read the package.json file of each sub-project and install its dependencies.

[0162] Symbolic links: pnpm automatically handles symbolic links for common dependencies to avoid duplicate installations.

[0163] Step S3: Generate the lock file:

[0164] Generate the lock file: Automatically generate the pnpm-lock.yaml file when running pnpminstall.

[0165] Version consistency: Ensure that all developers use the same versions of dependencies through the lock file.

[0166] Step S4: Build and develop:

[0167] Cache mechanism: pnpm uses local and remote caches to accelerate dependency installation.

[0168] Parallel build: pnpm can process tasks for multiple sub-projects in parallel to improve the build efficiency.

[0169] Step S5: Dependency conflict monitoring:

[0170] Automated detection: Continuously monitor the dependency relationships and automatically adjust or issue warnings when conflicts are found.

[0171] It is understandable that the technical solution provided by this embodiment significantly reduces the problems of dependency conflicts and version inconsistencies through automated processing and unified management strategies. It avoids the repeated installation of dependencies and significantly reduces the consumption of disk space. By using efficient symbolic links and caching mechanisms, it significantly improves the build and development efficiency.

[0172] All of the above embodiments merely represent the implementation manners of the relevant practical applications of the present invention. The descriptions are relatively specific and detailed, but should not be construed as limiting the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can be made, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the present invention patent shall be subject to the appended claims.

[0173] For those skilled in the art, it can be further realized that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present invention.

[0174] Meanwhile, those skilled in the art can understand that all or part of the processes in the methods of all the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium provided in this application and used in the embodiments can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

Claims

1. A method for managing the dependency of online car-hailing components for SAAS, characterized in that: After receiving the instruction to start the unified front-end dependency management system based on pnpm and Monorepo architecture, start the following steps: S1, read the pnpm-workspace.yaml file and package.json file in the root directory of Monorepo, identify and load global dependencies and scripts; S2, for each sub-project (such as app1, app2, etc.), read its package.json file and identify and load its unique dependencies and the common dependency packages referenced by the workspace pointer; S3, generates or updates pnpm's lock file that records the exact versions of dependencies in all subprojects and public dependency packages; S4, when users or automated tools perform build and development tasks in a Monorepo environment, pnpm's cache mechanism is triggered to speed up the installation and build process of dependencies.

2. The method for managing online car-hailing component dependencies according to claim 1, characterized in that: In S1, according to the configuration, the basic directory structure of the Monorepo project is created or verified, including each sub-project under the packages folder and shared public dependency packages.

3. The method for managing online car-hailing component dependencies according to claim 2, characterized in that: The execution steps of S1 include: S100, identify which sub-projects and shared public dependency packages are included in Monorepo; identify and load global dependencies and scripts; load global scripts; S101, check whether there is a packages folder in the root directory of Monorepo; if not, create the folder; the packages folder is used to store all sub-projects; check whether there are corresponding sub-project directories under the packages folder; if not, create these directories according to the configuration; S102, create other folders in the Monorepo root directory to store shared public dependency packages.

4. The method for managing online car-hailing component dependencies according to claim 1, characterized in that: The execution steps of S2 include: S200, traverses all sub-project directories under the packages folder according to the configuration of Monorepo; for each sub-project directory, opens the package.json file under it and parses its content; S201, identify the sub-project-specific dependencies based on the dependencies and devDependencies fields in the package.json file and install them through pnpm; S202, when parsing the package.json file of the subproject, check whether there is a reference to the public dependency package in Monorepo; S203, when pnpm installs a dependency, it checks whether the same dependency already exists in Monorepo; if so, pnpm creates a symbolic link pointing to the installed dependency.

5. The method for managing online car-hailing component dependencies according to claim 1, characterized in that: In the S3, the system ensures that all subprojects use the same version of dependencies through the lock file mechanism, thereby avoiding build or runtime errors caused by inconsistent versions.

6. The method for managing online car-hailing component dependencies according to claim 5, characterized in that: The execution process of S3 includes: S300, run the pnpminstall command in the root directory of Monorepo; pnpm automatically parses the package.json files of all subprojects, installs all dependencies, and generates or updates the pnpm-lock.yaml file; S301, open the pnpm-lock.yaml file and check its structure and content; S302, the pnpm-lock.yaml file locks the exact version of each dependency, ensuring that pnpm uses the same version each time a dependency is installed; S302, in Monorepo, all subprojects and public dependency packages share the same pnpm-lock.yaml file; when any subproject updates its dependency version, it will affect the lock file and further affect other subprojects; S303, add the pnpm-lock.yaml file to the version control system of Monorepo; every time you commit the code, make sure the lock file is also updated and committed accordingly.

7. The method for managing online car-hailing component dependencies according to claim 1, 2, 4 or 5, characterized in that: The execution process of S4 includes: S400, pnpm automatically caches dependencies into a local or remote cache when installing dependencies; S401, running corresponding build commands according to the build script of the sub-project; S402 runs corresponding development commands according to the development script of the sub-project; S403, using the parallel execution feature of pnpm, simultaneously handles the construction and development tasks of multiple sub-projects.

8. The method for managing online car-hailing component dependencies according to claim 1, 2, 4 or 5, characterized in that: The method also includes step S5: continuously monitoring dependency changes in the Monorepo environment; when a potential dependency conflict is detected, automatically resolving the conflict by updating the dependency version or adjusting the dependency; if the automatic resolution fails, warning the user.

9. A system for implementing the method for managing online car-hailing component dependencies as claimed in any one of claims 1 to 8, characterized in that: The system comprises: Monorepo management module: responsible for the initialization, configuration and management of the entire Monorepo environment; Dependency loading module: responsible for loading and parsing the dependencies of each sub-project; Version control module: responsible for ensuring the version consistency of dependencies; Build and development support module: provides support for build and development tasks; Dependency conflict handling module: responsible for monitoring and automatically handling dependency conflicts.

10. The system according to claim 9, characterized in that: After the Monorepo management module initializes and configures the Monorepo environment, the dependency loading module loads the dependencies of each subproject based on the information provided by the Monorepo management module; Dependency loading module and version control module: After the dependency loading module loads the dependencies, the version control module is responsible for generating or updating the lock file to record the exact version of the dependencies.

Images