前端工程化系列之闲谈“脚手架”（中）

时间 2019-11-30

标签前端工程系列闲谈脚手架繁體版

原文原文链接

Version：2019.09.08.v1.2

开篇

你们好，我是王小胖，一个集可爱与智慧于一身的胖子。

当初订的每周至少一篇原创文章的规矩尽可能不破，因此就算不能玩刚出的《怪物猎人：冰原》也要把文章给你们补上。。。

书接上回，上回书说到“前端工程化之脚手架”，谈了一谈胖子认为的前端脚手架的定义和服务内容。此次我们再闲谈一下下面几个问题。

脚手架的还应具有的特质（对以前文章中的一些观点的补充）
常见的脚手架介绍
脚手架实现的思路
制做脚手架可能依赖的相关库

脚手架还应该具有的特质

封装性（隔离性）

引用《前端工程化：体系设计与实践》（好书推荐）书里的一段话，

“前端工程体系的功能涵盖范围广，封装的方案类型多，对应的配置项也很是复杂。并且，大多数前端工程体系的开发者并非一线的业务开发者。对于业务开发者来讲，这套工程体系就是一个黑盒，他们不须要了解其中的复杂原理，只须要知道如何配置便可。因此业务开发者的需求就是快速开发快速配置，而且生成的配置项跟项目要对应，既要知足项目的功能需求，又不能有“混淆视听”的冗余功能。”

封装和隔离，目的就是对非必要的工程化体系的技术细节封装到一个黑盒中，对一线业务开发人员从没必要要的工程体系相关繁琐的工做开发任务隔离开来，提升相关业务人员关注的业务自己，提升专一性，提升生产效率。

兼容性

因为脚手架使用的特殊性，大部分使用场景是在工程师的本地平台上，因此，一个优秀的脚手架，就须要考虑到多个系统平台的支持，理论上讲不能有平台限制（除非这个脚手架是仅仅是服务大家内部项目而且大家公司的开发环境是高度统一的）

灵活性（可扩展性）

针对这个特性，胖子想先强调是针对内部项目或内部业务而产生的客制脚手架，首先是咱们的脚手架应该尽可能具有灵活性和宽展性，那么怎么理解这点呢？

由于如今前端的多样性和复杂性，服务于咱们本身业务项目的脚手架应该考虑以后业务变化带来的技术更替，要考虑技术兼容的问题，因此一个灵活的可配置的脚手架设计就会为从此的升级更新带来便利。在脚手架的设计之初就要考虑到这点，那么为了不过分设计，胖子建议参考下面几点建议。

考虑好你的脚手架的服务生命周期的目标，设计好每一个生命周期阶段的任务，以后再向不一样的生命周期的篮子里填充你的功能，尽可能保持周期之间互不影响。
如引用第三方的模块，尽可能引用第三方模块的原有功能接口，若有成熟的配置工具模块，尽可能调用成熟的模块功能，这样在以后的技术更新中，若是第三方模块接口不变，咱们就不须要作额外的工做作兼容。
前期尽可能功能不要太多，只提供必要的功能支持，由于功能少就意味着依赖更少，灵活性可控。

业务和工程目标驱动性

补充这点，主要是强调一下脚手架最终的目的是为业务和工程服务的，应该是业务和工程驱动脚手架变化的，而不该该是工程师团队，它不是技术的练兵场和百宝箱，不是任何一个工程师以为一个新技术或新点子不错，就把这些加入到咱们的脚手架里面。脚手架的目的都是纯粹的，“服务业务，提升效率”。

目前任何一个和前端相关的库和框架，ReactJS，VueJS，Express等等的脚手架的目的都是统一和纯粹的，让用户快速上手熟悉它们的东西，下降框架自身的学习成本。推广它们的产品和业务。因此，一个好的脚手架，应该是为业务和工程服务的。

常见的脚手架介绍

下面列出三个业界稍有名气库或框架的脚手架（其实大部分主要仍是提供工程初始化功能的），都是知名框架和库提供的generator脚手架，相信用过相关框架和库的你应该都很熟悉的。

Yeoman

最后一个是yeoman，它的主页上对本身的定义是“用Web脚手架工具构建Web APP，优化你的工做流，让你快速，优雅的Coding！”。其实胖子对其的理解就是一个web app的generator的构建系统，你能够在Yeoman生命周期基础上构建本身的脚手架generator，也能够在它现有的generators（3900+）里查找到你的脚手架快速生成你的web项目。

yeoman.io/

yowebapp.github.io/

脚手架实现思路

其实，脚手架的实现思路，特别是项目初始化脚手架的实现思路，胖子以为套路仍是很简单的。就和要把大象关冰箱里是同样的，总（nong三声啊）共就那么几步。。。这里咱们借鉴一下Yeoman的生命周期来看看实现本身的脚手架咱们须要思考的思路。

初始化：这一步主要是启动脚手架，校验项目的状态，获取一些基本的配置信息等。
获取用户配置：这一步就是经过互动交互的方式获取用户的定制化配置信息。
解析配置信息：处理上一步的用户定制化配置信息，结合项目自身的相关默认配置，生成解析出最终的项目配置。
生成项目模板文件：针对最终生成的项目配置，生成项目的基本模板文件结构。这一步通常有两种经常使用方式生成模板文件，一种是在已有的代码仓库中获取，例如从git上下载下来；另外一种是根据配置动态解析生成模板文件。也有的项目是两种的结合，例如项目的初始文件（例如angualr的component相关文件）直接下载，项目相关的配置文件（例如tsconfig）则动态解析生成。
收尾：这一步简单了，工做作完了，必定要作好清理和还原工做啊。

项目初始化搞定了，剩下的就要思考在前端工程化过程当中各个阶段你的脚手架计划提供的功能feature了，好比本地开发服务器等。这个就是具体需求出具体的解决方案了。

制做脚手架可能依赖的相关库

说完脚手架的实现思路了，那么我们要是开始打造本身的脚手架的化，须要怎么作技术选型呢？这里胖子简单列出一些构建通常的命令行脚手架的库和工具。

基础依赖工具s

NodeJS和ES这里胖子就不用多介绍了吧（能看这篇文章的，估计都没有问题）。

命令行工具库commander.js

命令行界面的完整解决方案。

github.com/tj/commande…

互动命令行工具库Inquirer.js

提供了用户界面和会话问答流程解决方案。

github.com/SBoudrias/I…

命令行美颜工具s

“美颜”，不只能让你的命令行更迷人，主要是能大大的提升你的脚手架的用户体验，谁让我们是作前端的呢？

命令行样式美化工具

github.com/chalk/chalk

加载效果工具

github.com/sindresorhu…

Others

其实上面列出的只是帮助你们搭出脚手架骨架的工具类。若是你们要打造针对本身项目高度定制化真正核心的脚手架，须要的是你们对本身定制化的模板文件的构建和解析能力，其实真正依赖的仍是你的webpack，Gulp等项目库的理解和掌握。

结语

胖子但愿这篇文章能帮助你们更深刻的理解前端脚手架的一些相关知识点，分享一下胖子的想法和认识。下一篇文章打算介绍一下怎么利用上面说起的工具和库实现构建一个简单的脚手架。

若是您有什么问题和建议，欢迎留言。

转载请注明码农王小胖