MorningStar0

@weijiagege
@corianderHunter
一个问题，你们的微前端项目不包括 monorepo 么？也不包括构建方式更改？
而且标题这里的 “从 CRA 将 react 项目迁移成微前端项目-1” 和副标题这里的 “从 CRA 将 react 项目迁移成微前端项目 —— 目录结构的确定和构建方式的更改”，这俩说明不了这篇是主要讲目录结构和构建更改的吗？

然后这个主题提到的 “在主项目中引用抽离的项目”，引用子应用的方式，包括我在#15 、#9 的回复，应该不难看出这个项目拆分完成的结果吧

@MorningStar0
@alexsunxl
这不意味着我否定技术栈无关这点，但我确实不想引入其他技术栈。虽然这在我通过#15 层提供的沙箱方案可以解决。
并且我觉得不一定要严格要求通过 **路由层** 解决 collection 的问题。

@alexsunxl 这里源引 https://micro-frontends.org/来解释下。
> Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.
翻译：微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
我可能更侧重独立发布功能和#12 中提到的需求

@zhaol 确实比较麻烦，我的解决方案是将带有 context 的功能，作为单独的 module 打包，然后在构建的时候，保持这个 context 的唯一实例。

@lrwlf 可能我这个 blog 中给出的例子确实更像模块联邦😂

@musi 沙箱还是需要的，我这里目前的方案是，将通过 new Function 加载的远程库，把它的 context 绑定到一个 object 下，这个 object 提供了一些允许调用全局变量。

@MorningStar0 #9 至于微前端玩烂了，还有 ali 的技术观点，其实不太影响我。总的来说 我的需求对于微前端时刚需，这点是指我在 blog 中提到的
“对于不同用户，同一个包需要在运行时 提供不同的版本”。

@musi 呃我理解，微前端也包含我提到的这部分吧，而且我就是记录下自己实践的部分，blog 中提到的后续计划，已经在开发中了。
通过网络动态引用的部分已经完成了，只是其他计划还没有完成，我觉得不适合单独写一个专题。
动态引用的代码，在仓库中的 dynamic-import module 中