Add support for eager "exposed" modules

[MadaraUchiha-314]

Clear and concise description of the problem

There's no way to mark exposed modules as eager and having the ability to load them synchronously.

Suggested solution

Shared modules can be marked as eager in the shared config thus adding the ability to load them synchronously.

Internally eager shared modules are added to the remote entry.

The same can be done for exposed modules.

The only caveat is that if the exposed module imports a shared module, then that module also has to be marked as eager, otherwise one will get the error:

Uncaught Error: Shared module is not available for eager consumption

Alternative

The only workaround I have found is to also "share" the exposed module and then mark the shared module as eager. But this has the unwanted side effect of having that module in the shared scope. Additionally exposed modules don't have versions, so having them in the shared scope doesn't make sense.

Additional context

No response

Validations

• [X] Read the Contributing Guidelines.
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[2heal1]

Hmm I don't know understand the requirement . Do you mean expose can be config as the same as shared like 'eager:true', and then it will be loaded with remoteEntry ?

Can you add more details about why you need this change ? Or add pseudocode

[ScriptedAlchemy]

@2heal1 some exposed modules may be small or may be critical and he wants to avoid additional network call.

Basically like how shared eager=true works, but for exposes.

So eager exposed doesn't make extra chunk, it's just in the remote entry.

[ScriptedAlchemy]

The problem with eager module loading will be that you lose the async boundary - if eager expose needs react for example - it will fail since react is not ready / may not be ready at time its requested. There would need to be at least one async chunk call.

[MadaraUchiha-314]

There would need to be at least one async chunk call.

Not necessarily.

• If a dependency that the eager module requires is "shared" then it also has to be eager.
• Else the bundler will just bundle it in the remoteEntry since it will be a regular import.
• If a dependency is imported using dynamic imports, then we can
  • inline that dynamic import
  • let it be a dynamic import and let the exposed module handle it. The exposed module still be available synchronously.

[MadaraUchiha-314]

The same issue will exist when an eager shared dependency has a peer on another shared dependency which might or might not be marked as eager. For e.g. react and react-dom (declares react as a peer)

[github-actions[bot]]

Stale issue message

[MadaraUchiha-314]

@ScriptedAlchemy @2heal1 If this is an acceptable proposal, I can send in a PR implementing it.

[ScriptedAlchemy]

If you have an idea of how to add it. Then let's take a look.

[github-actions[bot]]

Stale issue message