[Feature]: Support per-shared dependency negotiation behavior (strict vs fallback)

[leo2823]

Is your feature request related to a problem?

No response

Describe the solution you'd like

In Module Federation, the negotiation behavior can be configured per shared dependency.

For example, it is possible to have:

• shared dependencies that throw an error if version negotiation fails (singleton: true + strictVersion: true);
• shared dependencies that fall back to loading another compatible version when negotiation fails.

In Native Federation v4, this behavior appears to be controlled globally by the strictExternalCompatibility option passed to initFederation(). As a result, it is not possible to configure the negotiation strategy for individual shared dependencies. We would like to configure some shared dependencies as strict while allowing others to fall back to their own implementation when version negotiation fails.

Additionally, is there a way to let a remote resolve its own shared dependency even if the host already provides the same package? At the moment, Native Federation v4 seems to always prioritize the host's shared dependency.

Example:

• Host provides:

  • lodash-es@4.17.23
  • requiredVersion: ^4.17.23

• Remote (front-office) provides:

  • lodash-es@4.18.1
  • requiredVersion: ^4.18.0

This results in:
[NF][3]: [front-office][lodash-es@4.18.1] Is not compatible with requiredRange '^4.17.23' from remote '__NF-HOST__'.
In this scenario, we would expect loading a single version lodash-es@4.18.1 into the global scope instead of failing, similarly to how Module Federation behaves.

• Is there currently a configuration that allows negotiation behavior to be configured per shared dependency instead of globally?
• Is it possible to let loading shared dependency from a remote even when the host provides the same package?

Describe alternatives you've considered

No response

[Aukevanoost]

Hi,

Thanks for this, I understand. To keep things straight this is the current "ruleset" of the orcestration: there are 2 kinds of influences on dependency negotiation.

There are "policies" that are globally managed. Like the strict policies which define how liberal the orchestrator is (fail or scope). Another policy you mentioned is an implicit one, if you provide a host remoteEntry, that one has precedence over everything. You can avoid this by not providing a host remoteEntry.json.

The "negotiation process" is dependency specific. As you said, strictVersion means "enforce requiredVersion", singleton indeed means, scope or make sharing candidate. These levers can be used to influence the negotiation process.

docs

Can you motivate why you'd like to move the policies to dependency specific as well? Like with an example case or so.

[leo2823]

It would be useful to have a way to configure strict negotiation for specific dependencies, for example some company-specific libraries may require a single version at runtime, while for other dependencies, such as lodash-es, it would be preferable to allow multiple versions to be loaded if the negotiation process cannot find a version that satisfies all declared ranges.

However, I’m not passing the hostRemoteEntry to the initFederation call from @angular-architects/native-federation-v4 in main.ts, yet I’m still seeing the host’s shared dependencies being prioritized.