基于软件开发框架衍生的多应用微前端实现方法与流程

1.本发明涉及微前端开发技术领域，尤其涉及一种基于软件开发框架衍生的多应用微前端实现方法。


背景技术：

2.微前端是一种多个团队通过独立发布功能的方式来共同构建现代化web应用的技术手段及方法策略。微前端借鉴了微服务的架构理念，将一个庞大的前端应用拆分为多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用联合为一个完整的应用。微前端既可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活。
3.当前，基于vue、react、angular的单页应用开发模式已经成为业界主流。受益于它们丰富的生态，可以使用这些技术快速构建一个新的应用，迅速响应市场。随着业务的不断发展，由于各应用模块之间的强耦合性，导致应用开始变得庞大臃肿，逐渐成为一个巨石应用，难以维护不说，每次开发、上线新需求时还需要花费不少的时间来构建项目，对开发人员的开发效率和体验都造成了不好的影响。
4.目前普遍采用的开发方法，具有以下问题：
5.1、在新业务构建时，拷贝一份基盘代码作为脚手架工程，在此基础上进行些许修改，迎合新业务，然后才能进行业务开发。此模式长此以往下去，会导致基盘代码维护困难，一个地方有故障后，所有业务的基盘版本都得去做修改。且业务规模壮大以后会沦为巨石应用。因此，每次新建业务都需要重复以前的操作和修改，开发维护成本高。
6.2、通常从系统登录到组成一个系统的各个基本维护页面，其实是一套完整的业务流。任何业务都可以基于这套业务流做上层开发。但是，像vue这种模式的框架，在一个项目内做组件共通化是容易的，但在不同项目之间想实现一个共通化的模块比较困难。因此，基盘代码不可复用，基于vue框架的开发模式，项目之间很难实现共通模块的复用。
7.3、n框架不在开源微前端框架qiankun官方提供支持的范围内，无法很好的实现微前端思想。
8.所以需要通过引入微前端技术，解决开发过程中面临的问题。


技术实现要素：

9.本发明主要解决现有技术开发成本高，代码维护困难，项目之间无法实现共享等问题，提出一种基于软件开发框架衍生的多应用微前端实现方法，以达到实现基盘在项目之间的可复用性，提高开发效率，降低维护成本的目的。
10.本发明提供了一种基于软件开发框架衍生的多应用微前端实现方法，包括以下过程：
11.步骤a，根据工程管理的需要，对应用进行拆分，形成基盘应用和子应用；其中，所述基盘应用是系统的底层架构，所述基盘应用包含了基础功能的应用架构；所述子应用，可
以按行业进行具体划分；
12.步骤b，建立共通的ui组件库和工具类库；
13.步骤c，使用模块扩展，重写n框架核心逻辑，以完成qiankun对于子应用的接入需求；
14.步骤d，为各子应用创建脚手架工程。
15.进一步的，所述步骤a，包括以下步骤a1至步骤a5：
16.步骤a1，创建基盘应用的基础功能；
17.步骤a2，进行路由管理；
18.步骤a3，分别建立基盘应用和子应用的通信机制；
19.步骤a4，使用标签页，对每一个页面进行管理；
20.步骤a5，建立组件缓存动态管理机制。
21.进一步的，所述步骤a2，包括以下步骤a2-1至步骤a2-2：
22.步骤a2-1，进行系统的页面级改造；
23.步骤a2-1-1，主应用中增加对微应用的动态配置管理，可根据需要增加/修改/删除子应用的配置信息；
24.步骤a2-1-2，进行菜单定义配置；
25.步骤a2-2，进行框架级改造；
26.步骤a2-2-1，增加路由插件；
27.步骤a2-2-2，针对基盘应用和子应用，进行加载和卸载处理。
28.进一步的，在步骤b中，所述ui组件库和工具类库使用npm公共包进行管理。
29.进一步的，所述步骤b中，包括以下步骤b1至步骤b2：
30.步骤b1，按照如下步骤b1-1至步骤b1-5创建ui组件库；
31.步骤b1-1，基于脚手架搭建组件库项目，以及先实现并跑通一个测试程序组件；
32.步骤b1-2，将所有ui组件抽出到这个工程中，完善组件api的设计、组件模板和样式；
33.步骤b1-3，打包的组件库：使用webpack打包组件库的js代码、使用gulp打包样式代码；
34.步骤b1-4，发布组件库到npm上，以供基盘应用和子应用安装使用；
35.步骤b1-5，搭建组件库文档站点，包含了每个组件的接口定义，使用场景以及详细案例；
36.步骤b2，按照如下步骤b2-1至步骤b2-5创建工具类库；
37.步骤b2-1，创建基于rollup的初始工程；
38.步骤b2-2，将原系统中所有工具类库抽出到这个工程中，并对模块进行拆分；
39.步骤b2-3，使用rollup打包工具类库。
40.步骤b2-4，发布工具类库到npm上以供基盘应用和子应用安装使用；
41.步骤b2-5，搭建工具类库文档站点。
42.进一步的，所述步骤c，包括步骤c1至步骤c3：
43.步骤c1，重写n框架下的客户端client.js模板文件；
44.步骤c2，定义实例，注册插件；
45.步骤c3，编写client.js模块文件。
46.进一步的，所述步骤c1，包括：
47.步骤c1-1，在使用qiankun的场合下，暴露qiankun框架所需的bootstrap、mount、update、unmount生命周期函数，否则保留原始逻辑并进行画面渲染；
48.步骤c1-2，在qiankun的场合下，不改变webpack_public_path的值；
49.步骤c1-3，在qiankun模式下，创建app的时候，需要将基盘应用传过来的数据参数设置到全局的配置变量当中；
50.步骤c1-4，加载异步组件时，qiankun模式下，如果路由跳转先不是微应用的路径，不做任何处理，跳过继续执行后续路由跳转逻辑；
51.步骤c1-5，画面渲染时，qiankun模式下，如果路由跳转先不是微应用的路径，不做任何处理，跳过继续执行后续路由跳转逻辑；
52.步骤c1-6，组件规范化时，qiankun模式下，如果路由跳转先是微应用的路径，才执行规范化逻辑操作；
53.步骤c1-7，mountapp的时，qiankun模式下，需更改子应用的挂载点；非qiankun模式下，保持原有逻辑；
54.步骤c1-8，定义全局app实例，以便在各个函数逻辑中能访问到app实例；
55.进一步的，所述步骤c3，包括：
56.步骤c3-1，接收外部定义参数；
57.步骤c3-2，为本模块添加模板插件；
58.步骤c3-3，扩展webpack配置并输出umd或者自定义的库；
59.步骤c3-4，为本模块添加模板文件；
60.步骤c3-5，添加钩子函数listen＝》设定html entry的绝对路径以便可以正确地获取子应用；
61.步骤c3-6，添加钩子函数render:route＝》为编译过的文件设定access-control-allow-origin。
62.进一步的，所述步骤d，包括以下步骤d1至步骤d2：
63.步骤d1，通过以下步骤d1-1至步骤d1-4建立一个基于n框架的子应用模板工程：
64.步骤d1-1，建立包含n框架下用到的基本目录结构；
65.步骤d1-2，集成各种前端ui组件库，测试自动化框架库于工程内；
66.步骤d1-3，定制出各种基于不同设定会生成不同内容的模板文件；
67.步骤d1-4，建立包含了接入qiankun后的一系列微应用中，需要做的共通性处理逻辑；
68.步骤d1-4-1，增加导出qiankun生命周期各种函数的内部逻辑实现文件；
69.步骤d1-4-2，n框架的配置文件中增加了对桥梁工程；的引入，对ui组件库；和工具类库；的编译模块的引入；
70.步骤d1-4-3，package.json中接入对桥梁工程、ui组件库和工具类库的引入；
71.步骤d1-4-4，组件缓存的include和exclude的共通处理；
72.步骤d1-4-5，加入与主应用数据通信的逻辑处理；
73.步骤d1-4-6，加入路由管理的插件文件；
74.步骤d2，通过以下步骤d2-1至步骤d2-2建立创建子应用工程：
75.步骤d2-1，编写入口文件cli.js；
76.步骤d2-1-1，接收命令行中输入的各种参数及校验参数的合理性；
77.步骤d2-1-2，初始化cac对象；
78.步骤d2-1-3，给cac注册命令和选项值；
79.步骤d2-1-4，获取命令行参数传入sao库，进行项目的配置和项目文件的生成；
80.步骤d2-2，编写模板处理文件saofile.js；
81.步骤d2-2-1，准备模板；
82.步骤d2-2-1-1，准备n框架的工程模板：包括可以运行起n框架的所有文件以及可动态配置的模板文件；
83.步骤d2-2-1-2，准备第三方框架的模板文件；
84.步骤d2-2-1-3，准备基盘对接qianku的逻辑处理文件以及可动态配置的模板文件；
85.步骤d2-2-2，设置问题与答案的配置文件；
86.步骤d2-2-3，根据用户在cli中选择的答案，在action中添加对步骤d2-2-1中的各种模板文件的add、move、modify、remove操作；
87.步骤d2-2-4，按照action中定义完毕执行顺序和指令，动态修改所有的模板文件，完成的项目的生成。
88.本发明提供的一种基于软件开发框架衍生的多应用微前端实现方法，与现有技术相比具有以下优点：
89.1、基盘的可复用性，本发明通过将基盘代码从整个代码中抽离出来单独管理，实现了基盘在项目之间的可复用性。通过步骤a将基盘应用单独抽出形成一套完整的业务流，对接qiankun后子应用可完全使用基盘应用内的所有业务。通过步骤b可以重复使用具有共同性质的组件和工具类库。组件化带来的好处是：(1)封装：组件屏蔽了内部的细节，组件的使用者可以只关心组件的属性、事件和方法。(2)解耦：组件本身隔离了变化，组件开发者和业务开发者可以根据组件的约定各自独立开发和测试。(3)复用：组件将会作为一种复用单元，被用在多处。(4)抽象：组件通过属性和事件、方法等基础设施，提供了一种描述ui的统一模式，降低了使用者学习的心智成本。
90.2、本发明改造以使用n框架为基础，使其可以完美接入开源微前端框架qiankun，对原有技术框架进行改造，使改造后的技术框架可无缝的接入qiankun。本发明通过步骤c可完成n框架下与qiankun的初步对接。使n框架不被qiankun支持的问题变成了可能。这样做的好处是：可以在既有技术栈的模式下进行开发，而不是改变现有模式，选择其他原生框架(比如vue)进行大规模的改造或重新实现，这样做的代价是巨大的。
91.3、本发明为新业务构建时打造快捷的方法，通过将重复使用的功能放入基盘应用中，这部分内容在创建新业务时可直接复用，不用重复劳动。本发明通过步骤d可为子应用创建初始工程，此工程内包含为了对接qiankun所产生的所有重复且复杂的业务逻辑处理。此种做法的好处是：子应用不必从0开始搭建，为开发子应用节约了时间成本，拿来即用。
附图说明
92.图1是本发明提供的基于软件开发框架衍生的多应用微前端实现方法的实现流程图；
93.图2是本发明提供的基盘应用的创建流程图。
具体实施方式
94.为使本发明解决的技术问题、采用的技术方案和达到的技术效果更加清楚，下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部内容。
95.本方法是一种针对n框架下的qiankun接入方案，提供一套规范化，流程化的思路和解决方案，实现微前端应用框架。
96.qiankun是一个基于single-spa的开源微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。在qiankun的接入方案中，以eact/vue/angular原生框架接入的方案居多，除此之外，也提供了一些非webpack构建的接入方案，例如jquery项目、jsp项目等。
97.本方法所使用的n框架是基于vue.js实现的，并不在qiankun(乾坤)官方提供支持的范围内，需要对接qiankun框架。
98.如图1所示，本发明实施例提供的基于软件开发框架衍生的多应用微前端实现方法，包括以下过程：
99.步骤a，根据工程管理的需要，对应用进行拆分，形成基盘应用和子应用。
100.本发明是一种微前端的实现方法，微前端将微服务的理念应用于浏览器端，即将web应用由单一的单体应用拆分为为多个小型前端应用聚集为一体的应用。
101.在实际的各种系统应用的场景中，有一部分功能是一直在重复使用着的，比如：登录登出、用户/组织/权限管理、日志管理、全局的异常处理等，每个系统都会有这些基本的功能，属于基盘应用。而有一部分则是根据不同的行业属性和性质才会有的功能，属于子应用；比如：生产系统中的入出库、盘点、核算；学校系统中的学生管理、公寓管理、成绩管理等。
102.按照微前端的理念，要从各种系统中将具有共通功能的部分和具有不同特征的功能分离开来，以基盘应用(共通功能)和子应用(生产系统/学校系统/财务系统)的模式来重新规划和梳理。
103.所述基盘应用(主应用)是系统的底层架构，包括但不限于用户登录、组织管理、权限控制、日志管理等，是多种功能于一体的完整业务流，同时所述基盘应用也对外提供一些共通的组件。所述基盘应用包含了基础功能的应用架构(xx-fw)。
104.所述子应用，可以按行业进行具体划分，包括但不限于生产子应用(xx-product)、学校子应用(xx-school)、财务子应用(xx-finance)等。
105.所述子应用的建立过程：通过命令行npx create-miro-frontend xx-product，即可生成接入qiankun微前端的初始子应用程序。后续可在这个工程的基础上，直接开发业务画面了。可以做到对接qiankun无缝开发。
106.在接入qiankun之后，基盘应用中还应保留下来这些基础功能，但因为主子应用的分离，还要进行路由管理、主子应用通信、标签页管理、组件缓存。具体的，如图2所示，按照如下过程建立基盘应用：
107.步骤a1，创建基盘应用的基础功能。
108.在交付使用的各种应用系统中，创建包含但不仅限于：用户登录鉴权控制，用户角色权限控制，组织架构管理，菜单定义配置，用户主题变换，标签式页面浏览，消息通知，组件缓存等一系列基础性功能。
109.步骤a2，进行路由管理。
110.a2-1，进行系统的页面级改造。
111.a2-1-1，主应用中增加对微应用的动态配置管理，可根据需要增加/修改/删除子应用的配置信息。
112.配置信息中心包含：子应用的名称，子应用路由根节点(即子路由前缀)
113.a2-1-2，进行菜单定义配置。
114.对应前：路由统一管理。系统内的所有页面均通过菜单项的配置即可显示在导航菜单中并通过点击菜单选项来浏览对应的页面。
115.对应后：由于基盘应用和子应用的分割，导致路由产生物理隔离，彼此分而治之。所以如果想继续保持在主应用中管理所有的路由信息，在菜单定义配置中就要区分出路由是哪个应用的。
116.于是，在菜单的信息中加入了【是否是微应用】以及如果是微应用的场合，需要定义它的【根路由信息】。
117.这样做一是为了帮能区分出定义的路由到底属于哪个应用的，二是为了能在菜单点击或切换时，可以正确的加载出子应用并显示出对应的页面。
118.a2-2，进行框架级改造。
119.a2-2-1，增加路由插件。
120.n框架下，路由信息是根据当前工程下的目录结构自动生成，并由n框架统一管理。由于子应用的页面与主应用是物理隔离的，所以接入qiankun后，n框架会因为找不到相关的子应用的路由信息而出404的错误，导致无法正常加载出子应用。
121.解决方法是：增加路由插件，使用路由通配符，根据管理的子应用信息，动态添加子应用的路由到基盘应用中，使路由中提前存储到子应用的信息，这样就可以保证n框架下能正常加载出子应用。
122.a2-2-2，针对基盘应用和子应用，进行加载和卸载处理。
123.导航菜单在被点击时，如果是基盘应用路由，按照之前的方式正常加载路由即可；如果是子应用路由，建立缓存列表，通过缓存列表控制子应用的加载，路由的跳转并对已加载子应用的路由个数进行计数。
124.当通过点击标签栏上关闭按钮，适时的对子应用进行卸载处理。处理的规则就是：如果当某个子应用下的所有页面都已被关闭的场合，就卸载掉该子应用。
125.步骤a3，分别建立基盘应用和子应用的通信机制。
126.1)基盘应用提供了客户端缓存信息(数据字典，系统参数等)。子应用能够随时随地任意获取并使用这些信息。
127.2)基盘应用提供了统一的主题管理功能，可根据用户的需要，任意调整系统内的风格与样式。子应用能够保持与主应用样式的统一。
128.3)基盘应用提供了统一的系统错误提示与处理机制。子应用能够直接对接此机制，无需做额外的处理工作。
129.基于以上几点需求，在基盘应用层面的改造，需要在加载子应用的时候，通过qiankun提供的api函数将如下几个信息传递给子应用：状态存储对象/样式库对象。
130.步骤a4，使用标签页，对每一个页面进行管理。
131.应用系统中提供了一种类似于浏览器的行为方式，即使用标签页对每一个页面进行管理。
132.标签页方式管理的前提是需要基于路由信息，但是因为基盘应用和子应用的分离，基盘应用是无法获取到子应用详细的路由信息的。
133.此时，需要在子应用加载的过程中，通过子应用反向通信的方式将其路由信息回传给基盘应用，基盘应用收到回传信息后，做统一的缓存管理来实现标签页行为。
134.基盘应用则靠自身的路由管理机制即可获取到路由的信息，这样就可以分别实现对基盘应用和子应用的页面标签进行创建和管理。
135.同浏览器一样，标签页上提供了集中便捷式的关闭方式，如：关闭其他/关闭右侧/关闭所有。
136.在不同的关闭处理中，需要对被关闭的页面它们所属的子应用页面进行减数操作，当子应用页面的计数为0时，证明该子应用下的所有页面都已关闭，此时则需要对该子应用进行卸载。
137.步骤a5，建立组件缓存动态管理机制。
138.为了避免创建组件带来的效率开销以及可以保留组件的状态。应用系统中提供组件缓存的机制。但是根据不同的业务条件，常常可以自行决定是否保留组件的状态以及是否是要重新获得数据等等。
139.比如：
140.1.点击标签使切换标签(多标签之间切换时)，应缓存页面；
141.2.同一标签内发生的页面跳转，应缓存页面；
142.3.发生标签间页面跳转时，跳转先的画面状态应该为非缓存的；
143.所以不管标签页内页面是基盘应用的还是子应用的，都要为其进行组件缓存的动态管理。
144.需要在各个应用的路由管理中加入元信息为keepalive的参数，在不同业务条件下，为其动态赋予不同的值。
145.而业务画面的开发时，只需要简单判断keepalive的值，就可以完成各种不同的业务场景。
146.由于基盘应用和子应用都要有这部分的逻辑处理，所以组件缓存的逻辑会单独抽成工具类以便使用。(这部分功能要在工具类库里实现)
147.步骤b，建立共通的ui组件库和工具类库。
148.在原来的单一应用的管理中，有一部分共通的ui组件库和工具类库是可以在应用工程内部自由使用的。
149.按上述划分后，所述ui组件库和工具类库使用npm(ninja pumpkin mutants)公共包进行管理，npm是node.js默认的、用javascript编写的软件包管理系统。通过将公共资源以打包发布到npm的形式，在使用公共资源的一侧只需安装指定了版本号的资源，就可以将资源引入到自己的工程中直接使用了。所以共通的部分也需要单独建立工程，例如，ui组件库(xx-ui)和工具类库(xx-util)。
150.步骤b1，按照如下过程创建ui组件库：
151.步骤b1-1，基于脚手架搭建组件库项目，以及先实现并跑通一个demo(小型测试程序)组件。
152.步骤b1-2，将原系统中所有ui(userinterface，用户界面)组件抽出到这个工程中，完善组件api(application program interface，应用程序编程接口)的设计、组件模板和样式的实现等。
153.步骤b1-3，打包的组件库：使用webpack打包组件库的js代码、使用gulp打包样式代码。
154.其中，webpack是一种代码编译工具，是一个用于现代javascript应用程序的静态模块打包工具。js一般指javascript，javascript是一种具有函数优先的轻量级，解释型或即时编译型的编程语言。gulp.js是由eric schoffstall创建的开源javascript工具包，用作前端web开发中的流构建系统，可以自动执行指定的任务，简洁且高效。
155.步骤b1-4，发布组件库到npm上，以供基盘应用和子应用安装使用。
156.步骤b1-5，搭建组件库文档站点，包含了每个组件的接口定义，使用场景以及详细案例等。
157.步骤b2，按照如下过程创建工具类库：
158.步骤b2-1，创建基于rollup的初始工程。其中，rollup.js是一个javascript模块打包器，可以将小块代码编译成大块复杂的代码，例如library或应用程序。
159.步骤b2-2，将原系统中所有工具类库抽出到这个工程中，并对模块进行拆分，每个模块做自己对应的方法。这样做可以降低维护成本。
160.模块比如分为：base、date、file、data、security...等模块。
161.步骤b2-3，打包工具类库：使用rollup打包工具类库。
162.步骤b2-4，发布工具类库到npm上以供基盘应用和子应用安装使用。
163.步骤b2-5，搭建工具类库文档站点，包含了每个模块的接口定义，使用场景以及详细案例等。
164.步骤c，使用模块扩展，重写n框架核心逻辑，以完成qiankun对于子应用的接入需求。
165.n框架是一个具有完全模块化的架构，为了能接入qiankun框架，需要使用模块扩展，去重写n框架核心逻辑，建立桥梁工程(qiankun bridge)。
166.具体的，子应用需要在自己的入口js上导出bootstrap(初始化)、mount(挂载)、unmount(卸载)三个生命周期钩子，以供基盘应用在适当的时机调用。
167.按照如下过程建立桥梁工程：
168.步骤c1，重写n框架下的客户端client.js模板文件：
169.步骤c1-1，在使用qiankun的场合下，暴露qiankun框架所需的bootstrap(初始
化)、mount(挂载)、update(更新)、unmount(卸载)生命周期函数，否则保留原始逻辑并进行画面渲染。
170.步骤c1-2，在qiankun的场合下，不改变路径全局变量(webpack_public_path)的值。其中，publicpath是指定应用程序中所有资源的基础路径，webpack暴露了一个名为__webpack_public_path__的全局变量,可以在运行时设置publicpath。
171.步骤c1-3，在qiankun模式下，创建app的时候，需要将基盘应用传过来的数据参数设置到全局的配置变量当中，以便之后进行基盘应用的实例注册。
172.步骤c1-4，加载异步组件时，qiankun模式下，如果路由跳转先不是微应用的路径，不做任何处理，跳过继续执行后续路由跳转逻辑。
173.步骤c1-5，画面渲染时，qiankun模式下，如果路由跳转先不是微应用的路径，不做任何处理，跳过继续执行后续路由跳转逻辑。
174.步骤c1-6，组件规范化时，qiankun模式下，如果路由跳转先是微应用的路径，才执行规范化逻辑操作。
175.步骤c1-7，挂载应用(mountapp)的时，qiankun模式下，需更改子应用的挂载点；非qiankun模式下，保持原有逻辑。
176.步骤c1-8，定义全局app实例，以便在各个函数逻辑中能访问到app实例。
177.步骤c2，定义实例，注册插件。
178.本步骤为微应用注入各种实例。
179.步骤c3，编写client.js模块文件。其中，client.js模板文件，用来写入对接qiankun的实现逻辑。
180.步骤c3-1，接收外部定义参数。所述参数包括但不限于hookfilepath：处理钩子函数中业务逻辑的文件路径，webpackoutput：对webpack的output选项进行定义，unique：子应用的包名是否需要唯一等。
181.步骤c3-2，为本模块添加模板插件。
182.具体的，将步骤c2中注册插件添加进来。
183.步骤c3-3，扩展webpack配置并输出umd或者自定义的库(暴露挂载点)。
184.步骤c3-4，为本模块添加模板文件。
185.具体的，将步骤c1得到的模板文件添加进来。
186.步骤c3-5，添加钩子函数listen＝》设定html entry的绝对路径以便可以正确地获取子应用。
187.步骤c3-6，添加钩子函数render:route＝》为编译过的文件设定access-control-allow-origin。
188.此工程将作为共通资源发布到npm公有库，以便各个子应用可以直接安装引用，并作为子应用的一部分模块配置到子应用中去使用。
189.步骤d，为各子应用创建脚手架工程。
190.考虑到应用系统可以快速迭代，上线部署并投入使用。如果能够提供一种快速的子应用的创建方法，将能省掉很多不必要的重复性工作，节约时间成本。因此，本发明提供一个子应用的脚手架工程，用一个命令直接可以生成一个初始的，可运行的子应用系统。
191.所述脚手架工程cli，包括但不限于：子应用模板工程(xx-template)和创建子应
用工程(xx-cli)。
192.步骤d1，通过以下过程建立一个基于n框架的子应用模板工程：
193.步骤d1-1，建立包含了n框架下用到的基本目录结构。
194.步骤d1-2，集成了各种前端ui组件库，测试自动化框架库于工程内。
195.步骤d1-3，定制出了各种基于不同设定会生成不同内容的模板文件。
196.本步骤中的模板文件，包含代码文件及各种代码规范校验文件。
197.步骤d1-4，建立包含了接入qiankun后的一系列微应用中，需要做的共通性处理逻辑。
198.本步骤简化子应用中关于微前端部分的逻辑处理，让子应用更关注业务面的开发。
199.步骤d1-4-1，增加导出qiankun生命周期各种函数的内部逻辑实现文件。
200.步骤d1-4-2，n框架的配置文件中增加了对桥梁工程(xx-bridge-module模块)的引入，对ui组件库(xx-ui)和工具类库(xx-util)的编译模块的引入。
201.步骤d1-4-3，package.json中接入对桥梁工程(xx-bridge-module)、ui组件库(xx-ui)和工具类库(xx-util)的引入。
202.步骤d1-4-4，组件缓存的include(包含)和exclude(排除)的共通处理。
203.步骤d1-4-5，加入与主应用数据通信的逻辑处理。
204.步骤d1-4-6，加入路由管理的插件文件。
205.步骤d2，通过以下过程建立创建子应用工程：
206.目的：提供了交互式命令行工具以用来快速生成子应用的初始工程。
207.功能：(有且不仅限于下记功能)
208.步骤d2-1，编写入口文件cli.js；
209.步骤d2-1-1，接收命令行中输入的各种参数及校验参数的合理性；
210.步骤d2-1-2，初始化cac(第三方建立命令行应用库)对象；
211.步骤d2-1-3，给cac注册命令和选项值；
212.步骤d2-1-4，获取命令行参数传入sao库(sao是一个前段脚手架，可以通过sao新建很多个模板，根据模板批量生产初始化代码)，进行项目的配置和项目文件的生成；
213.步骤d2-2，编写模板处理文件saofile.js；
214.步骤d2-2-1，准备模板；
215.步骤d2-2-1-1，准备n框架的工程模板：包括可以运行起n框架的所有文件以及可动态配置的模板文件等；
216.步骤d2-2-1-2，准备第三方框架的模板文件。其中，第三方框架的模板文件包括ui库，测试库，lint等。
217.步骤d2-2-1-3，准备基盘对接qianku的逻辑处理文件以及可动态配置的模板文件等；
218.步骤d2-2-2，设置问题与答案的配置文件；
219.步骤d2-2-3，根据用户在cli中选择的答案，在action中添加对步骤d2-2-1中的各种模板文件的add、move、modify、remove操作。
220.步骤d2-2-4，按照action中定义完毕执行顺序和指令，动态修改所有的模板文件，
完成的项目的生成。
221.至此，完成了全部的应用工程的划分，具体划分如下：
222.基盘应用：包含了基础功能的应用架构；
223.子应用：需按行业具体划分；
224.共通：ui组件库和工具类库；
225.桥梁工程，实现n框架对接qiankun的模块；
226.脚手架工程：子应用模板工程、创建子应用工程。
227.最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。