User-mode file system-based front-end module manager, management method and system

Abstract

The application discloses a front-end module manager based on a user state file system, and comprises an outer control unit, an application isolation unit and a bottom layer daemon process unit, wherein the outer control unit is used for initializing the application isolation unit and the bottom layer daemon process unit, acquiring preset module information corresponding to each project, and calling the operation instruction of the application isolation unit to create an isolation layer between modules in the project; the application isolation unit is used for receiving the creation operation instruction of the isolation layer to execute the creation of the isolation layer, generating the process ID of the isolation layer, and isolating the bottom layer storage when a user executes a write operation to prevent the bottom layer storage from being polluted; and the bottom layer daemon process unit is used for receiving the preset module information and generating a virtualization module directory according to the process ID of the isolation layer; the problems of slow installation speed and large occupation of hard disk space of the existing front-end module manager are solved, and the module performance requirement derived in the current front-end agile development process is met.

Description

Technical Field

[0001] This invention relates to the field of front-end development technology, and in particular to a front-end module manager, management method and system based on a user-space file system. Background Technology

[0002] FUSE (User-space File System) is a file system framework implemented in user space. With the support of the FUSE kernel module, users only need to implement specific file operations according to the interfaces provided by FUSE to create a file system. The core idea of ​​FUSE is to allow user-space programs to control the related logic of the file system, avoiding the awkward situation of difficult debugging of kernel-space code, while also enabling different flexible business requirements. This paper identifies the core pain points of efficiency optimization in the current module management field to determine whether the introduction of FUSE is worthwhile.

[0003] The shortcomings of existing front-end module management technologies are:

[0004] 1. Excessive module file decompression time: Front-end dependency packages typically contain a large number of small files, and there are also complex relationships between dependencies. The project's node_modules folder usually contains tens of thousands of files, which severely limits the module installation speed. Even when locks and caches are present, a lot of time is spent on decompression and small file I / O.

[0005] 2. No shared storage space for project modules: npm creates a node_modules directory for each project, which cannot share storage space, resulting in a huge waste of disk space.

[0006] 3. Polluting Global Storage: To address the above issues, pnpm introduced a combination of hard links and soft links for module management. However, the node_modules in a pnpm project cannot operate independently; debugging a module within a single project can pollute global storage.

[0007] Therefore, it is necessary to propose a front-end module management method based on a user-space file system to solve the problems of slow installation speed and large disk space consumption of existing front-end module managers, which cannot meet the module performance requirements arising in today's agile front-end development process. Summary of the Invention

[0008] The purpose of this invention is to provide a front-end module manager, management method, and system based on a user-space file system. This addresses the problems of slow installation speed and large disk space consumption in existing front-end module managers, which fail to meet the module performance requirements arising from today's agile front-end development. It utilizes COW (Copy on Write) technology to implement a top-level directory mirror layer for module isolation within projects, and employs a multi-project module management daemon process using process indexes. This daemon process generates virtualized module directories, bypassing the significant I / O time required for module decompression. Furthermore, by mounting a writable upper-layer, read-only lower-layer mirror directory, it solves the problem of modifications to module directories polluting the underlying storage during business project development. Simultaneously, a dependency graph is established in memory based on the upper-layer file system process index, supporting the simultaneous execution of different business projects. In this embodiment, each project contains multiple modules, and each module includes multiple sub-files.

[0009] The purpose of this invention is to provide a front-end module manager based on a user-space file system, comprising:

[0010] The outer control unit is used to initialize the application isolation unit and the underlying daemon process unit, obtain the corresponding preset module information under each project, and call the operation instructions of the application isolation unit to create the isolation layer between modules in the project.

[0011] An application isolation unit is used to receive the creation operation instruction of the isolation layer, execute the creation of the isolation layer, generate the process ID of the isolation layer, and isolate the underlying storage when the user performs a write operation to prevent pollution of the underlying storage.

[0012] The underlying daemon process unit is used to receive the preset module information and generate a virtualization module directory based on the isolation layer process ID. That is, it decompresses the original project package to an archive package, parses the virtualization module directory to obtain the dependency structure, and directly maps the target file entry to the archive package according to the dependency structure, so as to bypass the IO time consumption generated during the decompression of each module. Furthermore, by mounting the virtualization module directory, it skips the IO processing time during the download and decompression of modules in the existing technology and skips the copying process of multiple sub-files.

[0013] The virtualization module directory is generated by merging the application isolation unit and the underlying daemon process unit.

[0014] Preferably, it also includes a global storage unit, which provides a shared underlying storage space to each unit. The application isolation unit indexes the archive package according to the module name and version number of the preset module, and then returns it to different business projects for use.

[0015] Preferably, the application isolation unit is a union file system, which includes a merged node_modules virtual layer. The node_modules virtual layer includes an upper layer and a lower layer. When the current node issues an instruction to read a target file, if the target file exists in the upper layer, the target file is read directly; if the target file does not exist in the upper layer, the target file is read from the lower layer. If the target file is modified or deleted, the virtual layer copies the target file in the lower layer and transmits it to the upper layer to obtain a file copy based on the copy-on-write mechanism. When the file copy is modified, the file copy is modified based on the copy-on-write mechanism. The upper layer is the project-independent layer Upper Dir, and the lower layer is the mirror layer Lower Dir.

[0016] Preferably, the application isolation unit is set to an upper-level union file system to isolate module files. The union file system merges the top-level writable project-independent layer and the bottom-level global storage read-only layer into a node_modules directory. When the user program writes or modifies the project node_modules, it saves the changes in the project-independent layer based on copy-on-write technology, keeping the global storage read-only layer read-only.

[0017] Preferably, the module file content under the virtualization module directory is read directly from the tar archive based on the file size and offset data.

[0018] Preferably, the underlying daemon unit includes a FUSE kernel module and a user-space LibFUSE library. The FUSE kernel module is used to establish a connection with the VFS file system interface, receive requests from VFS, establish a pipeline through the connection control, and send the encapsulated request to user space. The user-space LibFUSE library is used to parse the library code of the FUSE data packet protocol, perform corresponding request operations in user space, output results, and return to kernel space. In the working state, it receives target file read instructions, receives VFS requests and passes them to object storage LibFUSE, passes them to the FUSE daemon through LibFUSE, identifies the target file to be read according to the dependency structure, locates the actual location of the target file, and stores the global file.

[0019] The purpose of this invention is to provide a front-end module management method based on a user-space file system, comprising:

[0020] Initialize the application isolation unit and the underlying daemon process unit, obtain the corresponding preset module information under each project, and call the operation instructions of the application isolation unit to create the isolation layer between modules in the project.

[0021] The system receives the creation operation instruction of the isolation layer, executes the creation of the isolation layer, generates the process ID of the isolation layer, and isolates the underlying storage when the user performs a write operation to prevent pollution of the underlying storage.

[0022] The system receives the preset module information and generates a virtualization module directory based on the isolation layer process ID. This involves decompressing the original project package into an archive package, parsing the virtualization module directory to obtain the dependency structure, and mapping the target file entry directly into the archive package based on the dependency structure. This bypasses the IO time consumption generated during the decompression of each module and mounts the virtualization module directory.

[0023] The virtualization module directory is generated by merging the application isolation unit and the underlying daemon process unit.

[0024] The purpose of this invention is to provide a front-end module management system based on a user-space file system, comprising:

[0025] The server and multiple clients connected to the server;

[0026] Each of the aforementioned clients runs a front-end module manager based on a user-space file system as described in the embodiments of the present invention;

[0027] The server runs a module library.

[0028] The purpose of this invention is to provide an electronic device, comprising:

[0029] The memory is used to store the processing program;

[0030] The processor, when executing the processing program, implements the front-end module management method based on the user-space file system as described in the embodiments of the present invention.

[0031] The purpose of this invention is to provide a readable storage medium storing a processing program, which, when executed by a processor, implements the front-end module management method based on a user-space file system as described in the embodiments of this invention.

[0032] Compared with the prior art, the present invention has the following beneficial effects:

[0033] 1. No need to decompress small files: This solution is based on FUSE design and directly generates the node_modules virtual image directory. You only need to decompress the original tgz format to a tar archive. Then, according to the parsed node_modules structure, the file entry is directly mapped to the archive (based on the file offset and size), saving a lot of time writing small files.

[0034] 2. Shared hard disk space: This solution can share the underlying storage. The file system can index the archive file package according to the module name and version number, and then return it to different business projects for use.

[0035] 3. Upper-layer business isolation: This invention isolates module files through an upper-layer union file system. The union file system merges the business-independent top-level writable layer and the lower-level global read-only storage layer into the node_modules directory. When user programs write or modify data in the project's node_modules, the changes are saved in the top-level independent layer (copy-on-write technology), keeping the lower layer read-only.

[0036] 4. Supports the generation of virtual node_modules directories by the FUSE daemon; supports the isolation of project modules to make up for the shortcomings of pnpm; supports multiple projects to use at the same time, that is, it should support multiple node_modules directories at the same time. Attached Figure Description

[0037] Figure 1 This is an architecture diagram of a front-end module manager based on a user-space file system in one embodiment of the present invention;

[0038] Figure 2 This is an example diagram of FUSE in one embodiment of the present invention;

[0039] Figure 3 This is an example diagram of a union file system according to an embodiment of the present invention;

[0040] Figure 4 This is a timing diagram of a scheme in one embodiment of the present invention. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Example 1

[0043] The term "comprising" and its variations as used herein are open-ended inclusion, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0044] It should be noted that the concepts of "first" and "second" mentioned in this application are only used to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0045] It should be noted that the terms "a" and "a plurality of" used in this application disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0046] See Figure 1 As shown, this invention provides a front-end module manager based on a user-space file system, including: an outer control unit, an application isolation unit, a low-level daemon process unit, and a global storage unit. This can be understood as the module management hierarchy in this example being: outer control program, application isolation layer - unionFS, low-level daemon process FUSE, and global module storage. It uses COW (copy-on-write) technology to implement a top-level directory mirror layer to achieve module isolation for projects, and uses a process index for multi-project module management daemon processes. This manager generates virtualized module directories by the daemon process, bypassing the significant I / O time required for module decompression. Furthermore, by mounting a writable upper-layer, read-only lower-layer mirror directory, it solves the problem of modifications to the module directory during business project development polluting the low-level storage. Simultaneously, a dependency graph is built in memory based on the upper-layer fs process index, supporting the simultaneous execution of different business projects.

[0047] Specifically, the outer control unit used in this embodiment is used to initialize the application isolation unit and the underlying daemon process unit, obtain the preset module information corresponding to each project, and call the operation instructions of the application isolation unit to create the isolation layer between modules in the project; and in this embodiment, the external control unit can be an outer control program;

[0048] An application isolation unit is used to receive the creation operation instruction of the isolation layer, execute the creation of the isolation layer, generate the process ID of the isolation layer, and isolate the underlying storage when the user performs a write operation to prevent pollution of the underlying storage; in this embodiment, the isolation layer can be an application isolation layer - unionFS. See also Figure 3As shown, this embodiment uses a Union File System (UNFS): multiple directories / branches can be mounted together under the same directory, while the physical locations of the directories are separate. UnionFS allows read-only and read-write directories to coexist, meaning that content can be deleted and added simultaneously. UnionFS has many applications, such as merging the main directories of different file systems on multiple disk partitions. Additionally, UnionFS has a copy-on-write feature, allowing it to merge read-only and read-write file systems, virtually enabling modifications to the read-only file system to be saved to the writable file system.

[0049] The underlying daemon unit receives the preset module information and generates a virtualized module directory based on the isolation layer process ID. This involves decompressing the original project package to an archive, parsing the virtualized module directory to obtain the dependency structure, and directly mapping the target file entry point to the archive based on the dependency structure. This bypasses the I / O time consumed during module decompression and mounts the virtualized module directory. In this embodiment, the underlying daemon can be FUSE. Based on the FUSE design, a virtual node_modules directory is directly generated. This only requires decompressing the original tgz format to a tar archive and then directly mapping the file entry point to the archive based on the parsed node_modules structure. This saves significant time writing small files based on file offsets and sizes. The underlying storage can be shared; the file system can index the archive file package based on the module name and version number and then return it to different business projects. It supports the generation of virtual node_modules directories by the FUSE daemon, supports project module isolation, compensates for the shortcomings of pnpm, and supports simultaneous use by multiple projects, meaning it should support multiple node_modules directories simultaneously.

[0050] A global storage unit provides shared underlying storage space to all units. The application isolation unit indexes the archive package based on the module name and version number, and then returns it to different business projects. In this embodiment, it can be module-wide storage.

[0051] The virtualization module directory is generated by merging the application isolation unit and the underlying daemon process unit, and is configured as an upper-layer writable mode and an underlying read-only mode.

[0052] In one embodiment, the virtualized module directory generated in this implementation is the virtual node_modules directory, or simply the virtual directory. Without considering manually handling the generation of lock files, we can use the npm-provided parsing library @npmcli / arborist to process the lock files into a dependency tree and then extract the required content. In this scenario, after extracting the download path of the module's tgz file, we handle the download and decompression logic, and the final storage format is a tar archive file. Then, we pass the dependency tree information to the daemon process for analysis. The daemon process can generate the corresponding virtualized module directory based on the dependency structure. The specific module file content under this directory can be directly read and returned from the tar archive file based on file size and offset data. Private folder prefixes in the @xxx format are handled separately, generating virtual directories for the corresponding modules under them. Other modules in ordinary formats directly generate directories under the root node_modules. Since npm's flattening scheme still has the limitation that different versions of sub-dependencies cannot be promoted and need to be maintained by the dependencies themselves under their own node_modules, we need to confirm whether it is necessary to maintain a next-level node_modules in the dependency directory. The .bin directory needs to be confirmed based on the bin section in the dependency package.json, and corresponding symbolic link files should be generated.

[0053] In one embodiment, the application isolation unit is configured as an upper-level union file system to isolate module files. This union file system merges a top-level writable, business-independent project-independent layer and a lower-level global storage read-only layer into a `node_modules` directory. When a user program writes or modifies a project's `node_modules`, the changes are saved in the top-level independent layer using copy-on-write technology, keeping the lower layer read-only. A separate overlay image is mounted on each project's `node_modules`, formed by merging the upper-level project-independent and writable virtual `node_modules` directory (i.e., the top-level directory) with the lower-level daemon process unit (i.e., the lower-level FUSE-implemented read-only original `node_modules` directory). When a program writes to `node_modules`, UnionFS copies the changes to the upper-level folder without affecting the lower-level directory. This ensures that modifications to `node_modules` in different projects do not affect each other.

[0054] In one embodiment, the application isolation unit is a union file system, which includes a merged node_modules virtual layer. The node_modules virtual layer includes an upper layer and a lower layer. When the current node issues a command to read a target file, if the target file exists in the upper layer, it is read directly; if the target file does not exist in the upper layer, it is read from the lower layer. If the target file is modified or deleted, the virtual layer copies the target file in the lower layer and transfers it to the upper layer to obtain a file copy based on a copy-on-write mechanism. When the file copy is modified, it is modified based on the copy-on-write mechanism. When a user wants to add or modify content to a file in the lower layer, overlayfs first copies a file copy from the lower dir to the upper dir. Subsequent write and modification operations will be performed on the copy-up file in the upper dir, and the original file in the lower dir is hidden.

[0055] The upper layer is the project-independent Upper Dir, and the lower layer is the mirrored Lower Dir.

[0056] In one implementation, considering UnionFS, each project's UnionFS is independent, and when merging image layers, it naturally needs to request the underlying directory. This request contains process information. In other words, we can use UnionFS process information to confirm the directory's origin. Put simply, we only need to add process information as an index to the dependency trees of different projects and submit it to the underlying daemon. The underlying daemon, upon receiving a file-related request, can use the process PID to find the specified dependency tree and generate a virtual directory.

[0057] In one embodiment, the underlying daemon unit includes a FUSE kernel module and a user-space LibFUSE library. The FUSE kernel module establishes a connection with the VFS file system interface, receives requests from VFS, establishes a pipeline through a connection control, and sends the encapsulated request to user space. The user-space LibFUSE library parses the library code of the FUSE packet protocol, executes the corresponding request operation in user space, outputs the result, and returns to kernel space. In its working state, it receives target file read instructions, receives VFS requests and passes them to the object storage LibFUSE, which then passes them to the FUSE daemon process. Based on the dependency structure, it identifies the target file to be read, locates the actual location of the target file, and performs global file storage. LibFUSE implements the main framework of the file system, encapsulates the implemented file system operations, manages mount operations, and communicates with the kernel module through the device / dev / fuse. The FUSE kernel module implements the VFS interface, handling fuse file driver registration, superblock maintenance, dentry management, and inode maintenance. It receives requests and passes them to LibFUSE, which then passes them to the user program's interface for operation. FUSE needs to forward VFS layer requests to the user-space fuseapp for processing before returning to kernel space and sending the result back to the VFS layer. In this embodiment, the underlying daemon process FUSE ensures that when a new user-defined user-space file system is mounted, accessing files within that file system is the same as accessing files in other file systems, guaranteed by VFS. The difference is that access behavior within the FUSE file system is user-defined. See also... Figure 2 As shown, the workflow of FUSE is as follows:

[0058] Taking `open` as an example, the entire call process is as follows:

[0059] 1. A user-space application calls the glibc open interface, triggering the sys_open system call.

[0060] 2. sys_open calls the open method defined in the inode node of fuse.

[0061] 3. An open function in the inode generates a request message and sends the request message to the user-space libfuse via / dev / fuse.

[0062] 4. Libfuse calls the user-defined open method of fuse_application and notifies the kernel of the return value through / dev / fuse.

[0063] 5. The kernel receives the request message, completes the processing, and then sends the result back to the VFS system call result.

[0064] 6. The user-space application receives the return result of `open`. This can be understood as follows: libfuse is a perpetually encapsulated library code used to parse the FUSE packet protocol, serving all user-space file systems; ` / dev / fuse` is used to connect the kernel fuse and the user-space file system; and fusermount is a tool used to mount user-space file systems. The FUSE framework used in this embodiment can utilize the above parts.

[0065] The core of UnionFS used in this embodiment is efficient utilization of disk space. Docker uses UnionFS because any program has dependencies at runtime, whether it's the development language's dependency libraries, various system libraries, operating systems, etc. These libraries may differ on different systems, or some may be missing. To ensure consistency during container runtime, Docker integrates and packages the dependent operating systems and various library dependencies together, i.e., an image. Then, when the container starts, this image serves as its root directory, i.e., the root file system (rootfs). This ensures that all dependency calls of the container process reside in this root directory, thus achieving environment consistency. UnionFS is a lightweight, high-performance hierarchical file system that supports committing changes to the file system as a single action, layering them on top of each other. It also allows different directories to be mounted under the same virtual file system, with the application seeing the final result of the mount. It supports setting read-only, read-write, and whiteout-able permissions for each member directory (similar to Git branches); the file system is hierarchical, and branches with read-only permissions can be logically modified incrementally without affecting the read-only parts. UnionFS typically has two uses: one is to mount multiple disks to the same directory, and the other, more commonly used, is to combine a read-only branch with a writeable branch. Union file systems are the technical foundation for implementing Docker images.

[0066] See Figure 4 As shown, based on the same concept, this embodiment also provides a front-end module management method based on a user-space file system, including:

[0067] S1: Initialize the application isolation unit and the underlying daemon process unit, obtain the module information corresponding to each project, and call the operation instructions of the application isolation unit to create the isolation layer between modules in the project;

[0068] S2: Receive the creation operation instruction of the isolation layer, execute the creation of the isolation layer, input the corresponding module information, and return the process ID of the isolation layer;

[0069] S3: Generate a virtualization module directory based on the isolation layer process ID, that is, decompress the original project package to an archive package, parse the virtualization module directory to obtain the dependency structure, and directly map the target file entry to the archive package according to the dependency structure, so as to bypass the IO time consumption generated during the decompression of each module, and mount the virtualization module directory;

[0070] The virtualization module directory is configured as an upper-layer writable mode and an lower-layer read-only mode.

[0071] Furthermore, it also includes: S4: providing a shared underlying storage space to each unit, indexing the archive package according to the module name and version number through the application isolation unit, and then returning it to different business projects for use.

[0072] Based on the same concept, the present invention also provides a front-end module management system based on a user-space file system, comprising:

[0073] The server and multiple clients connected to the server;

[0074] Each of the aforementioned clients runs a front-end module manager based on a user-space file system as described in the embodiments of the present invention;

[0075] The server runs a module library.

[0076] In some embodiments of this application, an electronic device is also provided. This electronic device includes a memory and a processor, wherein the memory stores a processing program, and the processor executes the processing program according to instructions. When the processor executes the processing program, the front-end module management method based on the user-space file system described in the foregoing embodiments is implemented.

[0077] In some embodiments of this application, a readable storage medium is also provided. This readable storage medium can be a non-volatile readable storage medium or a volatile readable storage medium. The readable storage medium stores instructions that, when executed on a computer, cause an electronic device containing this readable storage medium to perform the aforementioned front-end module management method based on a user-space file system.

[0078] It is understood that, for the aforementioned front-end module management methods based on user-space file systems, if all are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part 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 of the various embodiments of this invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0079] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0080] The program code for executing the technical solutions disclosed in this application can be written in any combination of one or more programming languages. These programming languages ​​include object-oriented programming languages—such as Java and C++—and conventional procedural programming languages—such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0081] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A front-end module manager based on a user-space file system, characterized in that, include: The outer control unit is used to initialize the application isolation unit and the underlying daemon process unit, obtain the corresponding preset module information under each project, and call the operation instructions of the application isolation unit to create the isolation layer between modules in the project. An application isolation unit is used to receive the creation operation instruction of the isolation layer, execute the creation of the isolation layer, generate the process ID of the isolation layer, and isolate the underlying storage when the user performs a write operation to prevent pollution of the underlying storage. The application isolation unit is a union file system, which includes a merged node_modules virtual layer. The node_modules virtual layer includes an upper layer and an lower layer. When the current node issues an instruction to read a target file, if the target file exists in the upper layer, the target file is read directly; if the target file does not exist in the upper layer, the target file is read from the lower layer. If the target file is modified or deleted, the virtual layer copies the target file in the lower layer and transmits it to the upper layer to obtain a file copy based on the copy-on-write mechanism. When the file copy is modified, the file copy is modified based on the copy-on-write mechanism. The upper layer is the project-independent layer Upper Dir, and the lower layer is the mirror layer Lower Dir. The underlying daemon process unit is used to receive the preset module information and generate a virtualization module directory according to the isolation layer process ID. That is, the original project package is decompressed into an archive package, the virtualization module directory is parsed to obtain the dependency structure, and the target file entry is directly mapped to the archive package according to the dependency structure to bypass the IO time consumption generated during the decompression of each module, and the virtualization module directory is mounted. The virtualization module directory is generated by merging the application isolation unit and the underlying daemon process unit. The module file content under the virtualization module directory is directly read and returned from the tar archive based on the file size and offset data.

2. The front-end module manager based on a user-space file system as described in claim 1, characterized in that, It also includes a global storage unit, which provides a shared underlying storage space to each unit. The application isolation unit indexes the archive package according to the module name and version number of the preset module, and then returns it to different business projects for use.

3. The front-end module manager based on a user-space file system as described in claim 1, characterized in that, The application isolation unit is set as an upper-level union file system to isolate module files. The union file system merges the top-level writable project-independent layer and the bottom-level global storage read-only layer into the node_modules directory. When the user program writes or modifies the project node_modules, it saves the changes in the project-independent layer based on copy-on-write technology, keeping the global storage read-only layer read-only.

4. The front-end module manager based on a user-space file system as described in claim 1, characterized in that, The underlying daemon unit includes a FUSE kernel module and a user-space LibFUSE library. The FUSE kernel module is used to establish a connection with the VFS file system interface, receive requests from VFS, establish a pipeline through the connection control, and send the encapsulated request to user space. The user-space LibFUSE library is used to parse the library code of the FUSE packet protocol, execute the corresponding request operation in user space, output the result, and return to kernel space. In the working state, it receives the target file read instruction, receives the VFS request and passes it to the object storage LibFUSE, which then passes it to the FUSE daemon. Based on the dependency structure, it identifies the target file to be read, locates the actual location of the target file, and stores the global file.

5. A front-end module management method based on a user-space file system, characterized in that, The application of the front-end module manager based on the user-space file system as described in any one of claims 1-4 includes: Initialize the application isolation unit and the underlying daemon process unit, obtain the corresponding preset module information under each project, and call the operation instructions of the application isolation unit to create the isolation layer between modules in the project. The system receives the creation operation instruction of the isolation layer, executes the creation of the isolation layer, generates the process ID of the isolation layer, and isolates the underlying storage when the user performs a write operation to prevent pollution of the underlying storage. The system receives the preset module information and generates a virtualization module directory based on the isolation layer process ID. This involves decompressing the original project package into an archive package, parsing the virtualization module directory to obtain the dependency structure, and mapping the target file entry directly into the archive package based on the dependency structure. This bypasses the IO time consumption generated during the decompression of each module and mounts the virtualization module directory. The virtualization module directory is generated by merging the application isolation unit and the underlying daemon process unit.

6. A front-end module management system based on a user-space file system, characterized in that, include: The server and multiple clients connected to the server; Each of the aforementioned clients runs a front-end module manager based on a user-space file system as described in any one of claims 1-4; The server runs a module library.

7. An electronic device, characterized in that, include: The memory is used to store the processing program; A processor, which, when executing the processing program, implements the front-end module management method based on a user-space file system as described in claim 5.

8. A readable storage medium, characterized in that, The readable storage medium stores a processing program, which, when executed by a processor, implements the front-end module management method based on a user-space file system as described in claim 5.

Images