Method, system, device and medium for sharing lightweight component at multiple terminals in intranet

Abstract

The invention relates to the technical field of web platform development, and discloses a method, a system, equipment and a medium for sharing a lightweight component at multiple ends of an intranet, and the method comprises the following steps: creating an independent project as a development platform for carrying out development debugging and packaging on a shared component in the development platform; performing dll dissociation on an npm packet on which a shared component needing to be shared depends to obtain a dynamic link library (DLL) file corresponding to the npm packet and a mapping file for mapping a relationship between the DLL file and the corresponding npm packet; generating a UMD single file component package for the shared component needing to be shared in combination with the mapping file in a UMD packaging mode; respectively placing a dynamic link library (DLL) file and a UMD single file component package in an intranet server; in a project needing to introduce a shared component, cdn loading is performed on a dynamic link library (DLL) file, and a UMD single file component package is applied in combination with an importScript asynchronous loading mechanism. Through DLL dependent dissociation and UMD packaging, the size of a component package is reduced, and the loading speed is increased.

Description

Technical Field

[0001] The present invention relates to the technical field of web platform development, and in particular to a method, system, device and medium for sharing lightweight components on multiple terminals in an intranet. Background Art

[0002] Current front-end development architectures generally employ a multi-project model with separate platforms, tenants, and desktops. During implementation, independent projects often require reuse of functional modules (including common business components, standardized UI components, and unified interaction logic). To reduce code redundancy, improve development efficiency, and ensure consistency across multiple platforms, existing technologies typically utilize the npm dependency management model for component sharing. This involves packaging common components into npm packages, publishing them to a public npm registry server after version review, and then installing dependencies within each project using the npm install command.

[0003] Analysis of defects in existing technologies: 1. The release process is inefficient and version updates are significantly delayed: a. The release of dependent packages requires multiple steps, including development environment packaging, manual review, and version release. This results in new features and fixes taking several hours to days to take effect, which cannot meet the real-time update requirements in agile development scenarios.

[0004] b. There is a lack of a grayscale release mechanism for version iteration, and forced full updates can easily lead to uncontrollable risks.

[0005] 2. Insufficient automation of dependency management: Multiple projects need to perform manual version number upgrades and dependency reinstallation operations separately. There is no automated update mechanism linked to the continuous integration (CI / CD) system, which poses the risk of human error and version fragmentation.

[0006] 3. Barriers to collaboration between internal and external network environments: In the intranet deployment scenario, dependency package updates must be downloaded from the external network environment and then transferred twice, which complicates the deployment process and causes version synchronization lags in the network isolation environment, violating the DevSecOps security development principles.

[0007] 4. Dependency tree redundancy leads to decreased build efficiency: If public components rely heavily on third-party npm modules (such as fully importing a UI framework), the product package size will grow exponentially, significantly affecting the cold start performance of the web application and the build speed of the continuous delivery pipeline. Summary of the Invention

[0008] The present invention provides a method, system, device and medium for sharing lightweight components among multiple terminals in an intranet to solve the above problems.

[0009] The present invention is achieved through the following technical solutions: A method for sharing lightweight components across multiple terminals in an intranet, comprising: Creating an independent project as a development platform for developing, debugging, and packaging shared components within the development platform; Extract the DLL from the npm package that the shared component needs to be shared depends on in the development platform to obtain the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between the dynamic link library DLL file and the corresponding npm package; In the development platform, the shared components that need to be shared are packaged in a UMD manner and combined with a mapping file to generate a lightweight UMD single-file component package; Placing the dynamic link library DLL file and the UMD single-file component package corresponding to the shared component in the intranet server respectively; In a project that needs to introduce shared components, the dynamic link library DLL file is loaded using cdn, and the UMD single-file component package is applied in combination with the importScript asynchronous loading mechanism.

[0010] As an optimization, the specific method for creating independent projects is to use CLI scaffolding tools to create standardized code projects and configure a unified development environment and build tool chain.

[0011] As an optimization, the specific process of extracting the DLL from the npm package that the shared component that needs to be shared depends on, obtaining the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between all the dynamic link library DLL files and the corresponding npm package is as follows: Configure the input npm package array: Use the package name of the npm package that the shared component depends on as the configuration item to set the parameters of the input file library; Intermediate plug-in processing: Use dependency mapping to generate the plug-in new webpack.DllPlugin() as one of the plug-in parameters of the webpack plug-in configuration item array webpack.plugins to generate a mapping file; Output dll file and mapping file: Set the name of the output file in the webpack output instruction configuration item. The output file is the dynamic link library DLL file and mapping file corresponding to the npm package that the shared component depends on.

[0012] As an optimization, the specific process of generating a lightweight UMD single-file component package for the shared components that need to be shared by combining the mapping file with the UMD packaging method is as follows: Form a JSON object with the name and path of the shared component to be packaged as a parameter of the webpack input file collection; Added js / css compilation and compression plug-in to parse the js and css codes in the Json object of the shared component before packaging; Set new webpack.DllReferencePlugin({manifest}) as one of the plugins in the webpack plugin configuration array, where {manifest} is the name of the mapping file; Set the parameter value of webpack output type to umd; Set the parameter value of the webpack output file name to [name].umd.js, where umd.js represents a JavaScript single-file component package with a UMD file type, and [name] represents the file name of the output UMD single-file component package.

[0013] As an optimization, the specific process of applying the UMD single-file component package in combination with the importScript asynchronous loading mechanism is as follows: Use the importScript method in the Vue tripartite dependency plug-in runtime-import, pass in the shared component umd server address to be used as the url parameter, and the plug-in runtime-import downloads the UMD single-file component package corresponding to the shared component and renders it to the page as a Vue component.

[0014] As an optimization, projects that need to introduce shared components include various ones on the platform side, tenant side, and desktop side.

[0015] The present invention also discloses a device for sharing lightweight components among multiple terminals in an intranet, which is used to execute the aforementioned method for sharing lightweight components among multiple terminals in an intranet, comprising: A platform creation module, used to create an independent project as a development platform for developing, debugging and packaging shared components within the development platform; A dll extraction module is used to extract the dll of the npm package that the shared component that needs to be shared depends on in the development platform, and obtain the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between all the dynamic link library DLL files and the corresponding npm packages; A packaging module, configured to generate a lightweight UMD single-file component package for the shared components that need to be shared in the development platform by combining the UMD packaging method with the mapping file; A deployment module, configured to place the dynamic link library DLL file and the single-file component package corresponding to the shared component in an intranet server respectively; The loading module is used to load the dynamic link library DLL file through CDN in a project that needs to introduce shared components, and apply the UMD single-file component package in combination with the importScript asynchronous loading mechanism.

[0016] As an optimization, the dll extraction module includes: The npm package input unit is used to set the parameters of the input file library using the package name of the npm package that the shared component depends on as a configuration item; The output configuration unit is used to set the name of the output file in the webpack output instruction configuration item. The output file is the dynamic link library DLL file corresponding to the npm package that the shared component depends on; The mapping file generation unit is used to generate a plug-in new webpack.DllPlugin() using dependency mapping as one of the plug-in parameters of the webpack plug-in configuration item array webpack.plugins to generate a mapping file.

[0017] The present invention also discloses an electronic device, comprising at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a method for sharing lightweight components on multiple terminals in an intranet as described above.

[0018] The present invention also discloses a storage medium storing a computer program, which, when executed by a processor, implements the aforementioned method for sharing lightweight components among multiple terminals in an intranet.

[0019] Compared with the prior art, the present invention has the following advantages and beneficial effects: a. Performance Optimization: Through DLL dependency extraction and UMD packaging, component package size is significantly reduced, loading speed is improved, and application operation fluency is enhanced. Due to the extraction of DLL dependencies, UMD component files are small, generally single JavaScript files of around 10-80k, with loading speeds generally between 30-60ms. After component code stripping, the code packaging in the project is naturally optimized.

[0020] b. Convenient deployment: Unified development, packaging, and deployment processes simplify operational steps and reduce the risk of human error. From development, packaging, to deployment, a pre-built development platform and pre-written packaging scripts are used. This standardization and uniformity facilitate deployment and enable timely fixes and updates.

[0021] c. Environmental compatibility: Supports seamless switching between internal and external network environments, eliminating external network dependencies and meeting deployment requirements in network isolation scenarios. Because UMD components and engineering projects are deployed on the same server, there are no internal and external network restrictions, and resources can be accessed without network restrictions.

[0022] d. Efficient Iteration: Component updates are automatically synchronized with front-end projects in real time, eliminating the need for manual upgrades across multiple projects and improving iteration efficiency. Because UMD components are deployed within an intranet environment, each iteration requires only replacing server resources. After a browser refresh request, component resources are updated. Unlike npm, there's no need to upload remote images, review them, or open the code project to update dependencies. This invention allows for seamless updates by simply updating server component resources, eliminating the need for such tedious operations.

[0023] e. Share DLL dependencies with the project and bring performance optimization to the project. Because DLL is a js packaged with some third-party dependencies, the project does not need to download and install the third-party dependencies for the second time. It can share the compressed dependency DLL loaded by CDN with the UMD component, which speeds up the packaging of the original main project and reduces the packaging size.

[0024] f. Single component files can not only be shared by different code projects (platform, tenant, and user), but can also be used as small components in the microcode development platform. Due to their small size and simple customization, they are ideal for drag-and-drop assembly of homepages, workbenches, and other components on the microcode platform. Not only does the component size qualify as microcode, but it is also very convenient and practical in the rendering layer, which only needs to reference the same shared component to render.

[0025] g. Greatly reduces development costs and improves development efficiency. This is because upgrades, requirement modifications, and bug fixes for a shared component can be coded in one place and implemented in multiple places, eliminating the need to modify each project one by one.

[0026] h. Easy to get started, with low technical requirements. The built platform can be a common framework in the industry such as Vue / React / Angular. Component developers only need to develop according to the common component development method, without the cost of secondary learning. After development, it can be compiled directly through unified packaging. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The drawings described herein are used to provide a further understanding of the embodiments of the present invention, constitute a part of this application, and do not constitute a limitation of the embodiments of the present invention. In the drawings: Figure 1 A flowchart of a method for sharing lightweight components across multiple terminals in an intranet according to the present invention; Figure 2 A diagram showing the project path of the shared component relative to the packaged file. DETAILED DESCRIPTION

[0028] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with examples and drawings. The exemplary embodiments of the present invention and their descriptions are only used to explain the present invention and are not intended to limit the present invention.

[0029] The technical problems to be solved by the present invention are as follows: The present invention aims to solve the following technical problems existing in the prior art front-end component sharing solution based on npm dependency management: a. Inefficient release process: The release of dependent packages requires multi-step review, which leads to delayed version updates and fails to meet agile development requirements.

[0030] b. Complex iteration management: Multiple projects need to manually upgrade dependent versions separately. There is a lack of an automated update mechanism, which poses the risk of version fragmentation.

[0031] c. Difficulty in coordinating internal and external networks: Intranet deployment scenarios rely on external network updates, which complicates the deployment process and leads to version synchronization lags in network isolation environments.

[0032] d. Component size redundancy: Public components are deeply dependent on third-party npm modules, resulting in excessively large product packages, affecting build efficiency and application performance.

[0033] The present invention solves the above problems through the following steps: a. Build a unified development platform: Create an independent project as a development, debugging, and packaging platform for shared components to achieve standardized management of the component development environment.

[0034] b. Dependency optimization: By customizing the webpack script, the third-party npm packages that the component depends on are extracted into dynamic link library (DLL) files, significantly reducing the size of the component package.

[0035] c. Standardized packaging output: Use webpack's UMD (Universal Module Definition) packaging method and combine DLL files to generate a lightweight JavaScript single-file component package.

[0036] Automated Deployment and Updates: Develop delivery scripts based on Node.js to enable on-demand component packaging and automated deployment. Introducing DLL dependencies through CDN and combining the importScript asynchronous loading mechanism supports real-time updates and version management within the intranet environment.

[0037] Next, the technology of the present invention is introduced through a specific solution.

[0038] This embodiment 1 provides a method for sharing lightweight components on multiple terminals in an intranet, such as Figure 1 Shown, including: S1. Create an independent project as a development platform for developing, debugging and packaging shared components within the development platform.

[0039] In some embodiments, a CLI scaffolding tool is used to create a standardized code project, configuring a unified development environment and build toolchain. (This step involves building a code project specifically for developing shared components. The CLI scaffolding tool is a quick command line creation and preparatory step.)

[0040] This step is to build a unified development platform: create an independent project as a development, debugging, and packaging platform for shared components to achieve standardized management of the component development environment.

[0041] S2. Extract the dll from the npm package that the shared component that needs to be shared depends on in the development platform to obtain the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between the dynamic link library DLL file and the corresponding npm package.

[0042] A dynamic link library (DLL) file (dll file for short) can contain multiple npm packages. You can create multiple dll files by categorizing them according to the npm package type and configuring multiple groups in the webpack configuration entry.

[0043] Write a DLL extraction script (DLL is the js file compressed from the npm package that the shared component depends on, hereinafter collectively referred to as dll file).

[0044] Specifically, the specific process of extracting the DLL from the npm package that the shared component that needs to be shared depends on, obtaining the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between all the dynamic link library DLL files and the corresponding npm packages is as follows: S2.1. Configure the input npm package array: Use the package names of the npm packages that the shared components depend on as configuration items to set the parameters of the input file library; For example, the input file library is webpack.entry.libs, and the parameters in webpack.entry.libs are the npm packages that the shared components that need to be packaged depend on.

[0045] entry is the input, libs is the name of a custom npm package collection, for example, the libs collection can contain three npm dependencies: axios, vue, and vuex. libs: [axios, vue, vuex].

[0046] webpack.entry.libs receives an array libs, and multiple npm dependency packages are packaged into a dll file. The output dll file is a dynamic link library. The library name of the dynamic link library is the npm package name, and the value of the dynamic link library is the compressed corresponding code (that is, the code after the npm dependency package is compiled and compressed).

[0047] webpack.entry is an object that can specify multiple map sets A / B / C (which determines how many dll.js files are packaged). For example, map set A is named libs. libs is an array that records the names of npm package dependencies, telling the webpack tool that these npm packages need to be packaged into a dll.js.

[0048] S2.2. Intermediate plug-in processing: Use dependency mapping to generate the plug-in new webpack.DllPlugin() as one of the plug-in parameters in the webpack plug-in configuration item array webpack.plugins to generate a mapping file (i.e., json mapping).

[0049] This step is used to set the intermediate plug-in that generates libs-manifest.json (a mapping file of the array libs).

[0050] Because the npm package is packaged into dll.js (i.e., dll file), the mainfest.json (mapping file) is used to record the npm packages (i.e., npm dependent packages) in the dll file, the versions of the dependent packages, and other information. The mapping file maps to the content in dll.js. The intermediate plug-in is used to generate the mapping file. The specific packaging and compression code is compiled by webpack internally. The plug-in configuration is as follows: For example: new webpack.DllPlugin({ / / The name of the file when the manifest.json file describing the dynamic link library is output path: path.join(dllPath, '[name]-manifest.json'), / / The value of this field is the value of the name field in the output manifest.json file name: '[name]_dll', / / to be consistent with output.library / / Close the process context: process.cwd() }) That is to say, the intermediate plug-in processing mainly includes setting the file name of the manifest.json file (i.e., the mapping file) when it is output (i.e., the file name and path of the output manifest.json file), setting the value of the name field in the output manifest.json file, setting the conditions for closing the process, etc. The name in mainfest.json is the name of the npm package after packaging, that is, the name of the dll.js set previously, which is convenient for generating mainfest.json (mapping file, that is, the generated mapping file depends on the dll.js with the name you specified). One dll file is paired with one mainfest.json.

[0051] S2.3. Output dll file and mapping file: Set the name of the output file in the webpack output instruction configuration item. The output file is the dynamic link library DLL file and mapping file corresponding to the npm package that the shared component depends on.

[0052] In the webpack output directive (webpack.output.filename) configuration item, you can write a string or an array of strings as the name of the output file.

[0053] This step involves dependency optimization: by customizing the webpack script, the third-party npm packages that the shared components depend on are extracted into dynamic link library (DLL) files, significantly reducing the size of the component package.

[0054] Finally, combined with the above important configurations, one or more npm packages that the shared component depends on are packaged and output as a libs.dll.js file (the dll file corresponding to the array libs) and a libs-manifest.json dependency mapping (that is, the mapping file corresponding to the array libs, which mainly maps which npm dependencies are contained in libs.dll.js). One dll file is equipped with one mapping file (manifest.json).

[0055] The command webpack.output.filename will output both the dll file and the mapping file (mainfest.json), a total of two files. In the above specific configuration, path is the output location and name of mainfest.json, and name is the name of the dll.

[0056] S3. In the development platform, the shared components that need to be shared are packaged in a UMD manner and combined with a mapping file to generate a lightweight UMD single-file component package.

[0057] This step is the standardized packaging of shared components.

[0058] Write the UMD packaging script (UMD is a single JavaScript file generated for each shared component). The specific process is as follows: S3.1. Create a JSON object with the name and path of the shared component to be packaged as a parameter of the webpack input file collection webpack.entry; This path is the project path of the shared component relative to the package file, for example Figure 2 An example of a path for two shared components: { NotificationAnnouncement: '. / src / umd-component-dev / eoss / h5 / notification-announcement / index.js', WaitH5: '. / src / umd-component-dev / eoss / h5 / wait-h5 / index.js' } Map the shared component name to the location of the component code (i.e. the path of the shared component), for example, NotificationAnnouncement: '. / src / umd-component-dev / eoss / h5 / notification-announcement / index.js' The key of the JSON object is the file name, and the value is the file path (i.e., umd-component-dev / eoss / h5 / notification-announcement.index.js). Through the node script, the user selects the component to be packaged, generates a new JSON object, and packages it.

[0059] The code for json object configuration is as follows: [ { "label": "coos", "value": "coos", "children": { "label": "PC", "value": "PC", "children": { "label": "More Applications", "value": "ApplicationGateway", "src": ". / src / umd-component-dev / coos / pc / application-gateway / index.js" }, { "label": "My Applications", "value": "MyApp", "src": ". / src / umd-component-dev / coos / pc / my-app / index.js" }, { "label": "Navigation Bar", "value": "TenantGuide", "src": ". / src / umd-component-dev / coos / pc / tenant-guide / index.js" }, { "label": "iframe Plugin", "value": "WebDisplay", "src": ". / src / umd-component-dev / coos / pc / web-display / index.js" }, { "label": "Carousel", "value": "SwiperImage", "src": ". / src / umd-component-dev / coos / pc / swiper-image / index.js" } { "label": "Application Management", "value": "ApplicationManage", "src": ". / src / umd-component-dev / coos / pc / application-manage / index.js" }, ]. For example, MyApp is the key of the JSON object, which is the name of one of the shared components.

[0060] The following is the process of the node script selecting the packaged components and regenerating json.

[0061] yarn run v1.22.21 $ node build / umd-build-config / interactive.js build:umd ? Please select the packaged patient test environment ? Please select the project where the packaged imd is located coos ? Please select the packaged umd type (H5 / PC) H5 ? Please select the packaged umd file name all More Application Apply >Carousel Notification component (Notice) BulletinBoard Form entry (CustomFormFillH5) (Move up and down to reveal more choices)

[0062] JSON objects are primarily generated interactively through scripting. A fixed mapping JSON file is created for all shared components (not the previously mentioned mapping file; this JSON file is a manually configured JSON object that maps the file location of each shared component, making it easier to find shared components during packaging). This mapping JSON file is then presented to the user via the node command. The user then dynamically generates a JSON file for the shared components they select. This JSON file is the JSON object to be packaged.

[0063] In this step, after specifying the shared components to be packaged through the previous node script, the json mapping (i.e. json object) corresponding to the shared components to be packaged is passed in as a parameter.

[0064] S3.2. Add a JS / CSS compilation and compression plug-in to parse the JS and CSS code in the JSON object of the shared component before packaging. A shared component file contains JS and CSS parts, which need to be processed, compiled, and compressed separately. The process of compressing the code is the packaging process.

[0065] S3.3. Set newwebpack.DllReferencePlugin ({manifest}) as one of the plug-ins in the webpack plug-in configuration array webpack.plugins, where {manifest} is the file name of the mapping file. Pass the mapping file (for example, the mapping file libs-manifest.json of the array libs) into the plug-in (webpack.DllReferencePlugin) as a parameter of the manifest (that is, the mapping file is used as a parameter of the plug-in, and the plug-in will ignore the corresponding npm package when packaging after receiving it), thereby informing the webpack packaging tool that the dependencies in the mapping file libs-manifest.json have been processed, so that the dependencies mentioned in the mapping file can be ignored when packaging the UMD single-file component package.

[0066] Here, the dependency is the third-party npm package, which is the dll.js (dll file) packaged earlier. In fact, the third-party npm package has been separately packaged into dll.js (dll file), and the mapping file corresponding to the dll file is inserted through webpack.DllReferencePlugin. In this way, the shared components that rely on these npm packages individually do not need to be packaged repeatedly.

[0067] In other words, when the new webpack.DefinePlugin plugin is used, the mainfest.json (mapping file) generated by packaging the DLL file is passed to the new webpack.DefinePlugin plugin. This tells webpack to package the component files (shared components). If the shared component depends on the dependencies mapped in the mainfest, the code of the NPM package corresponding to the shared component will be ignored and packaged into umd.js. In this way, all component files share the NPM dependency package corresponding to the DLL file, reducing the need to package each component file with its own dependencies (i.e., separate NPM packages), thus reducing the size of the component. A DLL file can contain multiple NPM packages, and shared components can use one or more of them.

[0068] This plug-in is officially provided by webpack. It ignores dependencies and will not be included in umd.js (UMD single-file component package) during packaging. Umd.js will become a lightweight component. Otherwise, a dependency may be several MB and the effect will not be achieved.

[0069] The present invention utilizes two sets of configurations to link dll and umd together, and invents a lightweight shared dependency component concept.

[0070] S3.4. Set the parameter value of webpack output type webpack.output.libraryTarget to umd; S3.5. Set the webpack output file name to [name].umd.js. umd.js represents a single-file component package with the UMD file type, and [name] represents the name of the output UMD single-file component package. This step outputs the name of the UMD single-file component package.

[0071] S4. Place the dynamic link library DLL file and the UMD single-file component package corresponding to the shared component in the intranet server respectively.

[0072] For example, you can place the libs.dll.js file (the DLL file in the libs array) generated by S2 on the server as a dependency compressed package required by the shared component. (The DLL file is the compressed JS file that S2 extracts from the npm dependency package extracted from the shared component.)

[0073] At the same time, place the [name].umd.js file (UMD single-file component package) packaged from S3 on the server. (This component is a single JavaScript file, also known as a UMD file.) S5. In a project that needs to introduce shared components, the dynamic link library DLL file is loaded using CDN, and the UMD single-file component package is applied in combination with the importScript asynchronous loading mechanism.

[0074] The dll file is a single js file, which simply compresses the npm dependency packages into a single file. The umd single-file component package refers to the component js file. All component js files no longer contain dependencies in the dll file, significantly reducing the component size. All component js files share the dll file loaded via CDN.

[0075] In projects that require shared components (specifically, platform, tenant, and desktop), load the DLL file. This step loads the compressed dependency files required by the shared component into the project (platform, tenant, and desktop) so that the shared component can be used. (Because S2 processes the dependencies into compressed JS files, their size is reduced. Loading via CDN reduces the project's package size. Because the project deployment and the DLL file are placed on the same server, the DLL file can be loaded regardless of the internal or external network.)

[0076] Specifically, use the importScript method in the Vue tripartite dependency plug-in runtime-import to pass in the shared component umd server that the project needs to use ( Figure 1 The runtime-import plugin uses the URL of the shared component (the intranet server in the source code) as a parameter. It downloads the UMD single-file component package (umd.js file) corresponding to the shared component and renders it as a Vue component on the page. This enables on-demand loading and dynamic rendering of UMD components, supporting component-level hot updates and version management.

[0077] The umd single-file component package is essentially a js function at the rendering level. The runtime-import plug-in can synchronously load remote js. The js contains the rendering function, which can be rendered directly after loading.

[0078] This page is used by the platform, tenant, and desktop clients. For example, the tenant client renders a UMD single-file component as a component on the page, allowing users to drag and drop it to create a page for preview. The configured component layout is saved and rendered and presented to the user in the same way on the user client. (The page can be configured with multiple UMD components, so it can also be used for microcode platform development.)

[0079] In summary, the present invention has the following effects: 1. DLL-based dependency optimization mechanism Use webpack's DllPlugin plug-in to extract the third-party npm packages that the component depends on into independent dynamic link library (DLL) files, significantly reducing the size of the component package.

[0080] Generates a dependency mapping file (manifest.json) to implement dynamic loading and version management of runtime dependencies.

[0081] 2. UMD standardized packaging solution Use webpack's UMD packaging configuration and combine it with DLL files to package shared components into a single JavaScript file that complies with the UMD specification.

[0082] Achieve seamless compatibility of components in different environments (browsers, Node.js, etc.).

[0083] 3. DLL+UMD dual-mode collaborative architecture Innovatively combines DLL dependency optimization with UMD standardized packaging to build a lightweight, highly compatible component sharing solution.

[0084] Asynchronously load DLL resources through CDN, and use importScript to implement on-demand loading and dynamic rendering of components.

[0085] 4. Full-process engineering management Establish an independent shared component development project to achieve integrated management of component development, debugging, packaging, and deployment.

[0086] Provide standardized engineering templates and configurations to ensure consistency in multi-team collaboration.

[0087] 5. Automated deployment and iteration mechanism Develop interactive deployment scripts based on Node.js, supporting rapid packaging and deployment of specified environments and components.

[0088] Achieve one-click release of component updates and automatic synchronization of multiple projects to improve iteration efficiency.

[0089] 1. This invention is not only applicable to component development on low-code platforms, but can also be widely used in the following scenarios: a. Component sharing under micro-frontend architecture b. Development of UI component libraries for cross-platform applications (such as Electron and React Native) c. Modular development of large-scale enterprise applications 2. The technical solution of the present invention has high scalability and can be adapted to different application scenarios in the following ways: a. Replace the packaging tool (such as using Rollup instead of webpack) b. Adjust dependency optimization strategies (e.g., using Tree Shaking instead of DLL) c. Expand deployment methods (such as supporting Docker container deployment) 1. The core innovation of this invention lies in the DLL+UMD dual-mode collaborative architecture. This design has high technical barriers and it is difficult to achieve the same effect through simple replacement.

[0090] 2. For different application scenarios, the specific implementation methods can be adaptively adjusted while keeping the core architecture unchanged, such as: a. Use Vite instead of webpack as the build tool; b. Use ES Module instead of UMD specification; c. Introduce WebAssembly to optimize performance critical paths.

[0091] Example 2 discloses a device for sharing lightweight components across multiple terminals in an intranet, which is used to execute the method for sharing lightweight components across multiple terminals in an intranet described in Example 1, including: A platform creation module, used to create an independent project as a development platform for developing, debugging and packaging shared components within the development platform; A dll extraction module is used to extract the dll of the npm package that the shared component that needs to be shared depends on in the development platform, and obtain the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between the dynamic link library DLL file and the corresponding npm package; A packaging module, configured to generate a lightweight UMD single-file component package for the shared components that need to be shared in the development platform by combining the UMD packaging method with the mapping file; A deployment module, configured to place the dynamic link library DLL file and the UMD single-file component package corresponding to the shared component in an intranet server respectively; The loading module is used to load the dynamic link library DLL file through CDN in a project that needs to introduce shared components, and apply the UMD single-file component package in combination with the importScript asynchronous loading mechanism.

[0092] As an optimization, the dll extraction module includes: The npm package input unit is used to set the parameters of the input file library using the package name of the npm package that the shared component depends on as a configuration item; The output configuration unit is used to set the name of the output file in the webpack output instruction configuration item. The output file is the dynamic link library DLL file corresponding to the npm package that the shared component depends on; The mapping file generation unit is used to generate a plug-in new webpack.DllPlugin() using dependency mapping as one of the plug-in parameters of the webpack plug-in configuration item array webpack.plugins to generate a mapping file.

[0093] Example 3 discloses an electronic device, comprising at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a method for sharing lightweight components on multiple terminals in an intranet as described in Example 1.

[0094] Example 4 discloses a storage medium storing a computer program. When the computer program is executed by a processor, the method for sharing lightweight components on multiple terminals in an intranet described in Example 1 is implemented.

[0095] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for sharing lightweight components on multiple terminals in an intranet, characterized in that: include: Create an independent project as a development platform for developing, debugging, and packaging shared components; Extract the DLL from the npm package that the shared component needs to be shared depends on in the development platform to obtain the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between the dynamic link library DLL file and the corresponding npm package; In the development platform, the shared components that need to be shared are packaged in a UMD manner and combined with a mapping file to generate a lightweight UMD single-file component package; Placing the dynamic link library DLL file and the UMD single-file component package corresponding to the shared component in the intranet server respectively; In a project that needs to introduce shared components, the dynamic link library DLL file is loaded using cdn, and the UMD single-file component package is applied in combination with the importScript asynchronous loading mechanism.

2. A method for sharing lightweight components on multiple terminals in an intranet according to claim 1, characterized in that: The specific method for creating an independent project is to use the CLI scaffolding tool to create a standardized code project and configure a unified development environment and build tool chain.

3. A method for sharing lightweight components on multiple terminals in an intranet according to claim 1, characterized in that: The specific process of extracting the DLL from the npm package that the shared component needs to be shared depends on, obtaining the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between all the dynamic link library DLL files and the corresponding npm packages is as follows: Configure the input npm package array: Use the package name of the npm package that the shared component depends on as the configuration item to set the parameters of the input file library; Intermediate plug-in processing: Use dependency mapping to generate the plug-in new webpack.DllPlugin() as one of the plug-in parameters of the webpack plug-in configuration item array webpack.plugins to generate a mapping file; Output dll file and mapping file: Set the name of the output file in the webpack output instruction configuration item. The output file is the dynamic link library DLL file and mapping file corresponding to the npm package that the shared component depends on.

4. A method for sharing lightweight components across multiple terminals in an intranet according to claim 3, characterized in that: The specific process of generating a lightweight UMD single-file component package for the shared component that needs to be shared by combining the mapping file with the UMD packaging method is as follows: Form a JSON object with the name and path of the shared component to be packaged as a parameter of the webpack input file collection; Added js / css compilation and compression plug-in to parse the js and css codes in the Json object of the shared component before packaging; Set new webpack.DllReferencePlugin({manifest}) as one of the plugins in the webpack plugin configuration array, where {manifest} is the name of the mapping file; Set the parameter value of webpack output type to umd; Set the parameter value of the webpack output file name to [name].umd.js, where umd.js represents a JavaScript single-file component package with a UMD file type, and [name] represents the file name of the output UMD single-file component package.

5. The method for sharing lightweight components among multiple terminals in an intranet according to claim 1, characterized in that: The specific process of applying the UMD single-file component package in combination with the importScript asynchronous loading mechanism is as follows: Use the importScript method in the Vue tripartite dependency plug-in runtime-import, pass in the shared component umd server address to be used as the url parameter, and the plug-in runtime-import downloads the UMD single-file component package corresponding to the shared component and renders it to the page as a Vue component.

6. A method for sharing lightweight components on multiple terminals in an intranet according to claim 1, characterized in that: Projects that need to introduce shared components include various types of projects on the platform side, tenant side, and desktop side.

7. A system for sharing lightweight components on multiple terminals in an intranet, used to execute a method for sharing lightweight components on multiple terminals in an intranet according to any one of claims 1 to 6, characterized in that: include: The platform creation module is used to create independent projects as a development platform for shared components for development, debugging, and packaging; A dll extraction module is used to extract the dll of the npm package that the shared component that needs to be shared depends on in the development platform, and obtain the dynamic link library DLL file corresponding to the npm package and a mapping file for mapping the relationship between the dynamic link library DLL file and the corresponding npm package; A packaging module, configured to generate a lightweight UMD single-file component package for the shared components that need to be shared in the development platform by combining the UMD packaging method with the mapping file; A deployment module, configured to place the dynamic link library DLL file and the UMD single-file component package corresponding to the shared component in an intranet server respectively; The loading module is used to load the dynamic link library DLL file through CDN in a project that needs to introduce shared components, and apply the UMD single-file component package in combination with the importScript asynchronous loading mechanism.

8. A system for sharing lightweight components across multiple terminals in an intranet according to claim 7, characterized in that: The dll extraction module includes: The npm package input unit is used to set the parameters of the input file library using the package name of the npm package that the shared component depends on as a configuration item; The output configuration unit is used to set the name of the output file in the webpack output instruction configuration item. The output file is the dynamic link library DLL file corresponding to the npm package that the shared component depends on; The mapping file generation unit is used to generate a plug-in new webpack.DllPlugin() using dependency mapping as one of the plug-in parameters of the webpack plug-in configuration item array webpack.plugins to generate a mapping file.

9. An electronic device, characterized in that: It includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute a method for sharing lightweight components on multiple terminals in an intranet as described in any one of claims 1 to 6.

10. A storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for sharing lightweight components among multiple terminals in an intranet according to any one of claims 1 to 6 is implemented.

Images