feat: add configurable sharing with semver resolution

[AndreasLoukakis]

This is more of a plan than a final implementation, so that I can get some initial feedback. Actual function implementation and tests should follow accordingly.

The idea / feature is to add opt-in support for sharing configuration, with semver range matching and singleton/strictVersion enforcement. I tried to establish a resolution algorithm as used in webpack, with the same options that already exist in both implementations.

Changes:

• Add semver utility supporting ^, ~, >=, <=, >, <, exact, and * ranges (sine this is a runtime check, we probably prefer a custom small function rather than semver lib dependency, which would add a good number of kb at runtime bundle)
• Add useShareConfig flag to InitFederationOptions (default: false). The idea here is to not introduce any breaking changes, even if (useless so far) config is already used. Switch to default true in a later version then maybe remove in next major.
• Implement Webpack-like resolution algorithm in externals.ts
• Add warning for ignored config when useShareConfig is disabled (dev mode only)
• Maintain 100% backwards compatibility via opt-in flag

So, implementation is mostly skeleton with TODO comments. Actual logic to be implemented after some feedback.

Package Resolution Flow:

1. Fast Path: Check for exact version match first (e.g., 3.0.0 === 3.0.0)

2. Singleton Mode (singleton: true):

   • Only ONE instance allowed across all microfrontends
   • First registered version wins
   • If requiredVersion: false → use singleton regardless of version
   • If version satisfies range (e.g., 3.5.0 satisfies ^3.0.0) → use singleton
   • If incompatible:
     • strictVersion: true → use own bundle (fallback)
     • strictVersion: false → use singleton anyway (with warning)

3. Non-Singleton Mode (singleton: false):

   • Multiple versions can coexist
   • Find all versions that satisfy requiredVersion range
   • Use highest compatible version
   • If no compatible version found:
     • strictVersion: true → use own bundle (fallback)
     • strictVersion: false → use highest available version (with warning)

Semver Support

Supports standard semver ranges (keeping runtime lightweight ~1-2KB):

• * - any version
• 3.0.0 - exact match
• ^3.0.0 - same major (>= 3.0.0 < 4.0.0)
• ~3.2.0 - same major.minor (>= 3.2.0 < 3.3.0)
• >=3.0.0, <5.0.0, >3.0.0, <=5.0.0 - comparison operators
• >=3.0.0 <5.0.0 - compound ranges (space-separated AND)

Backwards Compatibility

• Default: useShareConfig: false (exact version matching, current behavior)
• Opt-in: useShareConfig: true (enforces config with semver)
• Dev Warning: Warns when config is set but not enforced (dev mode only)

Example

// Host app
initFederation(
  { mfe1: 'http://localhost:4201/remoteEntry.json' },
  { useShareConfig: true }  // Enable enforcement
);

// federation.config.js
shared: {
  'date-fns': {
    singleton: true,           // Only one instance
    strictVersion: false,      // Allow version mismatch with warning
    requiredVersion: '>=3.0.0 <5.0.0'  // Accept 3.x or 4.x
  }
}
Result: Host with date-fns@3.0.0 and MFE with date-fns@4.1.0 will share because 4.1.0 satisfies >=3.0.0 <5.0.0.

[Aukevanoost]

Hi @AndreasLoukakis Really appreciate the effort! But we're actively working on integrating this orchestrator in the new version which already has the sharing capabilities!
https://github.com/topicusonderwijs/vanilla-native-federation

Check out this article for more info :)
https://medium.com/@auke997/migrating-a-stateful-monolith-to-micro-frontends-using-native-federation-0572a1e181b4

[AndreasLoukakis]

So you are actually saying that this library will get deprecated and people should move to vanilla native federation instead?

[Aukevanoost]

No, we're working on a smooth internal transition. It's not deprecated yet but it is currently serving it's purpose as is until the new orchtestrator is fully integrated. If you need the new features it's recommended to use that new orchestrator yes.

[AndreasLoukakis]

OK so it's feature freeze until the new orchestrator takes over. Good to know, thanks @Aukevanoost :)

[AndreasLoukakis]

It might be a good idea to announce some roadmap on this repo so people know what to expect, though. Just a thought.