下载掌阅APP，畅读海量书库
立即打开
目前市场上流行的前端工具大体分为3类，分别介绍如下。
1.工作流管理工具，比如Grunt、Gulp。
2.构建工具，比如webpack、rollup。
3.整体解决方案，比如FIS、WeFlow。
FIS是一套比较完整的前端工程化方案，它具备构建、部署、Mock服务等基本功能，但其构建功能对于目前市场较流行的技术支持度不是很理想，需要编写插件实现。而且其生态圈不够庞大，插件数量和质量均堪忧。此外，FIS诞生的初始目标是解决百度团队的内部需求，不论是从功能的完整度还是对编程范式的约束上，均有一定的局限性和捆绑性，比如FIS实现自动生成CSS Sprites图的功能需要开发者在代码中注入特殊标记，这在一定程度上限制了代码的可移植性。
Grunt、Gulp之类工作流管理工具本身不提供任何具体功能，所有的构建、部署等功能均由对应的插件提供。这便于项目各环节工作流程的控制，比如构建功能可以安排首先构建CSS和JS，然后构建HTML。Grunt和Gulp各自的生态圈也比较完整，但它们逐渐有了衰退之势。图1-10是来自Stack Overflow Trends的数据。
图1-10
Grunt、Gulp相关的讨论话题与webpack相比下落趋势明显。webpack虽然是近两年才崛起的构建工具，但其迅速发展为目前最流行的构建工具之一。其生态圈的庞大程度相比Grunt、Gulp有过之而无不及，与FIS相比更是拉开了数量级的差距，而且React、Vue等较流行的框架对应的webpack Loader均是由官方或者作者本人编写的，可保证插件的质量和更新的及时性。即使生态圈没有你所需的插件，webpack也提供了优雅的生命周期和高度扩展的API，便于开发各类插件。此外，webpack在提供足够多的构建功能的同时兼具性能优化，比如对构建产出文件的体积进行监控、其v2版本引入的Tree Shaking机制等。这也是我们选择webpack作为构建内核的原因之一。rollup也是一款非常优秀的构建工具，但由于起步较晚，目前生态还不完整。
本地工具链和云管理平台形态的前端工程化方案的主要区别在于，将构建、部署功能提升到云平台集中管理，保证构建结果的一致性并且便于权限控制，而从各个功能模块的实现角度考虑并没有很大差别。所以本书以本地工具链形态的前端工程化方案Boi为例，剖析各功能模块的设计方案和实现细节，同时在论述过程中兼顾云平台的差异性对比及其解决方案。整体架构如图1-11所示。
图1-11
● 暴露给用户层的有两种接口：命令行调用各功能模块的接口和配置接口。
● 平台层分为4个功能模块：脚手架、本地服务器、构建以及部署模块。
● 内核层是各个功能模块的内核，脚手架使用Yeoman，本地服务由Node.js的Express框架承载，构建功能模块围绕webpack打造，部署基于SSH协议实现。
● 以上所有的功能实现均是建立在Node.js平台上的。
小贴士： Boi 是一款开源的前端工程化方案，读者可以在 GitHub （https：//github.com/boijs/boi）中获取其源码。
请注意，本书的重点并不是具体的代码实现细节，而是通过具体案例探讨前端工程化方案应该具备的功能以及设计原则。以上的具体架构和方案只是作为辅助，目的是为了便于论述和理解。
根据如图1-11所示的工程化整体架构，平台层分为4个功能模块。
● 以Yeoman为内核的脚手架。
● 以Express承载的本地服务器。
● 以webpack为内核的构建系统。
● 基于SFTP协议的远程部署功能。
得益于庞大的生态圈，使用Node.js开发命令行工具并不是一件难事，我们可以借助优秀的辅助工具完成，比如commander.js。
首先在package.json文件中声明bin字段指向项目中的入口文件：
其中 key 的值＂boi＂便是命令行工具的主命令，value 值＂bin/boi.js＂指向的是此命令调用的文件路径。
然后在＂bin/boi.js＂文件中的顶部声明此文件需要调用Node.js执行：
#!/usr/bin/env node
随后就可以使用commander.js定制具体的子命令了。以build命令为例：
小贴士： commander.js是一个实现命令行交互的Node.js模块，由著名的工程师TJ Holowaychuk编写。更多使用细节读者可以参考commander.js的官方文档。
根据前文所述的功能规划，各功能对应的命令行命令如表1-1所示。
表1-1
各命令具体的使用细节后续章节将详细讲述。
构建系统是整个工程化方案中最重要也是最复杂的功能，主要解决的是前端开发层面的问题。根据1.4节列出的问题，本书所介绍的工程化方案Boi将内置以下功能。
● ES规范的转译。
● CSS预编译器支持。
● PostCSS处理hack后缀。
● 自动创建CSS Sprites图。
● 图片压缩。
● 小体积图片base64内嵌。
● JavaScript模块化规范支持。
除以上功能以外，Boi针对不同的缓存策略可以支持增量更新与覆盖更新构建。
具体的实现细节将在第3章讲解。
一个前端项目的迭代周期自始至终需要经历3个阶段：开发、测试和部署上线。每个阶段对应的运行环境为开发环境、测试环境和生产环境。不同的运行环境存在差异性的同时，对工程化方案的需求也不尽相同，比如开发环境需要借助Mock服务进行前端逻辑的开发、构建产出的代码需要便于浏览器调试，测试环境与生产环境的异步数据接口地址不同，生产环境需要控制静态文件体积等。工程化方案需要针对3种运行环境提供相应的功能和策略，必然会将环境相关的配置开放给用户。本书所介绍的工程化方案Boi将3种环境具化为3个不同配置API。
● dev——开发环境。
● testing——测试环境。
● prod——生产环境。
3种环境的执行时机分别如表1-2所示。
表1-2
用户可以通过配置 API 针对不同的环境分配对应的功能和策略，随后使用命令行工具指定执行环境。比如测试环境使用如下配置不对JavaScript代码进行混淆处理：
其中boi.spec是Boi提供的配置API。开发完成之后，运行以下命令构建测试环境代码：
boi build--env testing
最终构建产出的JavaScript代码不会经过混淆。
对环境配置功能最直观的理解是针对不同运行环境构建产出不同的代码内容。具体到使用层面可以与本地服务器、Mock服务、构建、部署功能模块联动，打造一种类似沙箱的独立作业环境，目的是解放生产力，同时保证整个开发流程的严谨性和代码质量。本书后续章节将详细讲述环境配置与各功能模块联动方案。
规范分为两部分：工程化方案自身的配置 API 规范以及方案对代码编程范式的约束规范。
配置 API 的设计原则着重于配置项的简洁明了，配置项可以一目了然。本书所介绍的工程化方案 Boi 使用 webpack 作为构建内核，在其外层封装了一层简化的配置API。webpack自身的优异性不用赘述，但是配置复杂度非常高，并且webpack自身不提供任何具体的构建方案，用户需要自行配置并安装各种loader、plugin来封装符合项目需求的具体方案。开发者往往需要花费大量的时间学习和处理 webpack 本身的配置，这显然是非常影响开发效率的。Boi以外部简化的配置API映射内部高度复杂化的webpack配置，不仅降低了一线业务开发人员对构建工具本身的学习成本，还避免了在进行自身迭代以及问题修复过程中增加的迁移成本。
编程规范的设计原则着重于代码的可移植性，减少对代码的捆绑性。比如前文提到的FIS在实现CSS Sprites功能时需要开发者在代码中添加可被FIS识别的特殊标记。如果项目需要迁移到其他构建方案中，这类特殊标记便成为冗余代码，不仅影响代码的可读性，而且不能保证与新的构建方案不存在冲突。工具只是辅助作用，最基本的原则是切勿喧宾夺主。
除能够解决现阶段的功能需求以外，对隐含需求的支持度也是评估一套工程化方案的标准之一。即使出现新需求时目前方案不支持，也能够以很小的成本对方案进行扩展。前端资源以及技术选型的多样性，令可扩展性对于前端工程化方案来说尤为重要。我们在设计工程化方案架构时，应当秉持“内核轻量、扩展丰富”的原则。比如webpack本身不提供任何具化的方案，而是开放丰富的配置和扩展API供开发者封装和扩展自己的构建方案。本书所介绍的工程化方案Boi自身只封装了必要的功能，比如 ES 转译、CSS 预编译器支持等，对于目前流行的框架如 React、Vue并不支持。但是你可以通过Boi的插件系统以非常小的成本对Boi进行扩展，并且这些插件是即插即用的，不会对Boi内核产生任何影响。