记一次微服务组件下沉

环境

next.js

方案

1.二方包模块联邦：@module-federation/nextjs-mf
优点：简单接入，既可在各微服务使用，且支持ssr。
缺点：没有版本控制，各微服务站不能自由选择版本，有部分三方包的坑。

2.三方包（npm）：
优点：物理隔离，版本控制。
缺点：除开代码，插件的坑之外，集成了多业务代码的组件还需要兼容各个不同环境的坑。

开发流程

1.三方包内开发（无可视化界面）
2.编译打包
3.yarn link 业务各微服务子站接入验证
4.rc发布，开发-测试=》验证
5.正式版本发布=〉预发验证
6.上线+定点接入=》A/B测试
7.各微服务接入

踩坑

1.storybook 没支持next环境下相关配套插件。解决办法：yarn link
2.转ts 规则设定与正式环境不同。临时解决办法：改代码兼容
3.相关内部三方包内方法依赖依赖未提前下沉。解决办法：多方合作下沉
4.swr（业务站 1.3.0 和 三方包2.0 ）导致下沉hooks方法出入参结构变化。解决办法：统一插件版本
5.三方包不支持next相关插件：国际化（next-translate）。解决办法：自定义转换+语言传入
6.三方包不支持ahooks多方配置：响应式（configResponsive）。解决办法：尺寸传入
7.业务站与三方包不能共享全局变量。解决办法：参数传入
8.网络io（带轮询）在三方包使用时才初始化总是比state监听更慢。解决办法：此接口参数外部持久化并传入
9.本地接入 yarn link 报错Object.defineProperty called on non-object。解决办法：除开组件的三方包，还有组件使用了的方法所在的三方包等地需要统一源地址
10.别的next.js微服务站报错 Object.defineProperty called on non-object。解决办法：next-transpile-modules 二次编译三方包

tips:

next-transpile-modules: 把包中，next.js 不友好的代码编程成友好代码。eg：1.ES6导入从NPM模块进行代码转换。2.一个带有styleguide包的monoreo