[WIP] framework & plugin 全量目录支持启动后按 env 加载

[hyj1991]

framework 在实践中逐渐倾向于 application runtime 的概念，通俗的说即提供 application 运行所需的各种对接基础设施的能力。

在这种场景下，存在同一个 application 希望根据不同的 env（此 env 非 test / prod，而是指独立的各个部署环境）选择不同的 framework，一个例子是：

• 某应用使用了 oss，内部 framework 提供了 oss plugin
• 新增需求需要进行其他环境的私有化部署，无法直接使用原来的 framework

将 framework 设计的更为灵活，支持通过 env 来选择继承链路即可从 core 层面满足这种需求，目前这种基于 scanner 扫描 manifest 的方式，可以更加优雅进行支持。

更多的，framework.${env}.ts 有别于其余配置的，它不需要合并，从 app - framework1 - framework2 每一级根据 env 配置选择需要使用的 framework dir 即可

Plugin 存在同样的问题，需要对 scanner 全量扫描的目录在启动期进行按照 env 的过滤。

[hyj1991]

cc @atian25 @fengmk2

[DuanPengfei]

这个思路有点意思，我再读几遍，哈哈哈。

[noahziheng]

@hyj1991 听起来只是需要把 framework 这组配置特殊化，不进行 deepMerge 就能实现？

目前 #43 的实现相当重，在 manifest 和 load 中各进行了大规模的重新遍历来单独处理 framework，个人理解上看相当不优雅，原因是啥

[hyj1991]

@noahziheng load 中的逻辑并没有变化，只是把之前的 const of 这种单循环动态添加 framework 改成递归方法了而已

[hyj1991]

manifest 的变动主要是因为 scanner 是全量扫描，也就是所有 framework (不管需不需要使用)涉及到的 dir 文件都会扫描进来，那么就带来一些比较重要的问题：

• 配置合并，实际上 load 加载的时候并不需要去合并无需使用的 framework 的配置文件
• extension 生命周期 hook（例如 didLoad 里可能执行的 http server），这个也不能让不使用的 framework 注册

这里的重实际上是为了支持 scanner 全量扫描，执行期通过 env 来解决哪些文件需要被加载，带来的好处就是一份构建，可以在多个环境部署（manifest 是全量的）

[hyj1991]

从执行的开销上看，目前在 load 阶段只是多了一个过滤无需执行的 framework dir 文件的动作，其余开销和以前的模式是一致的

[noahziheng]

@hyj1991 看起来和 #33 中 plugin 之前说的场景是类似的，是不是可以采用类似的做法搞个通用的机制，现在把 framework 特殊化感觉意义没有很大（当然这可能和包袱有关）

[hyj1991]

其实这个也不是包袱，我们以前的 framework 只能单线继承，就是之前 framework pr 的实现；只不过单线继承就是带来这个 issue 描述的困扰，以至于我们要在内部抽象 layer 的概念（平级的可选 framework）来 hack

#43 其实就是想在 core 解决这种场景

[hyj1991]

另外，如果我们能达成共识：manifest 应当是 env 无关的，可以在 #43 的基础上设计一个更加的通用的方案

[JerrysShan]

另外，如果我们能达成共识：manifest 应当是 env 无关的，可以在 #43 的基础上设计一个更加的通用的方案

现在 plugin 应该是根据 env 进行过滤了，scanner 阶段全量扫描比较好，这样在 build 阶段的产物在不同 env 环境能够复用

[hyj1991]

@JerrysShan framework 现在是全量扫描，启动期根据 env 过滤，我在 #43 把 plugin 也加进来，做个更加通用的方案