本地打包方法和装置与流程

1.本发明涉及计算机技术领域，尤其涉及一种本地打包方法和装置。


背景技术：

2.在开发大型前端项目时，通常会遇到业务工程(project)依赖关系复杂的情况。例如，业务工程1同时依赖于库文件1、库文件2和库文件3，库文件2又依赖于库文件1，库文件3又依赖于库文件1和库文件2。
3.与此同时，如果业务工程依赖的是自己研发的依赖库(简称“自研依赖库”)，那么业务工程和自研依赖库还需要维护不同的git分支版本。在最终上线时，业务工程是基于master分支的代码编译并打包的，且在编译过程中所安装的自研依赖包都是发布到私有服务器上的正式包。但是，在开发和测试过程中，由于相关代码还未通过验证，自研依赖库是没有办法发布正式包的，这时候可通过手动本地打包的方式安装对应分支的自研依赖库，进而实现对业务工程的本地打包。
4.在实现本发明过程中，发明人发现现有的手动本地打包方式至少存在如下问题：第一、依赖关系越复杂，手动本地打包越容易出错；第二、依赖关系越复杂，需要手动执行的步骤越多，耗时越长。开发人员需要一直关注到每两个步骤的衔接过程，占用大量开发人员时间。整个手动本地打包过程消耗时间太长。


技术实现要素：

5.有鉴于此，本发明提供一种本地打包方法和装置，能够降低开发和测试过程中业务工程的打包出错概率，提高本地打包的执行效率。
6.为实现上述目的，根据本发明的一个方面，提供了一种本地打包方法。
7.本发明的本地打包方法包括：获取配置文件并将其加载至内存中；所述配置文件用于描述业务工程和依赖项之间的依赖关系；遍历所述配置文件中业务工程依赖的一级依赖项集合；针对所述一级依赖项集合中的每个一级依赖项，在确认需要构建所述一级依赖项对应的包文件的情况下，构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存；拉取业务工程在目标分支上的最新代码；根据所述业务工程在目标分支上的最新代码、以及所述业务工程的各个一级依赖项对应的包文件，构建业务工程对应的包文件。
8.可选地，所述方法还包括：在所述构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存之前，拉取所述一级依赖项在目标分支上的最新代码；在所述一级依赖项在目标分支上的最新代码有更新，或者缓存中不存在所述一级依赖项对应的包文件的情况下，确认需要构建所述一级依赖项对应的包文件。
9.可选地，所述方法还包括：在所述一级依赖项在目标分支上的最新代码没有更新，且缓存中已存在所述一级依赖项对应的包文件的情况下，确认无需构建所述一级依赖项对应的包文件。
10.可选地，所述构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存包括：遍历所述配置文件中所述一级依赖项依赖的二级依赖项集合；针对所述二级依赖项集合中的每个二级依赖项，将缓存中的所述二级依赖项对应的包文件存至所述一级依赖项目录下的对应文件夹中；根据所述一级依赖项在目标分支上的最新代码、以及所述一级依赖项依赖的各个二级依赖项的包文件，对所述一级依赖项进行打包，以得到所述一级依赖项对应的包文件，然后将所述一级依赖项对应的包文件进行缓存。
11.可选地，所述构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存还包括：在所述一级依赖项不存在依赖的二级依赖项的情况下，根据所述一级依赖项在目标分支上的最新代码，对所述一级依赖项进行打包，以得到所述一级依赖项对应的包文件，然后将所述一级依赖项对应的包文件进行缓存。
12.可选地，所述方法还包括：在所述将所述一级依赖项对应的包文件进行缓存的步骤之前，通过抽包命令对所述一级依赖项对应的包文件进行抽包，然后对抽包得到的压缩包进行解压缩。
13.可选地，所述配置文件中的一级依赖项为自研一级依赖项，且所述配置文件中的二级依赖项为自研二级依赖项；所述方法还包括：在所述根据所述业务工程在目标分支上的最新代码、以及所述业务工程的各个一级依赖项对应的包文件，构建业务工程对应的包文件的步骤之前，安装所述业务工程依赖的第三方一级依赖项；在所述根据所述一级依赖项在目标分支上的最新代码、以及所述一级依赖项依赖的各个二级依赖项，对所述一级依赖项进行打包的步骤之前，安装所述一级依赖项依赖的第三方二级依赖项。
14.为实现上述目的，根据本发明的另一方面，提供了一种本地打包装置。
15.本发明的本地打包装置包括：获取模块，用于获取配置文件并将其加载至内存中；所述配置文件用于描述业务工程和依赖项之间的依赖关系；第一打包模块，用于遍历所述配置文件中业务工程依赖的一级依赖项集合；第一打包模块，还用于针对所述一级依赖项集合中的每个一级依赖项，在确认需要构建所述一级依赖项对应的包文件的情况下，构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存；第二打包模块，用于拉取业务工程在目标分支上的最新代码；第二打包模块，还用于根据所述业务工程在目标分支上的最新代码、以及所述业务工程的各个一级依赖项对应的包文件，构建业务工程对应的包文件。
16.为实现上述目的，根据本发明的再一个方面，提供了一种电子设备。
17.本发明的电子设备，包括：一个或多个处理器；以及，存储装置，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明的本地打包方法。
18.为实现上述目的，根据本发明的又一个方面，提供了一种计算机可读介质。
19.本发明的计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明的本地打包方法。
20.上述发明中的一个实施例具有如下优点或有益效果：通过获取配置文件并将其加载至内存中，遍历所述配置文件中业务工程依赖的一级依赖项集合；针对所述一级依赖项集合中的每个一级依赖项，在确认需要构建所述一级依赖项对应的包文件的情况下，构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存；拉取业务工
程在目标分支上的最新代码，根据所述业务工程在目标分支上的最新代码、以及所述业务工程的各个一级依赖项对应的包文件构建业务工程对应的包文件这些步骤，能够降低开发和测试过程中业务工程的打包出错概率，提高本地打包的执行效率。
21.上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
22.附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
23.图1是根据本发明第一实施例的本地打包方法的主要流程示意图；
24.图2是根据本发明第二实施例的本地打包方法的主要流程示意图；
25.图3是本发明第二实施例中步骤s206的一种可选实施方式示意图；
26.图4是根据本发明第三实施例的本地打包方法的主要流程示意图；
27.图5是根据本发明第四实施例的本地打包装置的主要模块示意图；
28.图6是本发明实施例可以应用于其中的示例性系统架构图；
29.图7是适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。
具体实施方式
30.以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
31.需要指出的是，在不冲突的情况下，本发明中的实施例以及实施例中的特征可以相互组合。
32.在详细介绍本发明的各个实施例之前，首先对本发明实施例涉及的部分技术术语进行说明。
33.业务工程：软件开发中的技术术语，英文可表示为“project”，又可称为“工程”或者“项目”。
34.依赖项：软件开发中的技术术语，又可称为“依赖”、“依赖库”或者“依赖包”。
35.一级依赖项：是指业务工程依赖的库文件。
36.二级依赖项：是指一级依赖项依赖的库文件。
37.自研依赖项：通常为自主研发的依赖项，区别于第三方依赖项。自研依赖项，又可称为“自研依赖”、“自研依赖库”或者“自研依赖包”。
38.图1是根据本发明第一实施例的本地打包方法的主要流程示意图。如图1所示，本发明实施例的本地打包方法包括：
39.步骤s101、获取配置文件并将其加载至内存中。
40.其中，所述配置文件用于描述业务工程和依赖项之间的依赖关系。
41.在一个可选示例中，所述配置文件用于描述业务工程和其所依赖的所有依赖项的依赖关系。例如，业务工程1同时依赖于库文件1、库文件2和库文件3，则可在配置文件中描述业务工程1和其所依赖的库文件1、库文件2和库文件3之间的依赖关系。
42.在另一个可选示例中，所述配置文件用于描述业务工程和其所依赖的所有自研依赖项的依赖关系。例如，业务工程1同时依赖于自研依赖项1、自研依赖项2和第三方依赖项3，则可在配置文件中描述业务工程1和其所依赖的自研依赖项1、自研依赖项2之间的依赖关系。
43.在该步骤中，在本地打包装置被触发后，可先从配置文件所在的文件路径上获取配置文件，并将其加载至内存中。通常，加载至内存中的配置文件为一个json(json是一种轻量级的数据交换格式)数据对象。
44.步骤s102、遍历所述配置文件中业务工程依赖的一级依赖项集合；针对所述一级依赖项集合中的每个一级依赖项，在确认需要构建所述一级依赖项对应的包文件的情况下，构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存。
45.其中，所述一级依赖项集合具体可采用数组形式表示。例如，可采用“config.dependencies数组”表示业务工程依赖的一级依赖项集合，该“config.dependencies数组”具体包括如下三个一级依赖项：库文件1、库文件2、库文件3。在遍历“config.dependencies数组”时，可先针对库文件1判断是否需要构建库文件1对应的包文件，并在确认需要构建库文件1对应的包文件的情况下，构建库文件1对应的包文件并缓存；然后，针对库文件2判断是否需要构建库文件2对应的包文件，并在确认需要构建库文件2对应的包文件的情况下，构建库文件2对应的包文件并缓存；接下来，针对库文件3判断是否需要构建库文件3对应的包文件，并在确认需要构建库文件3对应的包文件的情况下，构建库文件3对应的包文件并缓存。通过在构建一级依赖项对应的包文件后进行缓存，能够大大缩短整个本地打包所需的时间，提高了打包效率。
46.步骤s103、拉取业务工程在目标分支上的最新代码；根据所述业务工程在目标分支上的最新代码、以及所述业务工程的各个一级依赖项对应的包文件，构建业务工程对应的包文件。
47.在该步骤中，可先根据配置文件中业务工程的描述信息拉取业务工程在目标分支上的最新代码。例如，可先根据配置文件中包含的业务工程的名称字段拼接出完整的业务工程路径，并进入该业务工程的根目录；然后，根据配置文件中包含的业务工程的目标分支字段切换到目标分支，并通过诸如git pull的命令拉取目标分支上的最新代码。
48.在得到所述业务工程的各个一级依赖项对应的包文件、以及业务工程在目标分支上的最新代码以后，可先将缓存中的各个一级依赖项对应的包文件拷贝至业务工程目录下的对应文件夹中，然后执行项目打包命令(比如npm run build命令)对业务工程进行打包，以得到业务工程对应的包文件。
49.在本发明实施例中，通过配置文件描述复杂的依赖关系，使得依赖关系的复杂度不会影响到本地打包的难易程度，因此大大降低了打包出错的概率；通过步骤s101至步骤s103能够实现自动本地打包，使得开发人员无需关注打包细节，相比手动本地打包降低了打包出错概率，提高了打包效率。
50.图2是根据本发明第二实施例的本地打包方法的主要流程示意图。如图2所示，本发明实施例的本地打包方法包括：
51.步骤s201、获取配置文件并将其加载至内存中。
52.其中，所述配置文件用于描述业务工程和依赖项之间的依赖关系。
53.在一个可选示例中，所述配置文件用于描述业务工程和其所依赖的所有依赖项的
依赖关系。例如，业务工程1同时依赖于库文件1、库文件2和库文件3，则可在配置文件中描述业务工程1和其所依赖的库文件1、库文件2和库文件3之间的依赖关系。
54.在另一个可选示例中，所述配置文件用于描述业务工程和其所依赖的所有自研依赖项的依赖关系。例如，业务工程1同时依赖于自研依赖项1、自研依赖项2和第三方依赖项3，则可在配置文件中描述业务工程1和其所依赖的自研依赖项1、自研依赖项2之间的依赖关系。
55.在该步骤中，在本地打包装置被触发后，可先从配置文件所在的文件路径上获取配置文件，并将其加载至内存中。通常，加载至内存中的配置文件为一个json(json是一种轻量级的数据交换格式)数据对象。
56.步骤s202、创建缓存目录。
57.其中，所述缓存目录可以为在计算机本地项目空间的根目标中新建的一个文件夹。通过创建缓存目录，便于后续缓存本地打包好的依赖包，比如一级依赖项对应的包文件。
58.步骤s203、判断i是否小于dependencies.length。在判断结果为是的情况下，执行步骤s204；在判断结果为否的情况下，执行步骤s207。
59.其中，i表示一个计数器，其从0开始、每次加1；dependencies表示业务工程依赖的一级依赖项数组；dependencies.length表示一级依赖项数组的长度，即该数组中有多少个一级依赖项。
60.当i小于dependencies.length时，其表示还没有遍历完一级依赖项数组的所有元素；当i大于或等于dependencies.length时，其表示已经遍历完一级依赖项数组的所有元素。
61.步骤s204、拉取业务工程依赖的第i个一级依赖项在目标分支上的最新代码。
62.示例性地，可根据配置文件中第i个一级依赖项的描述信息拉取第i个一级依赖项在目标分支上的最新代码。例如，可先根据配置文件中包含的第i个一级依赖项的名称字段拼接出完整的项目路径，并进入该项目的根目录；然后，根据配置文件中包含的第i个一级依赖项的目标分支字段切换到目标分支，并通过诸如git pull的命令拉取第i个一级依赖项在目标分支上的最新代码。
63.步骤s205、判断是否需要构建一级依赖项对应的包文件。
64.在该步骤中，需要判断第i个一级依赖项是否需要构建其所对应的包文件。示例性地，可根据如下方式判断是否需要构建第i个一级依赖项对应的包文件：判断第i个一级依赖项在目标分支上的最新代码是否有更新，判断缓存目录中是否存在第i个一级依赖项对应的包文件；在第i个一级依赖项在目标分支上的最新代码有更新，或者缓存中不存在第i个一级依赖项对应的包文件的情况下，确认需要构建第i个一级依赖项对应的包文件；在第i个一级依赖项在目标分支上的最新代码没有更新，且缓存中已存在第i个一级依赖项对应的包文件的情况下，确认无需构建第i个一级依赖项对应的包文件。
65.具体实施时，可将此次拉取到的第i个一级依赖项最新代码的提交id(标识)与上一次拉取的第i个一级依赖项代码的提交id(标识)进行对比，如果两者不一致，则可说明第i个一级依赖项的最新代码有更新；如果两者一致，则可说明第i个一级依赖项的最新代码没有更新。此外，在具体实施时，可通过第i个一级依赖项的名称在缓存目录中查找是否存在对应的包文件，如果能查找到对应的包文件，则可说明缓存目录中存在第i个一级依赖项对应的包文件；如果不能查找到对应的包文件，则可说明缓存目录中不存在第i个一级依赖项对应的包文件。
66.进一步，在步骤s205的判断结果为是的情况下，可执行步骤s206；在步骤s205的判断结果为否的情况下，可令i＝i 1(意即使计数器i的值增加1)，然后再次执行步骤s203。
67.步骤s206、构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件存至缓存目录。在步骤s206之后，可令i＝i 1，然后再次执行步骤s203。
68.关于步骤s206具体如何实施，以下将结合图3进行详细说明。
69.步骤s207、拉取业务工程在目标分支上的最新代码。
70.在该步骤中，可根据配置文件中业务工程的描述信息拉取业务工程在目标分支上的最新代码。例如，可先根据配置文件中包含的业务工程的名称字段拼接出完整的业务工程路径，并进入该业务工程的根目录；然后，根据配置文件中包含的业务工程的目标分支字段切换到目标分支，并通过诸如git pull的命令拉取目标分支上的最新代码。
71.步骤s208、根据所述业务工程在目标分支上的最新代码、以及所述业务工程的各个一级依赖项对应的包文件，构建业务工程对应的包文件。
72.在得到所述业务工程的各个一级依赖项对应的包文件、以及业务工程在目标分支上的最新代码以后，可先将缓存目录中的各个一级依赖项对应的包文件拷贝至业务工程目录下的对应文件夹(比如，假设业务工程为project1，则可将各个一级依赖项对应的包文件拷贝至project1目录下的node_modules文件夹)中，然后可执行项目打包命令(比如npm run build命令)对业务工程进行打包，以得到业务工程对应的包文件。
73.在本发明实施例中，通过配置文件描述复杂的依赖关系，使得依赖关系的复杂度不会影响到本地打包的难易程度，因此大大降低了打包出错的概率；进一步，通过图2所示步骤能够实现自动本地打包，使得开发人员无需关注打包细节，相比手动本地打包降低了打包出错概率，提高了打包效率。
74.图3是本发明第二实施例中步骤s206的一种可选实施方式示意图。如图3所示，步骤s206的一种可选实施方式具体包括以下流程：
75.步骤s301、判断配置文件中是否存在一级依赖项依赖的二级依赖项集合。
76.示例性地，可根据第i个一级依赖项的名称构建查询字段，以查询配置文件中是否存在第i个一级依赖项依赖的二级依赖项集合。在判断结果为是的情况下，可执行步骤s302；在判断结果为否的情况下，可执行步骤s305。
77.步骤s302、遍历所述一级依赖项依赖的二级依赖项集合。
78.其中，所述二级依赖项集合具体可采用数组形式表示。例如，假设第i个一级依赖项为库文件3(其可表示为“lib3”)，则可采用“lib3.dependencies数组”表示库文件3所依赖的二级依赖项集合，“lib3.dependencies数组”具体包括如下两个二级依赖项：库文件1(其可表示为“lib1”)、库文件2(其可表示为“lib2”)。
79.步骤s303、针对所述二级依赖项集合中的每个二级依赖项，将缓存中的所述二级依赖项对应的本地包存至所述一级依赖项目录下的对应文件夹中。
80.例如，假设一级依赖项lib3依赖的二级依赖项集合具体包括如下两个二级依赖项：lib1和lib2，则可将缓存中lib1对应的包文件拷贝至lib3目录下的对应文件夹(比如lib3目录下的node_modules文件夹)中，将缓存中lib2对应的包文件拷贝至lib3目录下的对应文件夹(比如lib3目录下的node_modules文件夹)中。
81.进一步，在步骤s303之前，本发明实施例的方法还可包括以下步骤：针对所述二级
依赖项集合中的每个二级依赖项，判断是否需要构建所述二级依赖项的包文件；在确认需要构建所述二级依赖项对应的包文件的情况下，构建所述二级依赖项对应的包文件，并将所述二级依赖项对应的包文件进行缓存。
82.步骤s304、根据一级依赖项在目标分支上的最新代码、以及所述一级依赖项依赖的各个二级依赖项的包文件，对所述一级依赖项进行打包，以得到所述一级依赖项对应的包文件。
83.在通过步骤s303将一级依赖项依赖的各个二级依赖项的包文件存至一级依赖项目录下的对应文件夹后，可通过执行项目打包命令(比如npm run build命令)对所述一级依赖项进行打包，以得到所述一级依赖项对应的包文件。进一步，在步骤s304之后，可执行步骤s306。
84.步骤s305、根据所述一级依赖项在目标分支上的最新代码，对所述一级依赖项进行打包，以得到所述一级依赖项对应的包文件。
85.在该步骤中，可通过执行项目打包命令(比如npm run build命令)对所述一级依赖项进行打包，以得到所述一级依赖项对应的包文件。进一步，在步骤s305之后，可执行步骤s306。
86.步骤s306、通过抽包命令对所述一级依赖项对应的本地包进行抽包，然后对抽包得到的压缩包进行解压缩。
87.示例性地，可通过npm pack这一抽包命令对所述一级依赖项对应的本地包进行抽包。npm pack是一个抽包命令，其作用是把对应的源代码按照一定规则打包成一个后缀为.tgz的压缩包。通过抽包命令对所述一级依赖项对应的本地包进行抽包，能够使本地打包得到的依赖包与npm发布的包的包结构保存一致。
88.步骤s307、将解压缩得到的一级依赖项对应的包文件进行缓存。
89.具体地，可将解压缩得到的一级依赖项对应的包文件存至缓存目录中，并更新缓存包的信息。在该步骤中，所述缓存包的信息可包括最近一次更新的一级依赖项代码的提交id(标识)。具体实施时，可以headcommitid为字段存储在每个缓存包根目录下的package.json文件内。
90.在本发明实施例中，通过以上步骤实现了对一级依赖项的自动本地打包，使得开发人员无需关注打包细节，相比手动进行一级依赖项的本地打包降低了打包出错概率，提高了打包效率，进而有助于提高对业务工程整体的打包效率。
91.图4是根据本发明第三实施例的本地打包方法的主要流程示意图。如图4所示，本发明实施例中的本地打包方法包括：
92.步骤s401、获取配置文件并将其加载至内存中。
93.在本发明实施例中，所述配置文件用于描述业务工程和其所依赖的所有自研依赖项的依赖关系。例如，业务工程1同时依赖于自研依赖项1、自研依赖项2和第三方依赖项3，则可在配置文件中描述业务工程1和其所依赖的自研依赖项1、自研依赖项2之间的依赖关系。
94.在该步骤中，在本地打包装置被触发后，可先从配置文件所在的文件路径上获取配置文件，并将其加载至内存中。通常，加载至内存中的配置文件为一个json(json是一种轻量级的数据交换格式)数据对象。
95.进一步，在步骤s401之前，本发明实施例的方法还可包括以下步骤：在业务工程的
根目录下创建配置文件，以用于描述业务工程和依赖项之间的依赖关系。例如，对于业务工程poject1，可创建名称为build.config.js的配置文件，该配置文件具体包括：
96.[0097][0098]
其中，project表示业务工程的描述信息，dependencies表示项目的自研依赖列表；name表示项目名称(比如，project下的name表示业务工程的名称)；branch表示目标分支名称；lib表示是否为依赖库的标识，当lib的取值为false时表示其为业务工程，当lib的取值为true时表示其为依赖库。
[0099]
进一步，在业务工程的根目录下创建配置文件之后，本发明实施例的方法还可包括以下步骤：创建用于实现本发明的本地打包方法的脚本，配置相关的package.json文件里的bin字段及其他必要设置，让该脚本成为一个可执行文件，然后将其发布为npm包(npm包可理解为在node.js环境下的可执行程序)；之后，进入业务工程的目标分支(比如dev1分支)中，安装该npm包，并在package.json文件中的scripts字段添加相关命令，比如"lc-build":"eld-build
--
config./build.config.js"；之后，通过控制台在业务工程的根目录下执行命令“npm run lc-build”，则会触发图4所示本地打包流程。
[0100]
步骤s402、创建缓存目录。
[0101]
其中，所述缓存目录可以为在计算机本地项目空间的根目录中新建的一个文件夹。通过创建缓存目录，便于后续缓存本地打包好的依赖包，比如一级依赖项对应的包文件。
[0102]
步骤s403、遍历所述配置文件中业务工程依赖的一级依赖项集合；将所述一级依赖项集合中的每个一级依赖项作为入参，调用pullandpulish方法并执行，以得到各个一级
依赖项对应的包文件。
[0103]
其中，所述一级依赖项集合具体可采用数组形式表示。例如，可采用“config.dependencies数组”表示业务工程依赖的一级依赖项集合，“config.dependencies数组”具体包括如下三个一级依赖项：lib1、lib2、lib3。在遍历“config.dependencies数组”时，可先将“config.dependencies数组”中的lib1作为入参调用pullandpulish方法并执行，以得到lib1对应的包文件并缓存，然后将lib2作为入参调用pullandpulish方法并执行，以得到lib2对应的包文件并缓存，再将lib3作为入参调用pullandpulish方法并执行，以得到lib3对应的包文件并缓存。
[0104]
在本发明实施例中，pullandpulish方法用于实现对依赖项进行打包，还用于实现对业务工程进行打包。示例性地，当入参为一级自研依赖项时，pullandpulish方法的处理流程主要包括：步骤a1至步骤a9。
[0105]
步骤a1、根据一级自研依赖项的name(名称)字段拼接出完整的项目路径，并进入此依赖项的根目录。
[0106]
步骤a2、根据一级自研依赖项的branch(目标分支)字段切换到对应的git分支。
[0107]
步骤a3、拉取该一级自研依赖项的最新代码。
[0108]
步骤a4、判断是否需要构建该一级自研依赖项的包文件。
[0109]
如果步骤a4的判断结果为不需要构建，则本次执行结束；如果步骤a4的判断结果为需要构建，则继续进行后面的步骤。
[0110]
步骤a5、安装该一级自研依赖项依赖的二级第三方依赖。
[0111]
步骤a6、遍历该一级自研依赖项依赖的二级自研依赖项数组；针对所述二级自研依赖项数组中的每一个二级自研依赖项，将缓存中与其对应的包文件拷贝到业务工程下面的对应文件夹中。比如，一级自研依赖项为lib1，则将其依赖的二级自研依赖项拷贝至业务工程目录下lib1对应的文件夹中。
[0112]
步骤a7、通过npm run build命令对一级自研依赖项进行打包，以得到一级自研依赖项对应的包文件。
[0113]
步骤a8、通过npm pack抽包命令对一级自研依赖项对应的包文件进行抽包。
[0114]
步骤a9、将抽包得到的压缩包解压缩至缓存目录中，并更新缓存包的信息。
[0115]
步骤s404、获取所述配置文件中的业务工程字段；将业务工程字段作为入参，调用pullandpublish方法并执行，以得到业务工程对应的包文件。
[0116]
示例性地，当入参为业务工程字段时，pullandpulish方法的处理流程主要包括：步骤b1至步骤b6。
[0117]
步骤b1、根据业务工程的name(名称)字段拼接出完整的项目路径，并进入业务工程的根目录。
[0118]
步骤b2、根据业务工程的branch(目标分支)字段切换到对应的git分支。
[0119]
步骤b3、拉取业务工程的最新代码。
[0120]
步骤b4、安装业务工程项依赖的一级第三方依赖。
[0121]
步骤b5、遍历该业务工程依赖的一级自研依赖项数组；针对所述一级自研依赖项数组中的每一个一级自研依赖项，将缓存中与其对应的包文件拷贝到业务工程下面的对应文件夹中。
[0122]
步骤b6、通过npm run build命令对业务工程进行打包，以得到业务工程对应的包文件。
[0123]
在本发明实施例中，通过以上步骤实现了对一级依赖项的自动本地打包，使得开发人员无需关注打包细节，相比手动进行一级依赖项的本地打包降低了打包出错概率，提高了打包效率，进而有助于提高对业务工程整体的打包效率。
[0124]
图5是根据本发明第四实施例的本地打包装置的主要模块示意图。如图5所示，本发明实施例中的本地打包装置500包括：获取模块501、第一打包模块502、第二打包模块503。
[0125]
获取模块501，用于获取配置文件并将其加载至内存中。
[0126]
其中，所述配置文件用于描述业务工程和依赖项之间的依赖关系。
[0127]
在一个可选示例中，所述配置文件用于描述业务工程和其所依赖的所有依赖项的依赖关系。例如，业务工程1同时依赖于库文件1、库文件2和库文件3，则可在配置文件中描述业务工程1和其所依赖的库文件1、库文件2和库文件3之间的依赖关系。
[0128]
在另一个可选示例中，所述配置文件用于描述业务工程和其所依赖的所有自研依赖项的依赖关系。例如，业务工程1同时依赖于自研依赖项1、自研依赖项2和第三方依赖项3，则可在配置文件中描述业务工程1和其所依赖的自研依赖项1、自研依赖项2之间的依赖关系。
[0129]
具体来说，在本地打包装置被触发后，获取模块501可先从配置文件所在的文件路径上获取配置文件，并将其加载至内存中。通常，加载至内存中的配置文件为一个json(json是一种轻量级的数据交换格式)数据对象。
[0130]
第一打包模块502，用于遍历所述配置文件中业务工程依赖的一级依赖项集合；第一打包模块502，还用于针对所述一级依赖项集合中的每个一级依赖项，在确认需要构建所述一级依赖项对应的包文件的情况下，构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存。
[0131]
其中，所述一级依赖项集合具体可采用数组形式表示。例如，可采用“config.dependencies数组”表示业务工程依赖的一级依赖项集合，该“config.dependencies数组”具体包括如下三个一级依赖项：库文件1、库文件2、库文件3。在遍历“config.dependencies数组”时，可先针对库文件1判断是否需要构建库文件1对应的包文件，并在确认需要构建库文件1对应的包文件的情况下，构建库文件1对应的包文件并缓存；然后，针对库文件2判断是否需要构建库文件2对应的包文件，并在确认需要构建库文件2对应的包文件的情况下，构建库文件2对应的包文件并缓存；接下来，针对库文件3判断是否需要构建库文件3对应的包文件，并在确认需要构建库文件3对应的包文件的情况下，构建库文件3对应的包文件并缓存。通过在构建一级依赖项对应的包文件后进行缓存，能够大大缩短整个本地打包所需的时间，提高了打包效率。
[0132]
第二打包模块503，用于拉取业务工程在目标分支上的最新代码；第二打包模块503，还用于根据所述业务工程在目标分支上的最新代码、以及所述业务工程的各个一级依赖项对应的包文件，构建业务工程对应的包文件。
[0133]
示例性地，第二打包模块503可根据配置文件中业务工程的描述信息拉取业务工程在目标分支上的最新代码。例如，第二打包模块503可先根据配置文件中包含的业务工程
的名称字段拼接出完整的业务工程路径，并进入该业务工程的根目录；然后，第二打包模块503根据配置文件中包含的业务工程的目标分支字段切换到目标分支，并通过诸如git pull的命令拉取目标分支上的最新代码。
[0134]
在得到所述业务工程的各个一级依赖项对应的包文件、以及业务工程在目标分支上的最新代码以后，第二打包模块503可先将缓存中的各个一级依赖项对应的包文件拷贝至业务工程目录下的对应文件夹中，然后通过执行项目打包命令(比如npm run build命令)对业务工程进行打包，以得到业务工程对应的包文件。
[0135]
在本发明实施例的装置中，通过配置文件描述复杂的依赖关系，使得依赖关系的复杂度不会影响到本地打包的难易程度，因此大大降低了打包出错的概率；通过获取模块、第一打包模块和第二打包模块能够实现自动本地打包，使得开发人员无需关注打包细节，相比手动本地打包降低了打包出错概率，提高了打包效率。
[0136]
图6示出了可以应用本发明实施例的本地打包方法或本地打包装置的示例性系统架构600。
[0137]
如图6所示，系统架构600可以包括终端设备601、602、603，网络604和服务器605。网络604用以在终端设备601、602、603和服务器605之间提供通信链路的介质。网络604可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
[0138]
用户可以使用终端设备601、602、603通过网络604与服务器605交互，以接收或发送消息等。终端设备601、602、603上可以安装有各种通讯客户端应用，例如软件开发类应用、购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。
[0139]
终端设备601、602、603可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
[0140]
服务器605可以是提供各种服务的服务器，例如对用户利用终端设备601、602、603所发出的本地打包命令提供支持的后台管理服务器。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果反馈给终端设备。
[0141]
需要说明的是，本发明实施例所提供的本地打包方法一般由服务器605执行，相应地，本地打包装置一般设置于服务器605中。
[0142]
应该理解，图6中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
[0143]
下面参考图7，其示出了适于用来实现本发明实施例的电子设备的计算机系统700的结构示意图。图7示出的计算机系统仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
[0144]
如图7所示，计算机系统700包括中央处理单元(cpu)701，其可以根据存储在只读存储器(rom)702中的程序或者从存储部分708加载到随机访问存储器(ram)703中的程序而执行各种适当的动作和处理。在ram 703中，还存储有系统700操作所需的各种程序和数据。cpu 701、rom 702以及ram 703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。
[0145]
以下部件连接至i/o接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；
以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。
[0146]
特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(cpu)701执行时，执行本发明的系统中限定的上述功能。
[0147]
需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。
[0148]
附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
[0149]
描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括获取模块、第一打包模块、第二打包模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，获取模块还可以被描述为“获取配置文件并将其加载至内存中的模块”。
[0150]
作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备执行以下流程：获取配置文件并将其加载至内存中；所述配置文件用于描述业务工程和依赖项之间的依赖关系；遍历所述配置文件中业务工程依赖的一级依赖项集合；针对所述一级依赖项集合中的每个一级依赖项，在确认需要构建所述一级依赖项对应的包文件的情况下，构建所述一级依赖项对应的包文件，并将所述一级依赖项对应的包文件进行缓存；拉取业务工程在目标分支上的最新代码；对所述业务工程在目标分支上的最新代码、以及所述业务工程的各个一级依赖项对应的包文件进行打包，以得到业务工程对应的包文件。
[0151]
上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。