一种前端组件处理方法、装置、设备及介质

技术领域

本申请涉及计算机技术领域，特别涉及一种前端组件处理方法、装置、设备、介质。

背景技术

目前，在组件打包和发布时，通常是将一套组件库中所有的组件打包在一起。这就导致了只要其中一个组件需求修改发布，就要所有组件一起发布，因为在对其中一个组件进行修改时，可能会影响到其他组件，所以需要整个组件包一起重新发布，提高了组件之间的耦合性和每次发版的风险，也增大了组件修改的工作量。

发明内容

有鉴于此，本申请的目的在于提供一种前端组件处理方法、装置、设备、介质，能够对同一套组件库中的各个组件进行单独打包，降低组件之间的耦合性和组件版本发布的风险，以及降低组件修改时的工作量。其具体方案如下：

第一方面，本申请公开了一种前端组件处理方法，包括：

获取前端组件数据，并将所述前端组件数据存到预设路径下；

在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档；

基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中。

可选地，所述在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档，包括：

在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包；

在所述预设路径对应的根路径下执行第一预设命令中的npm run compile命令，以便生成各个所述资源包对应的组件文档。

可选地，所述在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包，包括：

在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的esm包和ejs包。

可选地，所述在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包之前，还包括：

在所述预设路径对应的根路径下执行第一预设命令中的node./scripts/clean-old-build.js命令，以便将所述根路径下所有子目录下在获取到所述前端组件数据之前存储的历史前端组件数据删除。

可选地，所述在所述预设路径对应的根路径下执行第一预设命令中的npm runcompile命令，以便生成各个所述资源包对应的组件文档之后，还包括：

在所述预设路径对应的根路径下执行第一预设命令中的node./scripts/build-wind-up.js命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件的测试文件和示例文件删除。

可选地，所述基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中，包括：

基于lerna publish命令将各个所述资源包和所述组件文档发布到私有npm仓库。

第二方面，本申请公开了一种前端组件处理装置，包括：

数据获取模块，用于获取前端组件数据，并将所述前端组件数据存到预设路径下；

组件打包模块，用于在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档；

组件发布模块，用于基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中。

可选地，所述组件打包模块，用于：

在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包；

在所述预设路径对应的根路径下执行第一预设命令中的npm run compile命令，以便生成各个所述资源包对应的组件文档。

第三方面，本申请公开了一种电子设备，包括：

存储器和处理器；

其中，所述存储器，用于存储计算机程序；

所述处理器，用于执行所述计算机程序，以实现前述公开的前端组件处理方法。

第四方面，本申请公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述公开的前端组件处理方法。

可见，本申请先获取前端组件数据，并将所述前端组件数据存到预设路径下，然后还需要在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档，并基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中。由此可见，本申请中是在保存了前端组件数据的预设路径的根路径下执行第一预设命令，以将所述根路径下所以子目录中的各个前端组件单独打包成对应的生产环境的资源包，并生辰各个资源包对应的组件文档，这样能够对同一套组件库中的各个组件进行单独打包，降低组件之间的耦合性和组件版本发布的风险，以及降低组件修改时的工作量。且对组件进行修改之后，只需要更新已修改组件对应的组件文档，不需要更新所有组件对应的组件文档，也进一步减少了组件修改时的工作量。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请公开的一种前端组件处理方法流程图；

图2为本申请公开的一种前端组件处理装置结构示意图；

图3为本申请公开的一种电子设备结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，在组件打包和发布时，通常是将一套组件库中所有的组件打包在一起。这就导致了只要其中一个组件需求修改发布，就要所有组件一起发布，因为在对其中一个组件进行修改时，可能会影响到其他组件，所以需要整个组件包一起重新发布，提高了组件之间的耦合性和每次发版的风险，也增大了组件修改的工作量。有鉴于此，本申请提出了一种前端组件处理方法，能够对同一套组件库中的各个组件进行单独打包，降低组件之间的耦合性和组件版本发布的风险，以及减少组件修改时的工作量。

参见图1所示，本申请实施例公开了一种前端组件处理方法，该方法包括：

步骤S11：获取前端组件数据，并将所述前端组件数据存到预设路径下。

在实际应用中，需要先获取前端组件数据，并将所述前端组件数据存储到预设路径下。也即获取前端开发人员设计的前端组件数据，然后将获取到的前端组件数据保存到预设路径下。

步骤S12：在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档。

将获取到的前端组件数据保存到所述预设路径下之后，还需要在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档。其中，所述第一预设命令可以包括多条命令，也即，所述第一预设命令可以包括两条以及两条以上的命令。

具体的，包括在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档，包括：在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包；在所述预设路径对应的根路径下执行第一预设命令中的npm run compile命令，以便生成各个所述资源包对应的组件文档。其中，生产环境对应的资源包也就是适应不同场景的组件包。

也即，先在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的esm包和ejs包。其中，esm包和ejs包分别适用于不同的场景，例如，浏览器、应用程序等。

然后在所述预设路径对应的根路径下执行第一预设命令中的npm run compile命令，以便生成各个所述资源包对应的组件文档。实际上会执行lerna run compile--stream--no-sort命令，由于前端组件是由lerna搭建而成，会执行package目录下每个项目的npm run compile。会生成所有前端组件的d.ts声明文件，也即生成各个资源包对应的组件文档，这样能方便组件使用者在编辑器中就知道组件的入参及其类型，而不用额外再到别处查阅文档。

在实际应用中，在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包之前，还包括：在所述预设路径对应的根路径下执行第一预设命令中的node./scripts/clean-old-build.js命令，以便将所述根路径下所有子目录下在获取到所述前端组件数据之前存储的历史前端组件数据删除。也即，需要先将所述根路径下所有子目录中本次构建组件之前构建的数据删除，防止上次构建的产物也一起上传至包仓库，多次发布之后，过时产物累加，将会造成组件仓库空间巨大浪费。

相应地，在所述预设路径对应的根路径下执行第一预设命令中的npm runcompile命令，以便生成各个所述资源包对应的组件文档之后，还包括：在所述预设路径对应的根路径下执行第一预设命令中的node./scripts/build-wind-up.js命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件的测试文件和示例文件删除。

步骤S13：基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中。

将各个前端组件分别打包成生产环境对应的资源包并生成对应的组件文档之后，还需要基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中。

具体的，可以基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中，包括：基于lerna publish命令将各个所述资源包和所述组件文档发布到私有npm仓库。可以将资源包打包成压缩版本和对应的组件文档一起发布到组件库中。

实际应用中，前端组件可以不是lerna下搭建，所以所述第一预设命令可以是除了上述的father-build、npm run compile、node./scripts/clean-old-build.js、node./scripts/build-wind-up.js命令以外的其他命令，能够将各个前端组件分别打包成生产环境对应的资源包以及生成对应的组件文档即可，相应的，所述第二预设命令也可以为与所述第一预设命令对应的其他命令。

可见，本申请先获取前端组件数据，并将所述前端组件数据存到预设路径下，然后还需要在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档，并基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中。由此可见，本申请中是在保存了前端组件数据的预设路径的根路径下执行第一预设命令，以将所述根路径下所以子目录中的各个前端组件单独打包成对应的生产环境的资源包，并生辰各个资源包对应的组件文档，这样能够对同一套组件库中的各个组件进行单独打包，降低组件之间的耦合性和组件版本发布的风险，以及减少组件修改时的工作量。且对组件进行修改之后，只需要更新已修改组件对应的组件文档，不需要更新所有组件对应的组件文档，也进一步减少了组件修改时的工作量。

参见图2所示，本申请实施例公开了一种前端组件处理装置，包括：

数据获取模块11，用于获取前端组件数据，并将所述前端组件数据存到预设路径下；

组件打包模块12，用于在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档；

组件发布模块13，用于基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中。

可见，本申请先获取前端组件数据，并将所述前端组件数据存到预设路径下，然后还需要在所述预设路径对应的根路径下执行第一预设命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包并生成各个所述资源包对应的组件文档，并基于第二预设命令将各个所述资源包和所述组件文档发布到预设的组件库中。由此可见，本申请中是在保存了前端组件数据的预设路径的根路径下执行第一预设命令，以将所述根路径下所以子目录中的各个前端组件单独打包成对应的生产环境的资源包，并生辰各个资源包对应的组件文档，这样能够对同一套组件库中的各个组件进行单独打包，降低组件之间的耦合性和组件版本发布的风险，以及减少组件修改时的工作量。且对组件进行修改之后，只需要更新已修改组件对应的组件文档，不需要更新所有组件对应的组件文档，也进一步减少了组件修改时的工作量。

在一些具体的实施过程中，所述组件打包模块12，用于：在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的生产环境的资源包；在所述预设路径对应的根路径下执行第一预设命令中的npm run compile命令，以便生成各个所述资源包对应的组件文档。

在一些具体的实施过程中，所述组件打包模块12，用于：在所述预设路径对应的根路径下执行第一预设命令中的father-build命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件分别打包成对应的esm包和ejs包。

在一些具体的实施过程中，所述组件打包模块12，还用于：在所述预设路径对应的根路径下执行第一预设命令中的node./scripts/clean-old-build.js命令，以便将所述根路径下所有子目录下在获取到所述前端组件数据之前存储的历史前端组件数据删除。

在一些具体的实施过程中，所述组件打包模块12，还用于：在所述预设路径对应的根路径下执行第一预设命令中的node./scripts/build-wind-up.js命令，以便将所述根路径下所有子目录下的所述前端组件数据对应的各个前端组件的测试文件和示例文件删除。

在一些具体的实施过程中，所述组件发布模块13，用于：基于lerna publish命令将各个所述资源包和所述组件文档发布到私有npm仓库。

参见图3所示，为本申请实施例提供的一种电子设备20的结构示意图，该电子设备20可以实现前述实施例中公开的前端组件处理方法步骤。

通常，本实施例中的电子设备20包括：处理器21和存储器22。

其中，处理器21可以包括一个或多个处理核心，比如四核心处理器、八核心处理器等。处理器21可以采用DSP(digital signal processing,数字信号处理)、FPGA(field-programmable gate array,现场可编程们阵列)、PLA(programmable logic array,可编程逻辑阵列)中的至少一种硬件来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(central processing unit,中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以集成有GPU(graphics processing unit,图像处理器)，GPU用于负责显示屏所需要显示的图像的渲染和绘制。一些实施例中，处理器21可以包括AI(artificialintelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器22可以包括一个或多个计算机可读存储介质，计算机可读存储介质可以是非暂态的。存储器22还可以包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器22至少用于存储以下计算机程序221，其中，该计算机程序被处理器21加载并执行之后，能够实现前述任一实施例中公开的前端组件处理方法步骤。

在一些实施例中，电子设备20还可包括有显示屏23、输入输出接口24、通信接口25、传感器26、电源27以及通信总线28。

本技术领域人员可以理解，图3中示出的结构并不构成对电子设备20的限定，可以包括比图示更多或更少的组件。

进一步的，本申请实施例还公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述任一实施例中公开的前端组件处理方法。

其中，关于上述前端组件处理方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或者操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得一系列包含其他要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种前端组件处理方法、装置、设备、介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。