[RFC] Manifest 应做到环境无关

[noahziheng]

基于 #29 的实现，目前会在 Scanner 中依据环境变量生成 Manifest，但通常逻辑中，可能会在构建出 manifest 后在不同环境中运行。

• 目前 pluginConfig 包括 enable/path/package，会直接影响 Manifest 生成结果，且遵循与 config 一致的合并逻辑，这将导致生成阶段的合并变得复杂
• 考虑将 enable 在 scan 阶段剥离，按 path/package 去重后全量扫描，在 load 阶段过滤
  • 这将使得依赖回环检查在 scan 阶段失效，可能有非预期的报错

[DuanPengfei]

@noahziheng 这个是考虑说的：“一次构建产物，根据需求可以部署到多个环境中去的“ 的场景吧？config plugin 都涉及到这些，看你也提了在 load 阶段做 merge 等工作。最后这个依赖回环检查在 scan 阶段失效，是怎么理解呢？

[hyj1991]

@DuanPengfei 这个指的是 scanner 里不处理 env 相关的文件过滤，env 的逻辑放到启动期判断，这样可以实现一份 mainfest 多环境部署。

[noahziheng]

@DuanPengfei “依赖回环检查在 scan 阶段失效”指的是现在计算插件排序的时候利用拓扑排序检测回环，这个机制依赖enable和dependency，如果scan阶段环境无关，那就需要不同环境的path/package对应的meta都要纳入算序流程且enable默认为true，那这个阶段的回环检测就没有实际意义了

[DuanPengfei]

@noahziheng @hyj1991 那是不是可以理解，如果要做到构建时环境无关，还要能够检测出插件的依赖顺序和 enable 是否存在错误，就需要把扫描到的 ${config 路径} 下的 plugin.default.ts 和其他 plugin.${env}.ts 都尝试合并一下，再去分别计算一下依赖判断是否存在错误，并且可能需要提供在 items 里的内容也需要有环境的标识？

如果 scanner 不做这个，那就要启动前再做一次 plugin 加载顺序的计算？

这个也就是我们把 scanner 放入到构建期间，想要一个更好的启动速度，而引入的需要解决的问题？

[DuanPengfei]

@noahziheng @hyj1991 那是不是可以理解，如果要做到构建时环境无关，还要能够检测出插件的依赖顺序和 enable 是否存在错误，就需要把扫描到的 ${config 路径} 下的 plugin.default.ts 和其他 plugin.${env}.ts 都尝试合并一下，再去分别计算一下依赖判断是否存在错误，并且可能需要提供在 items 里的内容也需要有环境的标识？

如果 scanner 不做这个，那就要启动前再做一次 plugin 加载顺序的计算？

这个也就是我们把 scanner 放入到构建期间，想要一个更好的启动速度，而引入的需要解决的问题？

那其实还不止 plugin 吧，跟 env 联动，有 merge 等需求的，如：config，都会出现这种问题？

[noahziheng]

@noahziheng @hyj1991 那是不是可以理解，如果要做到构建时环境无关，还要能够检测出插件的依赖顺序和 enable 是否存在错误，就需要把扫描到的 ${config 路径} 下的 plugin.default.ts 和其他 plugin.${env}.ts 都尝试合并一下，再去分别计算一下依赖判断是否存在错误，并且可能需要提供在 items 里的内容也需要有环境的标识？

如果 scanner 不做这个，那就要启动前再做一次 plugin 加载顺序的计算？

这个也就是我们把 scanner 放入到构建期间，想要一个更好的启动速度，而引入的需要解决的问题？

是的，scanner 内计算需要更严谨的逻辑，启动前再计算一遍成本更高，items 就白改了

[DuanPengfei]

@atian25 @whxaxes 可以关注下这个问题，通过多环境部署引出的无法仅在构建阶段做扫描，启动阶段可能也需要做一些工作，但是又与我们想追求的构建阶段处理好这些计算工作，启动阶段可以性能更优，并且不用做重复工作这一个想法有些冲突。有什么好建议也一起聊聊看。

[noahziheng]

那其实还不止 plugin 吧，跟 env 联动，有 merge 等需求的，如：config，都会出现这种问题？

@DuanPengfei config 还好，因为默认都是要生效的，manifest 本来就会拿全量进去，启动时才会真实地合并，plugin 就完全不同，enable 和加载的 path 会直接影响 manifest 的内容

[DuanPengfei]

那其实还不止 plugin 吧，跟 env 联动，有 merge 等需求的，如：config，都会出现这种问题？

@DuanPengfei config 还好，因为默认都是要生效的，manifest 本来就会拿全量进去，启动时才会真实地合并，plugin 就完全不同，enable 和加载的 path 会直接影响 manifest 的内容

@noahziheng @hyj1991 那 scanner 忽略单一环境，把已经声明的所有 plugin.${env}.ts 都扫一遍，然后 items 里给个 env 的标识做区分，manifest 相当于多了一些冗余信息，启动时再读取，这个思路可行吗？

[noahziheng]

@noahziheng @hyj1991 那 scanner 忽略单一环境，把已经声明的所有 plugin.${env}.ts 都扫一遍，然后 items 里给个 env 的标识做区分，manifest 相当于多了一些冗余信息，启动时再读取，这个思路可行吗？

@DuanPengfei 前面已经提过，这是可行方案，但因为 pluginConfig 内的 enable 和 path/package 干扰，这个方案没有想象地这么简单

[DuanPengfei]

@noahziheng @hyj1991 那 scanner 忽略单一环境，把已经声明的所有 plugin.${env}.ts 都扫一遍，然后 items 里给个 env 的标识做区分，manifest 相当于多了一些冗余信息，启动时再读取，这个思路可行吗？

@DuanPengfei 前面已经提过，这是可行方案，但因为 pluginConfig 内的 enable 和 path/package 干扰，这个方案没有想象地这么简单

嗯嗯，可以简单写个 demo 吗？

[noahziheng]

@DuanPengfei 我在尝试写，但是逻辑还没理清，提 RFC 的目的就是先列在这里供讨论，思考一下再提 PR

[hyj1991]

经过讨论，已经修改为环境有关