插件依赖包的更新方法、装置、电子设备及介质与流程

1.本发明涉及软件开发技术领域，尤其是涉及一种插件依赖包的更新方法、装置、电子设备及介质。


背景技术：

2.随着业务地不断壮大，前端通常采用拆包方式对代码进行管理与维护，但拆包后会把之前项目中的插件(plugin)拆分到不同的仓库中，同时将一些基础仓库依赖包(比如：@/ekuaibao/vendor-common)也跟随着plugin拆分到对应的仓库中。此时，如果要更新plugin依赖的基础仓库，则需要将所有依赖这个仓库的plugin都更新一遍，更新完后再将plugin重新打包合并到主项目上，整个过程中工作量很大，耗费时间较长，工作效率比较低。


技术实现要素：

3.有鉴于此，本发明的目的在于提供一种插件依赖包的更新方法、装置、电子设备及介质，以减少了插件依赖包更新的工作量和时间，提升了工作效率。
4.为了实现上述目的，本发明实施例采用的技术方案如下：
5.第一方面，本发明实施例提供了一种插件依赖包的更新方法，包括：获取主项目的插件信息，并基于插件信息确定待更新插件；获取待更新插件的依赖包文件，并基于用户提交的配置信息更新依赖包文件；将更新后的依赖包文件发送至版本控制系统，并将更新后的依赖包文件打包得到更新后的插件。
6.在一种实施方式中，获取待更新插件的依赖包文件之前，该方法还包括：基于用户提交的配置信息创建待更新插件的分支，并将待更新插件转换至分支。
7.在一种实施方式中，获取待更新插件的依赖包文件，并基于用户提交的配置信息更新依赖包文件，包括：从存储库中获取待更新插件的依赖包文件，并将依赖包文件进行转换得到待更新插件的原始配置信息；基于用户提交的配置信息修改待更新插件的原始配置信息，得到更新后的依赖包文件，并将更新后的依赖包文件存储至存储库中。
8.在一种实施方式中，将更新后的依赖包文件打包得到更新后的插件，包括：基于更新后的依赖包文件创建待更新插件的标签，并基于标签触发持续集成工具，将更新后的依赖包文件打包得到更新后的插件。
9.在一种实施方式中，将更新后的依赖包文件打包得到更新后的插件之后，该方法还包括：将更新后的插件批量合并至主项目。
10.在一种实施方式中，将更新后的插件批量合并至主项目，包括：获取更新后的插件信息；创建用于存储更新后的插件信息的隐藏文件；基于隐藏文件，获取更新后的插件的依赖包文件和同步机制信息；将更新后的插件的依赖包文件和同步机制信息上传至远程仓库，并删除隐藏文件。
11.第二方面，本发明实施例提供了一种插件依赖包的更新装置，包括：插件获取模
块，用于获取主项目的插件信息，并基于插件信息确定待更新插件；文件更新模块，用于获取待更新插件的依赖包文件，并基于用户提交的配置信息更新依赖包文件；插件更新模块，用于将更新后的依赖包文件发送至版本控制系统，并将更新后的依赖包文件打包得到更新后的插件。
12.在一种实施方式中，该装置还包括：分支创建模块，用于基于用户提交的配置信息创建待更新插件的分支，并将待更新插件转换至分支。
13.第三方面，本发明实施例提供了一种电子设备，包括处理器和存储器，存储器存储有能够被处理器执行的计算机可执行指令，处理器执行计算机可执行指令以实现上述第一方面提供的任一项的方法的步骤。
14.第四方面，本发明实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器运行时执行上述第一方面提供的任一项的方法的步骤。
15.本发明实施例带来了以下有益效果：
16.本发明实施例提供的上述插件依赖包的更新方法、装置、电子设备及介质，首先，获取主项目的插件信息，并基于插件信息确定待更新插件；然后，获取待更新插件的依赖包文件，并基于用户提交的配置信息更新依赖包文件；最后，将更新后的依赖包文件发送至版本控制系统，并将更新后的依赖包文件打包得到更新后的插件。上述方法能够根据用户提交的配置信息自动更新待更新插件的依赖包文件，并进行自动提交，将更新后的依赖包文件发送至版本控制系统进行打包和自动部署，无需开发人员手动对代码进行修改，减少了插件依赖包更新的工作量和时间，降低了人工成本，提升了工作效率。
17.本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
18.为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
19.为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
20.图1为本发明实施例提供的一种插件依赖包的更新方法的流程图；
21.图2为本发明实施例提供的另一种插件依赖包的更新方法的流程图；
22.图3为本发明实施例提供的一种插件依赖包的更新装置的结构示意图；
23.图4为本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
24.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是
全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
25.目前，如果要更新plugin依赖的基础仓库，则需要开发人员手动修改代码，将所有依赖这个仓库的plugin都更新一遍，更新完后再将plugin重新打包合并到主项目上，整个过程中工作量很大，耗费时间较长，工作效率比较低。
26.基于此，本发明实施例提供的一种插件依赖包的更新方法、装置、电子设备及介质，可以减少插件依赖包更新的工作量和时间，提升工作效率。
27.为便于对本实施例进行理解，首先对本发明实施例所公开的一种插件依赖包的更新方法进行详细介绍，该方法可以由电子设备执行，诸如智能手机、电脑、平板电脑等。本发明实施例中可以通过前端实现插件依赖的更新，前端采用react进行页面渲染及ui(控件)交互，前端可以为用户提供可视化的操作界面，服务端采用node.js提供接口，以及采用docker进行打包部署、启动服务。参见图1所示一种插件依赖包的更新方法的流程图，示意出该方法主要包括以下步骤s101至步骤s103：
28.步骤s101：获取主项目的插件信息，并基于插件信息确定待更新插件。
29.在一种实施方式中，可以通过服务端提供的接口获取主项目的全部插件信息(即plugin信息)，并根据实际需求确定待更新插件。在具体实施时，前端可以为用户提供可视化的操作界面，获取到的全部plugin信息可以显示在操作界面中，用户可以基于需求选择待更新插件。
30.步骤s102：获取待更新插件的依赖包文件，并基于用户提交的配置信息更新依赖包文件。
31.在一种实施方式中，用户可以利用前端提供的操作页面输入配置信息，配置信息至少包括：分支名称、插件版本号、包名称、包版本、提交描述等。考虑到，一个项目通常包含大量的代码，为了在更新插件依赖包的过程中不会影响到主项目的其他功能，本发明实施例中，在确定待更新插件之后，还包括：基于用户提交的配置信息创建待更新插件的分支，并将待更新插件转换至分支。
32.在具体实施时，用户提交配置信息后，调用服务端接口，服务端通过gitapi创建分支，如果分支存在，则对分支进行修改，如果分支不存在，则创建相反用当前分支。
33.进一步，获取待更新插件的依赖包文件(即package.json文件)，根据用户提交的配置信息对package.json文件进行修改，得到更新后的package.json文件。
34.步骤s103：将更新后的依赖包文件发送至版本控制系统，并将更新后的依赖包文件打包得到更新后的插件。
35.在一种实施方式中，在得到更新后的package.json文件之后，可以将更新后的package.json文件通过接口下发到版本控制系统(即git)，并将更新后的package.json文件打包，得到更新后的插件。
36.本发明实施例提供的上述插件依赖包的更新方法，能够根据用户提交的配置信息自动更新待更新插件的依赖包文件，并进行自动提交，将更新后的依赖包文件发送至版本控制系统进行打包和自动部署，无需开发人员手动对代码进行修改，减少了插件依赖包更新的工作量和时间，降低了人工成本，提升了工作效率。
37.在一种实施方式中，对于前述步骤s102，即在获取待更新插件的依赖包文件，并基
于用户提交的配置信息更新依赖包文件时，可以采用包括但不限于以下方式：首先，从存储库中获取待更新插件的依赖包文件，并将依赖包文件进行转换得到待更新插件的原始配置信息；然后，基于用户提交的配置信息修改待更新插件的原始配置信息，得到更新后的依赖包文件，并将更新后的依赖包文件存储至存储库中。
38.在具体实施时，从存储库中通过/git/getfilescontext读取读取待更新插件的package.json文件，采用base64.decode将读取到的文件进行转换得到原始配置信息；然后，根据用户输入的配置信息来更新package.json文件，将原始配置信息修改为最新版本号(即用户输入的包版本)，升级plugin版本，得到更新后的依赖包文件；最后，通过/git/updatefilescontext更新存储库中的现有依赖包文件，即将更新后的依赖包文件进行存储。
39.在一种实施方式中，对于前述步骤s103，即在将更新后的依赖包文件打包得到更新后的插件时，可以采用包括但不限于以下方式：基于更新后的依赖包文件创建待更新插件的标签，并基于标签触发持续集成工具，将更新后的依赖包文件打包得到更新后的插件。
40.在具体实施时，可以采用更新后的最新版本号创建标签(即tag)，并利用tag触发持续集成工具(即gitlab-ci)，以实现更新后的依赖包文件的自动打包，打包成功的plugin可以存储到store里，方便后续使用。
41.在一种实施方式中，在将更新后的依赖包文件打包得到更新后的插件之后，上述方法还包括：将更新后的插件批量合并至主项目。
42.具体的，可以采用包括但不限于以下方式进行插件合并：首先，获取更新后的插件信息；然后，创建用于存储更新后的插件信息的隐藏文件；接着。基于隐藏文件，获取更新后的插件的依赖包文件和同步机制信息；最后，将更新后的插件的依赖包文件和同步机制信息上传至远程仓库，并删除隐藏文件。
43.在具体实施时，可以将打包好的plugin批量合并到主项目，首先，在store里获取更新后的plugin信息，点击提交后，可以在本地采用node的fs模块创建plugin的隐藏文件到电脑的根目录(隐藏文件用来存储package.json和package-lock.json文件)；然后，采用execsync操作命令，切换到根目录运行npm i，获取最新的package文件和lock文件(即依赖包文件和同步机制信息)；最后，将组织好的配置通过/git/commits提交到git，并采用node的fs模块删除隐藏文件。
44.本发明实施例提供的上述方法中，采用可视化界面来操作plugin批量自动更新依赖包，从新建分支、修改文件、删除分支、自动提交、自动部署等一系列流程，无需人工干预，提升了工作效率，降低了人工成本。
45.为了便于理解，本发明实施例还提供了另一种插件依赖包的更新方法，参见图2所示，主要包括以下步骤1至步骤5：
46.步骤1：通过接口下发获取所有plugin信息。
47.步骤2：创建分支。
48.具体的，用户通过操作界面输入配置信息，点击提交后调用服务端接口，服务端通过gitapi创建分支。
49.步骤3：从存储库中读取package.json文件，根据用户输入的配置信息更新package.json文件，并将更新好的package.json文件通过接口下发提交到git上。
50.具体的，可以从存储库中通过/git/getfilescontext读取package.json文件，读取出来的文件采用base64.decode进行转换，并将转换好的配置信息修改为最新版本号，然后通过/git/updatefilescontext更新存储库的现有文件。
51.步骤4：创建tag自动触发gitlab-ci配置，实现自动打包。
52.具体的，采用最新的版本号创建tag来触发gitlab-ci实现自动打包，并将打包成功的plugin存储到store。
53.步骤5：将打包好的plugin批量合并到主项目。
54.具体的，首先从store里获取plugin信息，并在本地采用node的fs模块创建个隐藏文件，然后采用execsync操作命令切换到跟目录运行npm i，获取最新lock文件和package.json文件，最后组织好的配置通过/git/commits提交到git，并采用node的fs模块删除隐藏文件。
55.本发明实施例提供的上述方法，与现有的人工操作相比，不需要开发人员打开编辑器修改代码，可以提升工作效率，降低了人工成本，同时避免了手动更新出错的问题，降低了研发人员的心理负担。
56.对于前述插件依赖包的更新方法，本发明实施例还提供了一种插件依赖包的更新装置，参见图3所示的一种插件依赖包的更新装置的结构示意图，示意出该装置主要包括以下部分：
57.插件获取模块301，用于获取主项目的插件信息，并基于插件信息确定待更新插件；
58.文件更新模块302，用于获取待更新插件的依赖包文件，并基于用户提交的配置信息更新依赖包文件；
59.插件更新模块303，用于将更新后的依赖包文件发送至版本控制系统，并将更新后的依赖包文件打包得到更新后的插件。
60.本发明实施例提供的上述插件依赖包的更新装置，能够根据用户提交的配置信息自动更新待更新插件的依赖包文件，并进行自动提交，将更新后的依赖包文件发送至版本控制系统进行打包和自动部署，无需开发人员手动对代码进行修改，减少了插件依赖包更新的工作量和时间，降低了人工成本，提升了工作效率。
61.在一种实施方式中，上述装置还包括：分支创建模块，用于基于用户提交的配置信息创建待更新插件的分支，并将待更新插件转换至分支。
62.在一种实施方式中，上述文件更新模块302进一步还用于：从存储库中获取待更新插件的依赖包文件，并将依赖包文件进行转换得到待更新插件的原始配置信息；基于用户提交的配置信息修改待更新插件的原始配置信息，得到更新后的依赖包文件，并将更新后的依赖包文件存储至存储库中。
63.在一种实施方式中，上述插件更新模块303进一步还用于：基于更新后的依赖包文件创建待更新插件的标签，并基于标签触发持续集成工具，将更新后的依赖包文件打包得到更新后的插件。
64.在一种实施方式中，上述装置还包括合并模块，用于：将更新后的插件批量合并至主项目。
65.在一种实施方式中，上述合并模块进一步还用于：获取更新后的插件信息；创建用
于存储更新后的插件信息的隐藏文件；基于隐藏文件，获取更新后的插件的依赖包文件和同步机制信息；将更新后的插件的依赖包文件和同步机制信息上传至远程仓库，并删除隐藏文件。
66.本发明实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。
67.本发明实施例还提供了一种电子设备，具体的，该电子设备包括处理器和存储装置；存储装置上存储有计算机程序，计算机程序在被处理器运行时执行如上实施方式的任一项所述的方法。
68.图4为本发明实施例提供的一种电子设备的结构示意图，该电子设备100包括：处理器40，存储器41，总线42和通信接口43，所述处理器40、通信接口43和存储器41通过总线42连接；处理器40用于执行存储器41中存储的可执行模块，例如计算机程序。
69.其中，存储器41可能包含高速随机存取存储器(ram，random acc ess memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口43(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。
70.总线42可以是isa总线、pci总线或eisa总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
71.其中，存储器41用于存储程序，所述处理器40在接收到执行指令后，执行所述程序，前述本发明实施例任一实施例揭示的流过程定义的装置所执行的方法可以应用于处理器40中，或者由处理器40实现。
72.处理器40可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器40中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器40可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等；还可以是数字信号处理器(digital signal processing，简称dsp)、专用集成电路(application specific integrated circuit，简称asic)、现成可编程门阵列(field-programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器41，处理器40读取存储器41中的信息，结合其硬件完成上述方法的步骤。
73.本发明实施例所提供的可读存储介质的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见前述方法实施例，在此不再赘述。
74.所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说
对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
75.最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

技术特征：
1.一种插件依赖包的更新方法，其特征在于，包括：获取主项目的插件信息，并基于所述插件信息确定待更新插件；获取所述待更新插件的依赖包文件，并基于用户提交的配置信息更新所述依赖包文件；将更新后的所述依赖包文件发送至版本控制系统，并将更新后的所述依赖包文件打包得到更新后的插件。2.根据权利要求1所述的方法，其特征在于，获取所述待更新插件的依赖包文件之前，所述方法还包括：基于用户提交的配置信息创建所述待更新插件的分支，并将所述待更新插件转换至所述分支。3.根据权利要求1所述的方法，其特征在于，获取所述待更新插件的依赖包文件，并基于用户提交的配置信息更新所述依赖包文件，包括：从存储库中获取所述待更新插件的依赖包文件，并将所述依赖包文件进行转换得到所述待更新插件的原始配置信息；基于所述用户提交的配置信息修改所述待更新插件的原始配置信息，得到更新后的所述依赖包文件，并将更新后的所述依赖包文件存储至所述存储库中。4.根据权利要求1所述的方法，其特征在于，将更新后的所述依赖包文件打包得到更新后的插件，包括：基于更新后的所述依赖包文件创建所述待更新插件的标签，并基于所述标签触发持续集成工具，将更新后的所述依赖包文件打包得到更新后的插件。5.根据权利要求1所述的方法，其特征在于，将更新后的所述依赖包文件打包得到更新后的插件之后，所述方法还包括：将更新后的插件批量合并至所述主项目。6.根据权利要求5所述的方法，其特征在于，将更新后的插件批量合并至所述主项目，包括：获取更新后的插件信息；创建用于存储所述更新后的插件信息的隐藏文件；基于所述隐藏文件，获取所述更新后的插件的依赖包文件和同步机制信息；将所述更新后的插件的依赖包文件和同步机制信息上传至远程仓库，并删除所述隐藏文件。7.一种插件依赖包的更新装置，其特征在于，包括：插件获取模块，用于获取主项目的插件信息，并基于所述插件信息确定待更新插件；文件更新模块，用于获取所述待更新插件的依赖包文件，并基于用户提交的配置信息更新所述依赖包文件；插件更新模块，用于将更新后的所述依赖包文件发送至版本控制系统，并将更新后的所述依赖包文件打包得到更新后的插件。8.根据权利要求7所述的装置，其特征在于，所述装置还包括：分支创建模块，用于基于用户提交的配置信息创建所述待更新插件的分支，并将所述待更新插件转换至所述分支。9.一种电子设备，其特征在于，包括处理器和存储器，所述存储器存储有能够被所述处
理器执行的计算机可执行指令，所述处理器执行所述计算机可执行指令以实现权利要求1至6任一项所述的方法的步骤。10.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器运行时执行上述权利要求1至6任一项所述的方法的步骤。

技术总结
本发明提供了一种插件依赖包的更新方法、装置、电子设备及介质，包括：获取主项目的插件信息，并基于插件信息确定待更新插件；获取待更新插件的依赖包文件，并基于用户提交的配置信息更新依赖包文件；将更新后的依赖包文件发送至版本控制系统，并将更新后的依赖包文件打包得到更新后的插件。本发明减少了插件依赖包更新的工作量和时间，提升了工作效率。提升了工作效率。提升了工作效率。


技术研发人员：刘磊
受保护的技术使用者：北京合思信息技术有限公司
技术研发日：2023.07.17
技术公布日：2023/10/15