因此构建能力也被抽离成单独的 npm 包，模板中可指定其构建包
3.7 多人合作项目，能确保构建结果一致
因为存在多版本，我们需要约束，让所有项目的贡献者的产出是一致的
其核心原则就是：针对那些可能导致差异的因素，我们都收录到工程中，让 git 仓库记录，从而实现同样，因此，现在流行的脚手架，如 umi taro，都将 构建能力 local 化到本地工程中，后续会做详细阐明
4 脚手架的三类包
一个被实践检验，能够符合上述需求的脚手架架构，其实非常简单，首先我们拆分成三类 npm 包：
| 包 | 功能 | 安装位置 | 备注 |
|---|---|---|---|
| 全局命令包 | 就像一个大脑，负责响应全局命令，并进行调度 | 全局包路径 | global 安装，提供全局命令 |
| 模板插件包 | 初始化工程所拷贝的模板 | 某个约定路径，如 ~/.maoda | 模板可随业务扩展 |
| 构建插件包 | 提供构建(webpack)能力 | 工程内 (目前主流脚手架都改用此方案) | 不同模板可使用同一构建包，也可不同 |
注：构建插件包，早期很多脚手架都把它放在工程外，比如放在全局，优势是多工程可复用一套 webpack 能力，但弊端也暴露出来，即在多人协同开发的项目中，由于构建插件包不在工程里没能被 git 仓库收录，导致一些不可预期的差异结果。
其调度关系如下：
5 全局命令包
前面说了一通理论，下面开始正式搭建
全局命令包的功能：负责接收全局命令，并调度。
比如我做的 cli 的模板 demo cli-tpl
npm i cli-tpl -g# 或 yarn global add cli-tpl
全局安装后，暴露出一个 dcli 命令 (自己随便取的名字)，该命令有以下典型功能：
暴露全局命令通过 package.json 中 bin 来指定，可参考我的 demo
| 命令 | 效果 |
|---|---|
dcli install [pkgName] | 安装一个「模板插件包」到 ~/.maoda 路径，如果已经安装再执行，则询问更新到最新版，如安装 dcli install gen-tpl |
dcli init | 以某个模板初始化一个新工程，执行后会让你从已装模板里选择 |
dcli build | 在工程根目录执行 (或写进工程的 scripts 里)，尝试读取工程依赖的「构建插件包」并执行构建 |
dcli dev | 与 dcli build 类似，只不过是执行调试 |
5.1 cli 开发中值得收藏的一些第三方调料包
