Hundreds of micro-frontend applications in the company, How to smoothly upgrade mf from umd

MF introduce

webpack5 module-federationvery powerful, The front-end code (module) sharing has reached a new level, and remote code can be used like a local module

Before that, it is bound to use the most widely standard UMD module specification for sharing, Using loaders such as systemjs needs to process promise logic, which only has a small impact when using asynchronous components. If the remote module is a function or a configuration item (such as JSON data), then the usage restrictions will be more obvious, and There is also no development environment support such as mature supporting TS prompts。

MF can use remote modules almost without perception, and has solutions in various fields（webpack-4、5、vite/rollup、TS、SSR、medusa/dashboard等）, More efficient and stable than requiring manual coding to process remote modules asynchronously

MF enhance

The company has hundreds of micro front-end applications and modules, and the company's business architecture will also require a large number of product integration components (different businesses provide capabilities and components to each other), which is very compatible with the characteristics of MF。

So what's the problem with using MF directly??

1. Hundreds of micro-frontend projects need to be fully upgraded and adapted (if a team uses webpack5 to provide an MF module, the webpack4 team cannot consume this module)
2. How to reuse a large number of existing remote modules without refactoring (after upgrading mf, remote resources are divided into two types (1.UMD 2.MF), both remote modules will have dependencies, and the two dependencies need to be able to communicate and maintain singleton)

For the above two problems, we provide two open source projects as corresponding solutions, and improve the versatility of module-federation, no longer limited by webpack5 (module-federation/webpack-4), and support the integration of other module specifications (universal-module-federation).

• module-federation/webpack-4

• universal-module-federation

  With the support of these two plug-ins, MF can even be used as a synchronously loaded remote universal module loader, and can be used directly in existing projects, It should also be able to reuse the original ecology such as ts, dashboard/medusa of MF。

How to support multi-version coexistence:

Many people may think that MF's remote cannot coexist in multiple versions. First of all, this is not a shortcoming of MF, nor is it unsolvable。

• Since the webpack application needs to mount global variables on the window, use jsonp to load different chunks. And MF also has a globally unique module name that will pollute the global space. When multiple versions of the same application appear at the same time, the global module will conflict。
• You only need to add the dimension of the version number to the configuration items of webpack, output.library.[name | uniqueName], ModuleFederationOptions.name, and the global conflict can be resolved (because the global jsonp variable name will appear In all chunks, the hash of all chunks packaged in each version of this setting will change, and the cache will be invalidated, but generally there is no need for multiple versions)。

Disadvantages of multiple versions:

• Multiple versions of the same remote are loaded at the same time, and should not exist in the H5 environment. The appearance of multiple versions will increase the resources requested by the network and cause performance problems
• In large-scale micro-frontend projects on the B-end, there is a high probability that multiple versions of remote will need to coexist. However, similar to H5, it generally only appears across micro-frontend applications. The same application still needs to ensure that the version is unified, and no redundant resources are required to ensure loading speed. However, there are qiankun and other micro-frontend solutions across applications to isolate window global variables, and this problem no longer exists.

future upgrade:

If webpack is eliminated, can the MF project continue to be used without refactoring

• If turbopack succeeds webpack, MF official should continue to support
• If other build tools succeed webpack, they can also make the MF project continue to run. You can refer to usemf (loading MF modules in other environments), and here In the process, there must be similar technologies.
• Even in the era when esmodule can be used directly in the browser, and the original MF module file can be imported directly, it can also be used in the form of promise, but then the packaging process can be simplified and the ES module can be directly output for support.

Therefore, no matter how the front-end ecology changes in the future, there can always be a smooth upgrade plan, but we need to move closer to the open source ecology, so as not to build a car behind closed doors and lead to reconstruction in the future.