RemoteEntry file size increased by ~7x about core HOT 8 OPEN

@karthickshanmugam0689 trust me I hear you. Will sync with the team next week and see what we can do about it.

My plan was to hold off on this task till I go to china this month, then we could all work on it in person.

I did take a look into it on one of my flights recently, I am able to half the artifact size with a few adjustments but I do need to find the best way to still make it easy for users to use and not introduce perf drag when users enable the features.

Let me sync with everyone and follow up on this. Im also not happy with the size but again we had to pick one or the other to get going. I appreciate the patience here, will make this a priority on my end but need to collaborate with my team about it and i know we have some big ticket items we really want to land

from core.

Okay I have found a possible solution here.

I can tell remotes to skip importing the runtime and instead create a remoteEntry that expects the runtime to be external / provided by the host.

If your host runtime is out of sync with the remotes, however, you will most likely break your application.

But if you can manage to keep them in sync, then this solution would work.

The alternative is to treat it like shared code with strict semver. But if anyone needs to load their own runtime you will have a much slower app startup than just loading an extra 20kb of code. establishing a HTTP call will take far longer than an already in-flight payload that a little larger.

from core.

@ScriptedAlchemy This is in line with some of the conversations we have been having. Externalizing the federation runtime is an option to reduce the bundle size.

Providing the external is by hosting it in a public/private CDN is the challenge.

I guess the @module-federation/runtime package can spit out single file builds which are in various formats like ESM, UMD, SystemJS etc.

I tried to do a quick check for this using esm.sh. Here's the PR: MadaraUchiha-314/rollup-plugin-module-federation#55

from core.

Yeah. We will work on making the runtime work similar to shared in the future. So if host is providing or has the runtime already the containers don't need to load theirs. After SSR lands for modernjs we will most likely take a closer look at how to reduce the payload size. Due to time we had to make some compromise as this is not a easy one to solve in a elegant way

from core.

Yes as a tool ModuleFedaration is awesome, but the size is too huge to use in a production build. We have a size limiter for our builds but now our bundle size is getting increased more than the set threshold limit.
An example where the bundle size is getting increased

And the related bundle analysis by webpack-analyzer

from core.

If your host runtime is out of sync with the remotes, however, you will most likely break your application.

It would be good to add in a console.warn or trigger a hook in such a case where we detect that the runtime of the host is incompatible with the runtime requested by the consumers.

It will also be good if a higher order entity (like a shell) has the ability to register/provide the runtime, just like we register a global runtime plugin

from core.

If your host runtime is out of sync with the remotes, however, you will most likely break your application.

This might help address the bundle size issue; however, it might add additional complexity, as we have to maintain module federation in sync with both the host and remotes.

Curious about v1 of module federation: did we always incur this cost? Instead of the federation runtime code being in the remote entry, was it in the webpack runtime?

Also, can we tree-shake unused modules from the SDK and runtime? We may not be able to share the runtime with other apps, but it might be worth the tradeoff. Could you please share recommended methods for maintaining the remote entry size small (apart from the module federation runtime)?

from core.

In general additional hop might not be of a big concern though. runtime can be shared from host and not being eager here.

from core.