初窥Web前端工程化：web-pack核心组件设计

上期回顾

先来回顾一下，在上期内容里，川哥为我们揭示了当下前端编译打包工具都是运行再Node环境下的，开发者是离不开编辑器IDE、编译打包这些工具。

但如何离开Node环境，前端开发者又该怎么办呢，此时web-pack应运而生。先来回忆下web-pack的设计基座：web-pack =  webpack + npm + IDE，后面，川哥还带我们讲解了web-pack核心组件，如依赖管理、编译文件处理模块、IDE等。

今天，川哥带来了web-pack下半部分的内容，让我们来看看，web-pack都有哪些应用场景。

web-pack应用场景

前面我们讲了许多理论，对于工程师来讲更多的关注这门技术到底能应用到哪些场景中，在《前端架构从入门到微前端》一书中，将微前端的实施分为六种，分别是路由分发、前端微服务化、微应用、微件化、iframe、Web Components

这里我们挑选出最重要，也是经常遇到的一个场景—微前端来展开说说。

所谓的微件化（Widget）是一段可以直接嵌入应用上运行的代码，它由开发人员预先编译好，在加载时不需要再做任何修改或编译。微前端下的微件化是指，每个业务团第编写自己的业务代码，并将编译好的代码部署到指定的服务器上，运行时只需要加载指定的代码即可。

经过web-pack构建微件化后，组件规范化，依赖管理等问题都得到了很大程度的解决。

统一依赖，引入新的依赖时都需要加入。

规范应用的组件及路由，避免不同的应用之间，因为这些组件名称发生冲突。

构建复杂，在A方案里，需要修改构建系统，在B方案里则需要复杂的架构脚本。

共享通用代码，这显然是一个要经常面对的问题。制定代码规范。

通过下面这张表，和github仓库实现的微件化的实现方案比，我们可以看出web-pack的优势都有哪些。

除此之外，在组件管理平台这类应用场景中，web-pack也发挥着巨大作用，通过web-pack将代码编写发布后，所有人都可以在上面修改代码。这种模式非常适合跨团队，跨项目，多人协作的复杂项目。

web-pack核心架构设计

这张web-pack核心架构图是不是很熟悉？在上一期的回顾文中，我们解释了web-pack的架构设计原理，本次，我们着重深入依赖，编译、沙盒这三个模块，详细探究这三个模块的核心设计原理

依赖

是上一期的文章中，我们有写到，组件由树形依赖表构成，依赖可以是一个.vue，.js，png，sass等文件，组件都有一个名为mian.** 文件编译入口，同时，组件本身可以作为其他组件的依赖。依赖可以分为内部依赖、外部依赖、临时依赖等，不同依赖的加载运行方式是不同的

编译器

前文我们有说过，前端在线编译打包工具可以直接在页面上进行前端代码编译打包，生成可直接在页面即时预览的代码。这个过程中核心的模块就是Compiler 。

作为web-pack 的核心内容，Compiler主要作用是能够帮助我们将字符串代码文本解析为ATS语法树，通过Complier的插件可以按照我们的需要将文本处理为可用代码。下图是我们列举了常见的前端文件如JS、CSS、HTML的编译器

沙盒

组件编写后，需要对组件的样式、变量保持一定的封闭性，这就是沙盒的作用了。沙盒常见的方案是iframe。这个方案的好处是

全局变量隔离，如setTimeout、location、 react不同版本隔离

路由隔离，应用可以实现独立路由，也可以共享全局路由

多实例，可以同时存在多个独立的微应用同时运行

安全策略，可以配置微应用对Cookie localStorage资源加载的限制

但是缺点也是明显的，首先script脚本不能执行，也不能发送表单和ajax请求，这显然是不符合我们的需求的。

以JS为例，解决方案是分配组件变量控件，设置公共变量控件管理，进而管理组件的生命周期。对于样式的隔离，我们可以让postcss处理scoped，默认组件为scoped处理，同时加入代码检查功能，对于组件样式的代码，不允许修改全局样式。

除了以上功能，通过web-pack的配置引擎，还可实现可视化表单组件。

讲师介绍

川哥，360前端Leader，FCC武汉社区组织者

《Hello ,World公开课》推出的面向广大开发工程师的免费加餐课，集结业内名师大咖，聚焦热门技术和实战解决方案，以专业知识分享交流为桥梁，链接正在创造世界的一群科技主力们，向初心致敬，为技术发烧。无论你是初入职场的应届生，还是准备升职加薪的职场精英，相信这里都有你需要的养料。