angular-architects / module-federation-plugin

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Native Federation and lib sharing: is it supposed to work like Module Federation ?

zerock54 opened this issue · comments

Hello,

I am trying to use the same configuration as MF for lib sharing, namely:

const {withNativeFederation, shareAll} = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({
  name: 'remote1',

  exposes: {
    './web-components': './src/bootstrap.ts',
  },

  shared: {
    'useless-lib': {
      singleton: true,
      strictVersion: true,
    },
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
    // Add further packages you don't need at runtime
  ],
});

But the "singleton", "strictVersion", etc... seem to have no effect.
The only thing I can see happening is this:

  • If the host and the remote use the same version, useless-lib will be downloaded once
  • If the versions are different, the host and the remote use their own versions of useless-lib

This is already nice but how can I make singleton, strictVersion, etc... work like in Module Federation ? Is it even implemented ?

My configuration:

  • 1 host (Angular 17.1.1)
  • 1 remote (Angular 17.3.1)
  • The remote is a web component
  • I'm using dynamic module federation to load my microfrontends

Thank you

Try adding this and it should do the trick:

sharedMappings: ['useless-lib'],

for development I normally use the shareAll

module.exports = withNativeFederation({
  ...
  shared: {
      ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' })
  },

  sharedMappings: ['useless-lib'],
  ...
});

But the "singleton", "strictVersion", etc... seem to have no effect.

Yes, that's right. We are going to implement this with one of the next versions.

The current behavior is the one that makes most sense for Angular applications:
a) If two or more MFEs have the very same Angular version (down to the patch version), the lib is shared
b) Otherwise, the different version is loaded

a) makes sense because the very same Angular version the app was compiled with is expected at runtime as the compiled version is using Angular's private API that does not (have to) align with semver.

In the case of b), you need to bootstrap the different Angular apps, e.g., by wrapping them into web components.