At first, this is not a bug. The webpack version I use: 5.88.1.

I work in a company who's business logic of products are very complex. Micro-Frontend architecture is quite common in my company, making module federation (MF) a suitable choice for us. Thanks MF.

We've been using MF for over a year now, and it has worked seamlessly for sharing React components across multiple projects, albeit without any shared libraries.

This year, our focus is on enhancing the performance of various products spanning multiple projects through Micro-Frontend. We have started sharing UI components in Micro-Frontend across these projects, with each component being packaged as an isolated npm package. To enable the sharing of any component, webpack(MF plugin) have split the code of each component into separate chunks. Initially, we didn't see any issues with having numerous chunks, as we believed in the power of HTTP2 (for HTTP2 multiplexing).

We conducted multiple tests in both local and online user environments, collecting and analyzing performance data. Our findings indicated that a smaller number of chunks significantly improves performance.

To address this, we made efforts to merge chunks using the optimization.splitChunks.cacheGroups option. However, it seems that when sharing components with Module Federation, the code splitting for these components takes precedence. We tried various options, but the results were not as expected.

One day, we found that eager option (of MF shared option) may help us. After setting eager: true for all the components the home page of a product(project), the number of chunks reduced noticeably (e.g. index.xxxx.js gets larger), resulting in improved performance.

However, we noticed that the MF remoteEntry.js file also increased in size. After a deep dive into the eager option documentation, we realized this was expected but not desirable for us. We consider remoteEntry.js as a resource list, similar to an HTML role, and expect it to have a small code size. Consumer projects load remoteEntry.js from another provider project using a timestamp (e.g., remoteEntry.js?t=160xxxxx) or with a no-cache HTTP header to access the latest code. While other resources (like index.[contenthash].js) use long-term caching from CDN. If remoteEntry.js becomes too large, it could negatively impact performance.

Just like this demo: https://github.com/module-federation/module-federation-examples/tree/master/shared-routes2/app2, after building in the dist directory, remoteEntry.js and main.js both have react and react-dom source code.

It appears that eager: true may not be the ideal solution for us to enhance performance, and using a no-cache strategy for remoteEntry.js may not be the best practice.

Then, We want to build two versions of source business code, one version with eager: true and without exposes, another one version without eager: true and with exposes, maybe it will work, but it is too heavy.

Could someone provide some advice on this matter? Thank you!

This image helps illustrate the usage of MF in our company: