脚手架的功能和本质
ziwei3749 opened this issue · comments
脚手架的功能和本质
2.1脚手架的功能和本质
-
脚手架的功能： 快速创建项目的文件和目录
-
脚手架的本质： 方案的封装
我们可以自己选择用什么框架、是否需要前端路由、是否用css预编译器，用less还是sass。
我们通过传递给脚手架一些参数配置，最终生成一个合适的方案。
所以说脚手架是对方案的封装。
2.2脚手架在前端工程中的角色和特征
2.2.1用完即弃的发起者角色
脚手架 --> 开发（本地服务器） --> 构建 --> 部署测试 --> 测试 --> 部署上线
前端工程化并不是vue全家桶或者react全家桶，而是一种服务，是辅助性质的。
辅助的是一线的业务开发人员，在一套合理的前端开发体系下，让开发人员只需要
把精力放在业务开发上。即时公司给出了明确的文档，也不应该强制要求每一个开
发人员花太多时间学习配置细节，比如公司明确了一套规范，告诉开发人员，应该
如何配置eslint，如何配置sass，如何部署，这些都不如一个脚手架直接生成统
一标准的方案配置
所以脚手架要解决的问题就是：
- 快速生成配置
- 降低学习框架的成本
- 让开发人员关注业务逻辑本身。
比如vue-cli，就不用了解vue-loader的细节。什么vue分别运行时和完整版，如果引入vue-router在自己的项目里，脚手架已经帮你下载、配置，甚至打好样了。
随着前端工程提供功能越来越多，需求越来越复杂，脚手架的威力也为越来越大。
配置一个简单的index.html肯定不需要脚手架。
2.2.2 局限于本地的执行环境
前端工程化的3个阶段
- 本地工具链
- 云管理平台
- 持续集成
三者区别： 各个功能模块的执行环境不同。
执行环境分4类：
- 本地环境
- 集成平台环境
- 测试环境
- 生产环境
其中测试环境和生产环境，与开发无关，所无论处于工程化哪个阶段，各个功能模块的执行环境的划分都是一致的
- 本地工具链阶段的前端工程化，开发、构建、部署测试都在本地环境
- 云管理平台阶段的前端工程化，把构建和部署测试放在集成平台
所以，无论是最简单的本地工具链还是持续集成，脚手架的执行环境都是在本地环境，这给脚手架工具带了一个必须解决的问题： 操作系统的兼容性
2.2.3 多样性的实现模式
因为前端可以选择的技术组合太多了，脚手架没有一个通过一的规范。
比如vue-cli和create-react-app各不相同。
但是优秀的脚手架工具往往有一下原则：
- 从功能实现角度
- 与构建。来发、部署等功能模块联动，在创建项目时自动对应配置项
- 自动安装依赖
- 从平台角度
- 动态可配置
- 底层高度可拓展
- 从易用性角度
- 丰富但不烦琐的配置项
- 支持多种运行环境，比如命令行和Node.js api
- 兼容各种主流操作系统
丰富不烦琐： 比如create-react-app，只开放一个swich给用户，而且不管siwtch是否打开，都是有默认值的。
2.3 开源脚手架案例剖析
介绍3个比较典型的案例，都是成熟的脚手架方案
- Sails.js ------ Node全栈MVC框架
- PHP中间层 ------ 只包括Controller和View的Web服务中间层框架，类似大前端
- Yeoman ------ 开发的脚手架平台，不封装任何具体方案
Yeoman提供了一整套完整的脚手架开发API，使用这个API可以定制符合自己业务需求的任意脚手架方案。
如果你需要开发一个属于自己IDE脚手架，Yeoman是最好的选择