update: 基于MF的组件化共享工作流

Author: chenjunsheng

source/_posts/2022-11-10-基于MF的组件化共享工作流.md

@@ -18,7 +18,7 @@ date: 2022-11-01 18:13:12
 
 ## 1. 业务研发背景
 
-目前在玲珑产品下有很多个平台，比如说可能有前台、运营平台以及编辑器等。这些平台分别是由不同的团队去进行开发的，并且每个团队都有沉淀自己的一些基础组件或者是业务组件。比如 Button、Select、Modal 等等，其实这些组件都有一些共通的逻辑是可以复用的。
+目前在羚珑产品下有很多个平台，比如说可能有前台、运营平台以及编辑器等。这些平台分别是由不同的团队去进行开发的，并且每个团队都有沉淀自己的一些基础组件或者是业务组件。比如 Button、Select、Modal 等等，其实这些组件都有一些共通的逻辑是可以复用的。
 
 ![img](https://img14.360buyimg.com/ling/jfs/t1/178941/21/30603/90743/636b953dE18780e4a/4269e2f654875023.jpg)
 
@@ -77,7 +77,7 @@ date: 2022-11-01 18:13:12
 
 ![img](https://img13.360buyimg.com/ling/jfs/t1/112303/11/30966/54591/636b95ceEe011d592/4ccb61e1b1847ee2.jpg)
 
-MF 的共享模式，如果运营平台将水印组件以 MF 的方式暴露出去，玲珑前台直接通过异步 chunk 的方式去动态加载后台的组件资源，同时会共享这些组件所依赖的 React，然后它会把这个 React 打包成一个 shared chunk。
+MF 的共享模式，如果运营平台将水印组件以 MF 的方式暴露出去，羚珑前台直接通过异步 chunk 的方式去动态加载后台的组件资源，同时会共享这些组件所依赖的 React，然后它会把这个 React 打包成一个 shared chunk。
 
 ### 3.2 MF Container
 
@@ -91,14 +91,13 @@ MF 的共享模式，如果运营平台将水印组件以 MF 的方式暴露出
 
 具体的路径：首先是前台去加载水印组件，它会先去加载 `remoteEntry.js`，也就是 **Container** 的入口文件。紧接着，它会去拿到调用 get 方法，再去拿水印组件具体的 chunk，同时进行 share scope 的创建，以及将 React 放到它本地的 share scope 里面去。
 
-在这个时候，MF 会去比较原子组件所依赖的 React 版本和玲珑前台依赖的 React 版本是否一致，这里是通过 semver 版本工具库的方式去比较的。如果不一致，假如玲珑前台依赖的 React 版本高于水印组件所依赖的 React 版本，默认会使用版本号更高的那个 React。如果一致，它会优先使用水印组件依赖的 React 版本，因为它在执行 init 方法的时候，会去覆盖前台的 share scope，将水印组件依赖的 React 版本覆盖掉前台的资源，所以它加载的就是水印组件所依赖的 react.js。如果说你想要一个固定的版本的话，也可以在配置里面去配。
+在这个时候，MF 会去比较原子组件所依赖的 React 版本和羚珑前台依赖的 React 版本是否一致，这里是通过 semver 版本工具库的方式去比较的。如果不一致，假如羚珑前台依赖的 React 版本高于水印组件所依赖的 React 版本，默认会使用版本号更高的那个 React。如果一致，它会优先使用水印组件依赖的 React 版本，因为它在执行 init 方法的时候，会去覆盖前台的 share scope，将水印组件依赖的 React 版本覆盖掉前台的资源，所以它加载的就是水印组件所依赖的 react.js。如果说你想要一个固定的版本的话，也可以在配置里面去配。
 
 ![img](https://img30.360buyimg.com/ling/jfs/t1/145942/23/30944/77065/636b95ceE6cb62421/4ee5562f03856da5.jpg)
 
 接下来，了解下对应的 webpack 配置。首先一体化平台这里需要新增一个 webpack 5 内置的 ModuleFederationPlugin，然后进行这个插件的配置。如上图右侧所示，name 就是导出的资源名称，filename 就是入口文件，exposes 配置是需要导出的组件以及对应的目录，最后再将需要共享依赖的库放到 shared 里去。因为多个版本 React 的运行时实例对于 React 来说是敏感的，一般情况下只能存在一个版本的 React ，所以这里需要将它放到共享依赖里去。
 
-
-那如何使用呢？玲珑前台在加载的时候，也是需要新增 webpack 5 内置的 ModuleFederationPlugin，然后配置 remote 远程资源地址，也就是运营平台的 `remoteEntry.js`。
+那如何使用呢？羚珑前台在加载的时候，也是需要新增 webpack 5 内置的 ModuleFederationPlugin，然后配置 remote 远程资源地址，也就是运营平台的 `remoteEntry.js`。
 
 ![img](https://img20.360buyimg.com/ling/jfs/t1/174371/10/29752/81585/636b95e9E9265028b/5b3e42f29108c90b.jpg)
 
@@ -198,7 +197,7 @@ mf import xxx
 
 因为 MF 更新是实时更新，只要发布了就会更新，我们也提供版本化的功能，类似 NPM 的版本流程，但区别是无需更新版本后重装依赖。有时线上的某个 MF 资源非常重要，为了确保发布之后不会出现问题，可以打开发布控制功能，它可以限制团队里的成员随意发布 MF 资源。
 
-![img](https://img30.360buyimg.com/ling/jfs/t1/133270/11/32869/75452/636b96dbEdc1b0f17/51afdb0f43831a59.jpg)
+![img](https://img12.360buyimg.com/ling/jfs/t1/87939/15/33102/75050/636c97b9Eb9c9c9ba/b5225c32744fa9fb.jpg)
 
 如果说你的组件库打开了这个发布控制开关，在你发布这个组件库的时候，它不会直接去覆盖线上的资源，会先去生成一个测试的 remote，之后它会去消息通知到每一个使用组件库的使用方。使用方拿到这个测试的 remote 就可以根据本地的环境配置，去配置测试环境的 remote，如果测试成功，就可以回到平台进行点击发布上线的按钮，然后去覆盖线上的 remote。为了确保万无一失，我们在覆盖线上 remote 的时候会去生成一个发布记录，这个发布记录你可以将它回滚，如果你发上去后发现有问题，可以拿以前的发布记录再给它回滚一次，它就会把以前的发布内容回滚到线上。