许多团队在制定前端工程方案时会加入脚手架模块。虽然不一样的团队对工程化的理解和实施有所差别，可是对于脚手架的定位基本是一致的：建立项目初始文件。这是一条看起来十分简单地准则，可是对于这条准则应该如何理解，如何实施却并非一件很简单地事情。php
在探索这条准则的深度以前，咱们不妨看看相似的一些成熟方案，好比Eclipse。这个大名鼎鼎的IDE软件被不少Java和Android开发者使用。经过Eclipse建立一个新项目时，它提供了丰富的配置项，这些配置项能够概括简化为如下流程：选择项目类型 -> 选择项目目录 -> 配置项目细节 -> 最终确认 -> 完成。这是脚手架最基本也是必须具有的流程。从这个流程中能够总结出脚手架的本质：方案的封装。css
由此，咱们明确了脚手架的定义：脚手架做用是建立项目的初始文件，本质是方案的封装。html
固然，脚手架建立项目流程之中还有不少细节，而且前端项目的多样性和复杂性更加为脚手架流程的实现增长了难度。这篇文章简单阐述一下笔者的一些浅见，但愿可以给你们一些启发。前端
1. 脚手架在前端工程中的角色
1.1 “用完即弃”的脚手架
以前写过一篇浅析前端工程化，简单介绍了前端工做流模型，简化以后能够用下图归纳：
node
脚手架在前端工做流中负责项目起始阶段建立初始文件。与其余功能模块不一样的是，脚手架是一个彻底“启下”的模块，它没有任何前置依赖。建立完成项目初始文件以后，脚手架就再无用武之地了。web
“用完即弃”的工做模式令脚手架的实现由很大的跃迁性。你能够用最简单的复制粘贴就能完成脚手架的工做，而一个完备、成熟的脚手架即便提供了很是丰富的交互配置，最终目的也“只”是建立了一堆初始的项目文件。既然结果同样，那为何还要花费时间和人力成品去开发复杂的脚手架方案呢？数据库
跃迁是量子力学术语，意思是状态发生跳跃式变化的过程。之因此将这个词用在这里是由于高度完备的脚手架相比较低级形态的脚手架而言，可以带来质的飞跃。前端工程化
这是一个很是现实的问题，互联网产品迭代的快速节奏下，开发团队最注重的就是投入产出比，而脚手架的投入产出比“看上去”是最低的。环顾目前前端的工具生态，最多的是构建工具，固然咱们不能否定构建确实是最复杂的功能。而脚手架工具是最少的，前端社区对脚手架的讨论也很是稀少。你可能据说过大名鼎鼎的yeoman，可是很难再想出第二个脚手架工具了。api
单独来看，脚手架可能并不具有很高的“性价比”，但若是你的团队有一套完整的前端工程体系，脚手架的做用就会被放大。前端工程体系的功能涵盖范围广，封装的方案类型多，对应的配置项也很是复杂。并且，大多数前端工程体系的开发者并非一线的业务开发者。对于业务开发者来讲，这套工程体系就是一个黑盒，他们不须要了解其中的复杂原理，只须要知道如何配置便可。因此业务开发者的需求就是快速开发快速配置，而且生成的配置项跟项目要对应，既要知足项目的功能需求，又不能有“混淆视听”的冗余功能。浏览器
前端工程体系不是Vue、React这种开发框架，工程体系只是一种“服务”，是辅助性质的。学习曲线应该平缓，即便文档再清晰易懂，也不该该要求业务开发者去花时间学习各类细节。这就是脚手架要解决的切实问题，简单说就是：
- 快速生成配置；
- 下降框架学习成本。
随着前端工程体系愈来愈复杂，脚手架的角色会愈来愈重要。
1.2 脚手架须要具有的要素
1.2.1 执行环境仅限本地
在讨论实现一个脚手架要考虑哪些要素以前，咱们不妨先看看脚手架的执行环境。回顾前文提到的简易前端工做流，最简单的情形是：框架提供一套完整的本地工具链，脚手架、开发、开发服务器、构建和部署测试都是在本地环境执行，以下图：
进一步的团队会搭建CI（持续集成）平台，将构建和部署功能迁移至云端，这样作便于工做流程控制和代码统一管理。以下图：
不论哪一种工做流，脚手架始终是在本地执行。
1.2.2 模式不固定
前端脚手架之因此没有固定的模式，是因为不一样的公司对于前端工程师的定位不固定。好比有些公司的前端仍然是“切图仔”；有些公司的前端负责浏览器端的全部逻辑开发可是html模板层仍然由服务端工程师维护；还有些比较前沿的团队提倡“大前端”，负责浏览器层与中间层（主要承载html的渲染功能）。前端工程师定位的不固定形成了前端项目模式的不固定，脚手架天然也具有了多样性。
不管是哪一种工做模式，一个优秀的前端脚手架都应该具有如下几点要素：
- 丰富但不繁琐的配置项；
- 与其余功能模块联动，生成对应的基本配置项；
- 自动安装依赖；
- 底层的高度可扩展性；
- 支持多种运行环境，好比命令行和Node.js API。
如何理解“丰富但不繁琐”呢？举个例子，假设构建功能支持自动生成css sprites，配置项有两个：
- 是否启用css sprites；
- 指定散列icon目录。
脚手架在实现针对css sprites的配置项时是否是应该将这两个配置都开放给用户配置呢？显然是不须要的，脚手架只要开放是否启用css sprites的配置项便可，由于这是影响这项功能最重要的一点，散列icon的目录即便用户不配置，使用默认的方案也不会形成任何不便。
另外，在实现脚手架时不该该只看到当前的需求，还应该考虑后续需求的变动和新增。因此一个优秀的脚手架应该具有高度的可扩展性，便于定制不一样类型的方案。从这个角度来讲，目前yeoman是作得最好的。
2. 开源前端脚手架方案剖析
明确了脚手架的基本工做模式，咱们不妨看看目前业内有哪些能够借鉴的案例。咱们在这里介绍三种形态的脚手架：
- sails是一个Node.js fullstack框架，其使用的sails generate脚手架主要是针对服务端代码设计；
- 优酷PHP中间层框架是笔者前团队使用的开发框架，目前并未开源。其使用的脚手架相对sails来讲比较简单，只能建立一个完整的webapp，包括Controller层和浏览器层代码；
- yeoman是广为人知的开源脚手架工具，它自己不提供任何直接建立文件的功能，而是一个脚手架底层框架，你能够定制本身的脚手架实现。
其中两个是开源项目，你们能够在Github上获取对应的源码。
2.1 sails - Node.js fullstack框架
sails是一个Node.js全栈框架，服务端使用MVC架构。sails generate是sails的脚手架模块，默承认以建立如下几种模块的初始代码：
- app - 建立一个新sails项目；
- api - 建立一对model和controller；
- model - 建立一个model；
- controller - 建立一个controller；
- adapter - 建立一个adapter；
- generator - 建立一个脚手架模板。
sails框架中的Adapter能够简单理解为简化model操做API的映射适配器。
你们注意最后一种类型：generator。sails在默认的脚手架基础上，开放了自定义脚手架模板的API。
sails默认的脚手架大都是针对服务端代码的，若是不借助其余脚手架模板，浏览器端的代码（JavaScript/CSS/Views）只能手动添加。
2.2 优酷 - PHP中间层框架
优酷的PHP中间层框架并未开源，因此就粗略的介绍一下吧。
中间层框架不涉及Model层，不涉及数据库操做，只包括Controller和View层。这个框架的理念是：任何一个模块都被视为一个webapp，每一个webapp都是一个SPA，好比登陆/注册模块Passport、订阅模块Subscribe等。脚手架只能建立一种文件类型：一个完整的webapp。其中包括Controller文件、Resource文件（浏览器层）和路由配置文件。
因为每一个模块webapp都是一个SPA，包含一个Controller文件，一个view入口文件、一个入口js文件和一个css文件，因此脚手架建立的初始文件就已经够用了，开发者只须要手动添加子模块文件便可。同时，技术栈统一，build功能封装完备，不须要额外配置。这种形态的脚手架基本知足了优酷PHP中间层框架的需求。
2.3 yeoman - 多是最好的开源脚手架框架
提起脚手架这三个字就不得不提yeoman这名老将。Yeoman在2012年Google I/O上首次发布，至今已经5年的光景了。对于前端技术圈子来讲，5年的时间可让绝大部分的技术遭到淘汰，而yeoman坚持到了今天，且扔未现衰退之势。咱们能够短暂回顾一下5年前的前端技术，你可能会想到Knockout和Backbone，也可能会想到YUI 3，甚至可能会想起被ExtJS所支配的恐怖。而后再看看这些在当时热火朝天的技术目前的市场状态，是否都已经是昨日黄花垂垂老矣？而yeoman之因此能“活”这么久，得益于它明确的定位。
yeoman的slogan是“THE WEB'S SCAFFOLDING TOOL FOR MODERN WEBAPPS”-脚手架工具，但我我的认为称之为脚手架框架更为合适。yeoman不能直接建立项目文件，它提供了一套完整的开发脚手架API，你能够经过这些API定制符合本身业务需求的任意的脚手架方案。换句话说，yeoman不封装任何方案，它是彻底开放、高度可扩展的。
yeoman的API具有了前文所列出的脚手架须要具有的全部要素，若是你须要开发一个属于本身的脚手架，yeoman是最好的选择。后续的博文会详细介绍如何使用yeoman提供的Node.js API将其集成到工程化框架中。
3. 总结
虽然前端脚手架没有固定形态，可是有必须具有的要素。从功能实现的角度，要考虑与业务的高度匹配；从底层框架的角度，要具有高度的可扩展性和执行环境多样性支持。
这多是目前针对前端脚手架理念说的废话最多的一篇文章了，哈哈。所述内容都是笔者的一些浅薄的心得，但愿可以给你们一些启发。
PS：作了一个简单地视频分享，你们可使用微信扫描二维码观看。