todoList
- 确认文件名是否重复，重复就提示是否覆盖（已完成）
- 选择语言，（不选择版本，默认最新，因为脚手架生成后可以自己安装想要的版本）(已完成)
- 选择项目类型（组件、后台、原生工具）（已完成）
- 组件、后台（vue ｜ react
-
- 是否使用UI框架
- 原生工具 （node | browser）
- 选择配套工具(eslint\axios)
- 拉取基础模版
- 内存中组合加工
- 生成项目
实现要点：
- 使用一个class来保存配置上下文
- 每个步骤穿插进度条
- 在加工环节尽可能设计成插件形式，方便以后拓展
-- 插件系统todo：
- 重写上下文管理器，需要使用传入类型来设置自身配置接口
- 划分生命周期
- 意味着需要编写一个event类实现钩子订阅
- 确定插件的形式(是一个function，参数有hook钩子注册器、当前上下文配置内容、附带工具类)
- 使用钩子形式广播不同不同生命周期事件供插件使用
- init逻辑里调用钩子以遍历形式调用（可能有多个插件注册了同一个钩子）
- 插件间的参数应该有流向关系，插件本身具有顺序关系
2020.12.04: todo:
- 从init钩子开始改造，把ctx的内容结构和行为定义好
- Plugin的两种方式（函数or对象）做好解析，第二个参数的utils需要做一层整合
- 对象类型的Plugin要做解析，把各个属性注册到钩子中，提供的参数要把该生命周期自带的和utils整合一起
2020.12.07: todo:
- 钩子注册内容暂时还没做到上下文链式取值(已完成)
- 考虑用洋葱模式执行plugin(不需要，没有折返需求)
2020.12.09:
- 需要设计一种节点构成文件依赖树，并且这棵树能100%用于生成文件，所以这种节点应该能清楚地描述本身内容以及路径关系
- 开发一个complier类用于将文件依赖树转化为文件
- 开发一个parser，将配置转化为文件依赖树，相当于对每个配置进行节点转换
2020.12.15:
- 在parse的生命周期中，不用所有插件都注册这个事件，完全可以在最后一个插件中才注册，统一决定输出的配置文件
- 想了一下，其实parse的ruleSetter最好直接返回fileNode，这样就相当于定义好了文件目录结构
- 在utils中需要加入git-download、fileNodeCreator等工具函数
2020.12.17:
- shit，不能把git下来的内容放到内存里，会引起node内存爆栈，考虑将git相关逻辑配置成基础模版的模式，在init阶段就要设置好，然后在parse阶段自动将git下来的模版解析成fileTree，供后续使用！
- 需要在init中增加对基础模版的配置
- 2020.12.15的所有内容都还没开始做呢！！！
2020.12.19
- 原来download-git-repo没有类型文件，但是其实源码也不多，试着自己实现一下看看有没有突破口把文件写入内存
- utilsLib中加入下载模版工具
2020.12.21
- 看了一下download-git-repo原理，其实用的是child-process库走命令行形式下载，其实可以考虑结合memfs看看能不能实现把仓库下载到内存中，然后再解析成fileTree
- 需要在init过程中，加入下载模版的逻辑
2020.12.22
- 现在暂时确定parseNode里的operate方法一定要返回fileNode，具体fileNode的构造器会在complier里完成并通过UtilLib提供出去
- 拉取模版下来后，还需要对本地目录进行依次解析为fileTree的逻辑，目前没什么头绪。。。
2020.12.27
- 把fileNode的创建方法完全搬到了UtilsLib中，基本确定了只保证parse过程中的ruleSetter一定接收一个key和fileNode组成一个对象，保存在一个数组中供解析
- ruleSetter本身还缺乏一些边界校验
- 拉取模版后如何解析成fileTree还没想好。。。
2020.12.29
- 勉强是把git模版拉取逻辑跑通，但是子进程报错问题没解决
2020.01.06
- 搞半天原来是以为download-git-repo库里把git地址的分支做了兼容默认写死了master，但是新的github已经改成main分支了，导致下载完之后checkout 报错，子进程无法退出，淦！
2020.01.07
- 开始动手写关于fileTree的解析逻辑，目前要弄清楚fs的readdir返回内容，做递归解析才行
2021.01.21
- 过了一个年，对parse生命周期的设计有了新的看法，其实应该在parse中建立存出一个{config:function}这样的对应关系，每一个配置运行它对应的函数，函数的参数里提供Utils、config上下文，以及从template解析出来的fileTree
- 最容易拓展和最高程度定制的手段，应该是从parse开始就让开发者参与编辑fileTree
- fileTree在最后转化成文件目录的时候其实可以做一层校验扫描来防止开发者的误操作
2021.01.30
- fileNode的实现不能简单用对象来实现，因为在outpur阶段十分耗性能，需要做一些编译前优化，因此需要做区分改fileNode有没有被改动过或者还存不存在，借此跳过该节点的遍历提高性能
2021.02.14 55555今天虽然是情人节，但是对我来说就是年初三。。。不过好消息是脚手架生成成器的主体逻辑已经基本完成了。。。
- 有一个纠结的点是，整体项目文件目录生成完后，安装依赖的行为应该是内部自动自行，还是应该暴露多一个钩子让外部自行决定？
- 如果让外部自行决定项目生成后的额外操作，那么连package.json的编辑也可以放在外部让开发者自己编写了
- 这个脚手架生成器难道只能用于js项目吗。。。本质是从github拉取一个简单模版，通过自己自定义的任务在拉取后插入各种文件及创建新目录以完成最终的项目结构，理论上是不应该局限在哪种语言的，所以对于package.json的依赖安装是否放在内部直接影响了这个生成器使用场景的局限性
2021.02.21 跑是可以跑起来了，但是运行完后的GC提示内存泄漏，慢慢找原因把，定位在complier的解析本地fileNode阶段
2021.03.16 fileNode的操作太不方便了，考虑按照graph的形式包装一层，查找和修改都由fileTree提供，最终生成文件目录也用这个fileTree