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