Version：2019.09.08.v1.2
开篇
大家好，我是王小胖，一个集可爱与智慧于一身的胖子。
当初订的每周至少一篇原创文章的规矩尽量不破，所以就算不能玩刚出的《怪物猎人：冰原》也要把文章给大家补上。。。
书接上回，上回书说到“前端工程化之脚手架”，谈了一谈胖子认为的前端脚手架的定义和服务内容。这次咱们再闲谈一下下面几个问题。
- 脚手架的还应具备的特质（对之前文章中的一些观点的补充）
- 常见的脚手架介绍
- 脚手架实现的思路
- 制作脚手架可能依赖的相关库
脚手架还应该具备的特质
封装性（隔离性）
引用 《前端工程化：体系设计与实践》（好书推荐）书里的一段话，
“前端工程体系的功能涵盖范围广，封装的方案类型多，对应的配置项也非常复杂。而且，大多数前端工程体系的开发者并不是一线的业务开发者。对于业务开发者来说，这套工程体系就是一个黑盒，他们不需要了解其中的复杂原理，只需要知道如何配置即可。所以业务开发者的需求就是快速开发快速配置，并且生成的配置项跟项目要对应，既要满足项目的功能需求，又不能有“混淆视听”的冗余功能。”
封装和隔离，目的就是对非必要的工程化体系的技术细节封装到一个黑盒中，对一线业务开发人员从不必要的工程体系相关繁琐的工作开发任务隔离开来，提高相关业务人员关注的业务本身，提高专注性，提高生产效率。
兼容性
由于脚手架使用的特殊性，大部分使用场景是在工程师的本地平台上，所以，一个优秀的脚手架，就需要考虑到多个系统平台的支持，理论上讲不能有平台限制（除非这个脚手架是仅仅是服务你们内部项目并且你们公司的开发环境是高度统一的）
灵活性（可扩展性）
针对这个特性，胖子想先强调是针对内部项目或内部业务而产生的客制脚手架，首先是我们的脚手架应该尽量具备灵活性和宽展性，那么怎么理解这点呢？
因为现在前端的多样性和复杂性，服务于我们自己业务项目的脚手架应该考虑之后业务变化带来的技术更替，要考虑技术兼容的问题，所以一个灵活的可配置的脚手架设计就会为今后的升级更新带来便利。在脚手架的设计之初就要考虑到这点，那么为了避免过度设计，胖子建议参考下面几点建议。
- 考虑好你的脚手架的服务生命周期的目标，设计好每个生命周期阶段的任务，之后再向不同的生命周期的篮子里填充你的功能，尽量保持周期之间互不影响。
- 如引用第三方的模块，尽量引用第三方模块的原有功能接口，如有成熟的配置工具模块，尽量调用成熟的模块功能，这样在之后的技术更新中，如果第三方模块接口不变，我们就不需要做额外的工作做兼容。
- 前期尽量功能不要太多，只提供必要的功能支持，因为功能少就意味着依赖更少，灵活性可控。
业务和工程目标驱动性
补充这点，主要是强调一下脚手架最终的目的是为业务和工程服务的，应该是业务和工程驱动脚手架变化的，而不应该是工程师团队，它不是技术的练兵场和百宝箱，不是任何一个工程师觉得一个新技术或新点子不错，就把这些加入到我们的脚手架里面。脚手架的目的都是纯粹的，“服务业务，提高效率”。
目前任何一个和前端相关的库和框架，ReactJS，VueJS，Express等等的脚手架的目的都是统一和纯粹的，让用户快速上手熟悉它们的东西，降低框架自身的学习成本。推广它们的产品和业务。所以，一个好的脚手架，应该是为业务和工程服务的。
常见的脚手架介绍
下面列出三个业界稍有名气库或框架的脚手架（其实大部分主要还是提供工程初始化功能的），都是知名框架和库提供的generator脚手架，相信用过相关框架和库的你应该都很熟悉的。
Angular CLI
Vue CLI
Express Generator
Yeoman
最后一个是yeoman，它的主页上对自己的定义是“用Web脚手架工具构建Web APP，优化你的工作流，让你快速，优雅的Coding！”。其实胖子对其的理解就是一个web app的generator的构建系统，你可以在Yeoman生命周期基础上构建自己的脚手架generator，也可以在它现有的generators（3900+）里查找到你的脚手架快速生成你的web项目。
脚手架实现思路
其实，脚手架的实现思路，特别是项目初始化脚手架的实现思路，胖子觉得套路还是很简单的。就和要把大象关冰箱里是一样的，总（nong三声啊）共就那么几步。。。这里我们借鉴一下Yeoman的生命周期来看看实现自己的脚手架我们需要思考的思路。
- 初始化：这一步主要是启动脚手架，校验项目的状态，获取一些基本的配置信息等。
- 获取用户配置：这一步就是通过互动交互的方式获取用户的定制化配置信息。
- 解析配置信息：处理上一步的用户定制化配置信息，结合项目自身的相关默认配置，生成解析出最终的项目配置。
- 生成项目模板文件：针对最终生成的项目配置，生成项目的基本模板文件结构。这一步一般有两种常用方式生成模板文件，一种是在已有的代码仓库中获取，例如从git上下载下来；另一种是根据配置动态解析生成模板文件。也有的项目是两种的结合，例如项目的初始文件（例如angualr的component相关文件）直接下载，项目相关的配置文件（例如tsconfig）则动态解析生成。
- 收尾：这一步简单了，工作做完了，一定要做好清理和还原工作啊。
项目初始化搞定了，剩下的就要思考在前端工程化过程中各个阶段你的脚手架计划提供的功能feature了，比如本地开发服务器等。这个就是具体需求出具体的解决方案了。
制作脚手架可能依赖的相关库
说完脚手架的实现思路了，那么咱们要是开始打造自己的脚手架的化，需要怎么做技术选型呢？这里胖子简单列出一些构建一般的命令行脚手架的库和工具。
基础依赖工具s
NodeJS和ES这里胖子就不用多介绍了吧（能看这篇文章的，估计都没有问题）。
命令行工具库commander.js
命令行界面的完整解决方案。
互动命令行工具库Inquirer.js
提供了用户界面和会话问答流程解决方案。
命令行美颜工具s
“美颜”，不仅能让你的命令行更迷人，主要是能大大的提高你的脚手架的用户体验，谁让咱们是做前端的呢？
命令行样式美化工具
加载效果工具
Others
其实上面列出的只是帮助大家搭出脚手架骨架的工具类。如果大家要打造针对自己项目高度定制化真正核心的脚手架，需要的是大家对自己定制化的模板文件的构建和解析能力，其实真正依赖的还是你的webpack，Gulp等项目库的理解和掌握。
结语
胖子希望这篇文章能帮助大家更深入的理解前端脚手架的一些相关知识点，分享一下胖子的想法和认识。下一篇文章打算介绍一下怎么利用上面提及的工具和库实现构建一个简单的脚手架。
如果您有什么问题和建议，欢迎留言。
转载请注明 码农王小胖
