init (from @module-federation/runtime) doesn't support registering multiple versions of the same shared module about universe HOT 9 CLOSED

Yes, i will support shared can pass array to support register mulite version shared in next days

from universe.

A custom runtime plugin that uses resolveShare should work.

IF react is set to a singleton its going to always fetch the highest version within the semver requirements. Unless set singleton: false or use strictVersion etc.

from universe.

if you look in share_scope object, it should register all version keys available but will return the version based on the rules of federation semver algo, unless you override it with your own in resolve share

from universe.

A custom runtime plugin that uses resolveShare should work.

IF react is set to a singleton its going to always fetch the highest version within the semver requirements. Unless set singleton: false or use strictVersion etc.

The problem is not with resolving to the right version of the package. The problem is how do we register multiple versions of the same package from a single container ?

Within a single container, due to nested dependencies, there might be many different versions of the same package that might be resolved. When a bundler plugin implementing module-federation is rewriting those imports to loadShare, it needs to provide the version info so that the correct version is resolved.

For federation runtime to resolve the correct version, it needs the ability to register multiple version of the same package during the init call. That's what's missing.

@ScriptedAlchemy ^

from universe.

use a trailing slash

react/ for instance, that should register any dependency that starts with react/ request, not just resolve to index file.

from universe.

I am still not able to grasp it completely 😅 May be if you could provide an example that would help me understand it better ?

My use case (as I mentioned in the parent post) is that of a plugin which is trying to implement module federation for a bundler (in this case rollup).

May be we can connect and I can explain this issue better.

from universe.

Ahh i understand what you mean.

The only way id seen this done in webpack was via the trailing slash which did some magic under the hood, and it adds multiple keys under the library for each version.

In here i only have one, but if there were more they would register here as additional keys.

@2heal1 do you have any suggestions?
We could allow for array support in the share, so you could pass an array of different react versions etc.

init({
  name: '@demo/main-app',
  remotes: [],
  shared: {
    react: [
{
      version: '17.0.0',
      scope: 'default',
      lib: () => require('react'),
      shareConfig: {
        singleton: true,
        requiredVersion: '^17.0.0',
      },
    },
{
      version: '18.0.0',
      scope: 'default',
      lib: () => require('../modern/react'),
      shareConfig: {
        singleton: true,
        requiredVersion: '^18.0.0',
      },
    },
],
    'react-dom': {
      version: '17.0.0',
      scope: 'default',
      lib: () => ReactDOM,
      shareConfig: {
        singleton: true,
        requiredVersion: '^17.0.0',
      },
    },
  },
});

from universe.

@ScriptedAlchemy @2heal1 I think this is wrapped up right? I remember seeing a PR around it.

from universe.

yes this should be complete

from universe.