Unable to initialise federated module sharing with multiple shareScopes

Bug report

What is the current behavior?

When using ModuleFederationPackage, the shared option allows specifying different scopeNames for each package. It is not possible to initialise sharing via (container.init(...)) for any but the default scope.

If the current behavior is a bug, please provide the steps to reproduce.

Make an example package with a set up similar to,

new ModuleFederationPlugin({
  shared: {
    'normal-package': { scopeName: 'default' },
    'package-a': { scopeName: 'a' },
    'package-b': { scopeName: 'b' }
  },
  shareScope: 'default'
})

Initialise default sharing with,

await Promise.all([
  __webpack_init_sharing__('default'),
  __webpack_init_sharing__('a'),
  __webpack_init_sharing__('b')
])

const container = window['example-package'];

await container.init(__webpack_share_scopes__['default']);

It is not possible initialise sharing in the example package for the scopes ‘a’, and ‘b’.

What is the expected behavior?

It should be possible to initialise sharing for ‘a’ and ‘b’

The current initialisation code hardcodes the scope name, even though there may be more than one.

var init = (shareScope, initScope) => {
	if (!__webpack_require__.S) return;
	var oldScope = __webpack_require__.S["default"];
	var name = "default"
	if(oldScope && oldScope !== shareScope) throw new Error("Container initialization failed as it has already been initialized with a different share scope");
	__webpack_require__.S[name] = shareScope;
	return __webpack_require__.I(name, initScope);
};

If we changed this container code (keeping API compatibility) to the following,

var init = (shareScope, initScope) => {
	return initSharing("default", shareScope, initScope);
};

var initSharing = (name, shareScope, initScope) => {
	if (!__webpack_require__.S) return;
	var oldScope = __webpack_require__.S[name];
	if(oldScope && oldScope !== shareScope) throw new Error("Container initialization failed as it has already been initialized with a different share scope");
	__webpack_require__.S[name] = shareScope;
	return __webpack_require__.I(name, initScope);
}

// This exports getters to disallow modifications
__webpack_require__.d(exports, {
	get: () => (get),
	init: () => (init),
	initSharing: () => (initSharing)
});

We could then initialise sharing for the other scopes via,

// ...
await Promise.all([
  await container.initSharing('default', __webpack_share_scopes__['default']),
  await container.initSharing('a', __webpack_share_scopes__['a']),
  await container.initSharing('b', __webpack_share_scopes__['b']),
])

See #13800

Other relevant information: webpack version: 5.44.0 Node.js version: v14.15.1 Operating System: macOS Big Sur Additional tools: nil

[sokra]

@jacobp100 I think you can put react 17 and 18 in the default scope and put the package with peer dependency on react under a different key into the share scope.

Assuming a react-lib uses react.

// react 17 app which uses "react-lib"
shared: ["react", {
  "react-lib": {
    shareKey: "react-lib for react@17"
  }
}]

// react 18 app which uses "react-lib"
shared: ["react", {
  "react-lib": {
    shareKey: "react-lib for react@18"
  }
}]

[jacobp100]

@sokra Thanks - that works surprisingly well! I’ll assume you don’t need the PR any more - but I’m happy to continue with it if you do need it (for other reasons etc.)