Module Federation @ syntax support

[zamotany]

Having a app@remoteUrl syntax support when declaring remotes, for example:

new webpack.container.ModuleFederationPlugin({
  remotes: {
    app1: Repack.Federated.createRemote('app1'),
    app2: Repack.Federated.createRemote('app2@https://somewhere-on-internet.com/app2.container.bundle'),
  },
})

essentially boils down to passing the remoteUrl into the ScriptManager.

By introducing concept of multiple resolvers to ScriptManager this can be easily achieved:

export function createRemote(remote: string) {
    const [remoteName, url] = remote.split('@');

    return dedent`promise new Promise((resolve, reject) => {
      var scriptManager = __webpack_require__.repack.shared.scriptManager;

      if (url) {
        scriptManager.addResolver(function(scriptId) {
          if (scriptId === "${remoteName}") {
            return { url: "${url}" };
          }
        });
      }

      scriptManager
        .loadScript('${remoteName}', undefined, __webpack_require__)
        .then(function() {
          resolve({
            get: (request) => {
              return self.${remoteName}.get(request);
            },
            init: (arg) => {
              try {
                return self.${remoteName}.init(arg);
              } catch (e) {
                console.log('[Repack/Federated] Remote container ${remoteName} already initialized.');
              }
            }
          });
        })
        .catch(function(reason) {
          reject(reason);
        });
    })`;
  }

This will allow not only to support @ syntax in remotes but also add an ability for containers to dynamically provide resolves inside the code:

// In a container

ScriptManager.shared.addResolver(async (scriptId) => {
  if (scriptId === 'app1') {
    const url = await getUrlDynamically();
    return { url };
  }
}):

cc: @ScriptedAlchemy @tom-sherman

[ScriptedAlchemy]

Yeah this is what id had in mind and tried with v2, but ran into issues of ChunkManager never resolving a promise even though the script did inject into RN.

Support of the @ syntax would enable pretty much universal use of MFP across any environment with more or less the same syntax for all - just different implementations of the "last mile" interconnections.

We have this for node.js, next.js which gives us server side MFP capabilities. RN will be the last env to achieve the trifecta.

What eager issues do you run into?
When using promise new promise, does the remote get loaded and its just a sharing issue? Is it the host failing on eager error, or is it the now loaded remote that says there is no shared modules injected into it?

Meta suggestion - what i usually do is create a new plugin wrapper. like RNModuleFederationPlugin, where my remotes are just the normal "browser" synax options. like a straight string - then in the plugin i parse options and convert it to promise new promise. That way the user only needs to pass one syntax all the time and the plugin takes the standard options and can convert it on demand.

so regardless of my envs, user only needs to read webpack docs and pass a remote in one of the valid formats, i then wrap the real MF plugin in the converted options.

See: Configuration Options

https://app.privjs.com/buy/packageDetail?pkg=@module-federation/nextjs-ssr

Next is powered by promise new promise, but users only ever pass known ways of working with standard api.

That said, i am working on this: https://github.com/module-federation/enhanced
Which might be a nicer syntax to take advantage of in general for advanced use cases where we need more plugability or middlewares

[tom-sherman]

Have you tried an additional bootstrap step?

index.js:

import Bootstrap from "./bootstrap";

AppRegistry.registerComponent(appName, () => Bootstrap);

bootstrap.js:

import * as React from "react";
import { Text } from "react-native";

const App = React.lazy(() => import("./App"));

export default function Bootstrap() {
  return (
    <React.Suspense
      fallback={
        <Text style={{ textAlign: "center", marginTop: 40 }}>
          Loading the app...
        </Text>
      }
    >
      <App />
    </React.Suspense>
  );
}

[ScriptedAlchemy]

Okay so it looks like it might be that share scope isn't passed into a remote. But the host still works?

If that's the case. I trick I use in next, where I can't move things around in the module graph. Is object.assign(webpack_share_scopes.default,{moreStuff})

[zamotany]

@tom-sherman
Yup, I've doing it with bootstrap, even with async boundary (import(...)) between index and bootstrap and using remote only inside bootstrap, and the result was the same initExternal('app') was called as part of bundle's entry evaluation.

[zamotany]

I'm going to commit an example right now, you you'll be able to see the code itself.

[zamotany]

@ScriptedAlchemy @tom-sherman
Here's the MF example I'm using:

• https://github.com/callstack/repack-examples/tree/main/module-federation - base
• https://github.com/callstack/repack-examples/tree/host-remotes/module-federation - with remotes in host package, this one fails on eager error

Once you clone repo, run yarn install and then yarn workspaces module-federation run start.

[tom-sherman]

IMO the ideal is that RePack would support name@url syntax out of the box without the createRemote call.

The reason I think this is ideal is that I believe module federation in react native should work as identically as possible to module federation on the web.

On the web ModuleFederationPlugin must transform the @ syntax into a HTTP request, can't we inject a loadScript call in there?

[ScriptedAlchemy]

Do you guys wanna go a google meet this week? Or a zoom?

If we can hammer this out quickly, get a reproducible error repo, and talk shop. Then we can go out seperate ways and see what we come up with. Then add it back to this thread:)

[zamotany]

Yeah, I'm up for it.

[tom-sherman]

Same, any time after 11am UTC+1 is good for me. Zack just message me on slack with the details 👍

[zamotany]

You can find me on Discord or message me on https://twitter.com/_zamotany

[ScriptedAlchemy]

Great will get a twitter group convo going