vue简易微前端项目搭建（一）：项目背景及简介

github传送门：
1、h5主项目
2、项目脚手架
3、子项目模板

系列文章传送门：
vue简易微前端项目搭建（一）：项目背景及简介
vue简易微前端项目搭建（二）：子项目模板及项目脚手架搭建
vue简易微前端项目搭建（三）：webpack相关配置

最近有空，准备写个系列教程，把公司目前在用的h5项目从搭建到实践优化的一些心得和经验记录一下，技术栈是vue2.x的，马上3.0正式版就要出了，再不写就要过时啦哈哈。

1、项目需求

我司h5主要做移动端，运行在app和小程序里，也就是hybrid app混合开发模式。

刚来公司时，公司h5才刚开始起步，同事只开发了三个h5需求，这三个需求在业务功能上都是相互独立的，所以也分开放在了三个spa项目里。。。想一想，以后开发类似需求越来越多，页面功能比较分散，大多都是相对独立的模块，难道要写n个项目吗，所以有必要设计一个多项目聚合方案。

2、关于微前端

我感觉今年随着qiankun2.0的发布，微前端概念突然火了很多，我记得去年也就是19年的时候还没那么火呢，不过确实是未来前端发展的一个方向。

在前公司的时候，有配合过后端做过微服务迁移的过程，对后端的微服务有一定的了解，后端一般是把接口划分为一些模块，每个模块就是一个微服务粒度，比如user、goods，每个模块都可以单独启动、单独修改发布。

而微前端也是借鉴后端的微服务化，把前端根据功能划分成几个相对独立的子项目，可以单独编译发布。

关于技术栈无关，个人认为对微前端来说是很有用的，但不是必需的，技术栈无关适用于把已有的几个老项目整合一起组成微前端，而如果是在微前端项目的立项搭建时就显得没那么重要了，因为搭建项目时选择统一的技术栈无论是开发维护还是代码复用都更方便且实际。

微前端也是前端技术发展过程中借鉴微服务后慢慢形成的一种架构思想，架构本身就是服务于业务而千变万化的，所以不必咬文嚼字去定义微前端必须具备哪些点。

本项目，只适用于vue技术栈，可以说是简易的微前端项目，也可以说是基于vue的多项目聚合方案。

3、关于本项目架构思路

技术栈选择呢，由于之前已做需求都是vue写的，也对vue相对更加熟悉，所以就选定vue作为基础框架，也便于项目搭建完成后把之前项目迁移进来，也是借鉴了前公司的方式。

整体上是基于vue-cli4生成的项目进行改造搭建，根据业务划分为多个不同的子项目，

（1）目录结构：

  ├── build                             // webpack相关配置├── src                               // 核心源代码│   ├── projects                      // 存储所有子项目│   │   ├── demo                      // 子项目目录名│   │   │   ├── components            // 子项目公共组件│   │   │   ├── static                // 不打包的js目录│   │   │   ├── store                 // vuex存储│   │   │   ├── utils                 // 公共js│   │   │   │   ├── importVant.js     // vant按需引入│   │   │   │   └── routerGuards.js   // 路由导航守卫│   │   │   ├── views                 // 页面源码│   │   │   ├── config.js             // 子项目配置文件│   │   │   └── main.js               // 子项目入口文件│   │   └── ......                    // 其他子项目│   ├── resources                     // 存储全局公共资源│   │   ├── assets                    // 全局公共图片等│   │   ├── components                // 全局公共组件│   │   ├── mixins                    // 全局mixins混入│   │   ├── styles                    // 全局公共样式│   │   ├── native                    // 原生客户端交互封装│   │   │   ├── callNative.js         // 调用客户端方法│   │   │   ├── openNative.js         // 跳转客户端页面│   │   │   ├── regNative.js          // 注册js方法给客户端│   │   ├── utils                     // 全局公共js│   │   │   ├── flexible.js           // rem适配│   │   │   ├── globalGuards.js       // 全局路由导航守卫公共方法│   │   │   ├── polyfill.js           // 手动添加的polyfill降级方法│   │   │   └── request               // 全局接口请求相关├── .env                              // 全局环境配置├── .env.beta                         // beta环境配置├── .env.dev                          // 本地环境配置├── .env.prod                         // 线上环境配置├── .env.test                         // test环境配置

（2）简述：

src目录包含projects和resources两个文件夹：
resources存放公共资源文件，
projects存放所有子项目，里面每个文件夹就是一个子项目，每个子项目相互独立，可以单独运行及打包。
部署到线上时，也是每个子项目隶属于不同的目录路径，例如子项目a是https://test.com/a/index.html，子项目b是https://test.com/b/index.html。

这样，不同的业务需求可以通过创建不同的子项目来开发，resources里有公共资源方法可以共用，例如公共样式、公共方法、客户端交互等等。

（3）优势：

1、利于多人多项目并行开发。在业务需求繁多、开发人员较多的时候，很多需求就需要并行开发，一个需求分配几个开发人员组成一个临时项目组，并行独立进行开发和上线，这样就可以通过在不同的子项目下开发而互不影响，同时也能方便使用公共资源和组件，保证并行开发的效率。
2、利于发布上线时的风险分散。子项目可以单独发布，即使代码修改有严重bug，发布后也只会影响这次发布的子项目，未发布的也就是之前已通过测试上线的可以照常运行。
3、提升页面访问速度和开发构建速度。相比于一整个大项目的方式，单个子项目使用webpack启动和构建的速度肯定更快；而且单个子项目使用的依赖包更少，意味着打包后的js文件更小，页面初次访问速度就会更快。当然，在不同子项目页面之间来回访问的速度相对会慢不少，但由于此hybrid h5项目的特殊性，绝大多数需求模块相对独立，互相跳转的场景很少，合理的划分子项目即可，而且hybrid h5里很多场景下新开一个webview打开页面的体验更好，这样还是得重新加载页面。

（4）对比MPA

这里说的MPA是指单页面spa和传统多个html形式混合后的一种方式，在webpack的entry里配置多个入口实现，在项目启动和打包时都是一起构建的。
这种方式对比上述的三点优势，其实就只是第3点的提升页面访问速度算是一致，其他优势点都不具备。
个人理解MPA的主要应用场景是提升首屏访问速度。即把首屏页面单独划分出来，这样首屏部分打包后的js等代码就少很多，访问速度自然有所提升，特别是其他页面引入了很多第三方依赖的情况。而页面的懒加载只是路由的懒加载，未配置chunk分离的依赖打包后仍然会在初始页面里加载，没有MPA方式解决的更彻底。

4、项目配套

由于项目的运行及打包需要指定选择一个子项目，子项目会随着业务的发展越来越多，不可能都在package.json的script里写上固定的命令吧，为了提高命令使用效率，就做了个配套的脚手架工具，使用nodejs编写，主要用于创建子项目、子项目启动、打包等命令，可以自定义输入命令来指定子项目名和服务端环境。

同时也创建了个子项目模板，便于快速生成一个子项目，以及做子项目使用引导。

github地址见文章开头，业务相关代码已做清理。

5、子项目划分

这个就见仁见智了，具体还是根据公司业务需要来考虑，不用分太多，不然子项目太多管理也不方便，路由懒加载下其实一个子项目里多放些页面也没关系。

比如一些简单的独立的页面（例如用户协议、app下载页什么的）可以都放到一个子项目里
再比如一些有时效性的活动页也可以放到一起，比如中秋活动页、双十一活动页什么的，也可以按年份归纳，比如命名activity2020，2020年的活动页都放这里。