微服务组件二方包和三方包的爱恨情仇

环境

next.js

背景

业务逐渐复杂起来，微服务组件代码如何更优雅的设计，成了今天的重点，之前写过一篇 记一次微服务组件下沉 ，当时用的npm包的形式，实际上远比文章中的踩坑多很多（主要原因环境比较重不适合三方包），比如各站点接入的不同的坑也不方便记录在博客。
简而言之，npm还是适合不要带太多副作用的场景下使用，在复杂组件下沉的开发实测module-federation会方便很多。

冲突

1.如果等各个公共组件（少无所谓，组件逐渐多和复杂起来）留在各个站点，会影响站点热更和打包部署时间和体积，大大的影响了效率，特别是为了seo+多语言的项目，SSG构建的时间和体积o(n)的增长…

2.所以module-federation得单独拆出来专门一个仓库远程包。

3.这下1的问题解决了，但是新问题是各组件交叉引用，以及强要求LCP的组件还必须留在子站然后组合远程包组件再module-federation出去给别的子站来用，下面称之为嵌套打包。

4.嵌套打包在复杂场景下会有问题，不仅仅是模块加载失败/多实例冲突/生产环境缓存等常见问题，除开必要解决这个问题，还需要补齐开发规范，注意代码设计，联邦嵌套不可超过2层。

调研

1.next嵌套打包是失败的, fe3=>fe2,fe2=>fe1,fe3=>fe1都是ok的，fe3=>fe2=>fe1的时候会报错找不到fe1，实际上fe2共享出去的代码是只有引入fe1的代码，并没有fe1内容的代码。但是fe3会在自己的chunks去找fe1，哪怕通过script引入fe1也找不到，因为原代码引入fe1通过webpack改名了，此时加载的资源也是比前面三种情况多很多。见代码：https://github.com/duuliy/next-project-template/tree/dev-module-next2

2.在react里面就没有问题。见代码：https://github.com/duuliy/react-next/tree/master/react-module-federation

3.next+federation/nextjs-mf 是可以嵌套打包的：https://github.com/duuliy/next-project-template/tree/dev-module-next3

解决思路

除开各第三方需要处理，最主要的是federation/nextjs-mf和module-federation/runtime里面的方法不能混用，原因不赘述了，多了解下原理就知道了