Next.js: Dynamic Remotes Singleton sharing not working about universe HOT 16 CLOSED

Stay pinned there!! Thanks for letting me know.

from universe.

published new nightlys

from universe.

We are encountering issues when trying to share react-query as a singleton with dynamic remotes. This problem is preventing us from updating our next and @module-federation/nextjs-mf packages.

Versions Tried

We attempted to use the following versions but encountered the same issue:

• 8.1.0-canary.7
• 0.0.0-feat-node-support-1703050615268

Current Versions

Currently, we are using the following versions without this issue:

• @module-federation/nextjs-mf: 7.0.8
• next: 13.4.19

We would appreciate any guidance or assistance in resolving this issue. Thank you.

from universe.

Read here:
https://github.com/module-federation/universe/tree/feat_apply_bundler_runtime/packages/runtime

You can dynamically defined containers as needed.

Or you dynamically control what remotes are loaded or from where, you should use the new runtimePlugins capability:

https://github.com/module-federation/universe/blob/feat_apply_bundler_runtime/packages/runtime/src/core.md

https://github.com/module-federation/universe/blob/feat_apply_bundler_runtime/packages/nextjs-mf/src/plugins/container/runtimePlugin.ts

new NextFederationPlugin({
runtimePlugins: [
        require.resolve(path.join(__dirname, '../container/runtimePlugin')),
      ],
})

from universe.

Downgrading @module-federation/nextjs-mf to 8.1.0-canary.1 seems to resolve the singleton sharing issue.

from universe.

Just tried out the experimental version 0.0.0-feat-node-support-1702696727086. The development mode works very well (and singleton sharing is fixed, thank you! 🙂).
When running the production build I get the following error:

main-2930bf0ea7365e55.js:54 [ Federation Runtime ]: TypeError: ee.j.startsWith is not a function
main-2930bf0ea7365e55.js:54 Uncaught Error: [ Federation Runtime ]: TypeError: ee.j.startsWith is not a function
    at SyncWaterfallHook.error [as onerror] (main-2930bf0ea7365e55.js:54:3027)
    at SyncWaterfallHook.emit (main-2930bf0ea7365e55.js:16:2384)
    at FederationHost.formatOptions (main-2930bf0ea7365e55.js:53:2800)
    at new FederationHost (main-2930bf0ea7365e55.js:54:1407)
    at Object.init (main-2930bf0ea7365e55.js:54:1650)
    at 2515 (main-2930bf0ea7365e55.js:1:378)
    at __webpack_require__ (webpack-58e7c275c1f45a54.js:54:26463)
    at main-2930bf0ea7365e55.js:54:143007
    at webpackJsonpCallback (webpack-58e7c275c1f45a54.js:54:76971)
    at main-2930bf0ea7365e55.js:1:79

from universe.

thanks for letting me know, ill address

from universe.

I just tried to upgrade to 0.0.0-feat-node-support-1703050615268 and the error is unfortunately still the same.
Or should I rather now use the snapshots which are build from the next branch?

PS: I really like these fast iteration cycles with the experimental releases, thanks for publishing them! One suggestion: If I got the pattern correctly, the npm version is currently 0.0.0-<BRANCH_NAME>-<TIMESTAMP>. What about replacing the timestamp with the commit sha? This would make it easier to find the commit where the snapshot was published from.

from universe.

We should release new canary soon.

from universe.

Ahh this is dynamic remotes. You will encounter problems doing this. Youll likely need to use the new runtime https://github.com/module-federation/universe/blob/feat_apply_bundler_runtime/packages/runtime/README.md

Dynamic remotes in v1 of MFP cannot guarantee singletons as share scope will tear.

from universe.

You can do the following:

try {
//share scope can be mutated
 await container.init(__webpack_share_scopes__.default);
 // share scope is sealed in this container, no additions will be seen after this point. 
} catch() {}

Container cannot be initialized multiple times. After first init() share scope cannot be updated, if it is, whoever is already initialized will not "see" any subsequent additions.

V1.5 apis will allow for more control over where shared modules are picked from, but if you initialize remotes lazily like this, it'll most likely still tear share scope.

from universe.

But, i would not suggest implementing dynamic remotes by hand with your own script loaders and so on. use /runtime package along with v8 of nextjs-mf.

Can these remotes not be configured upfront?

from universe.

We're planning an architecture with one host and ~50 remote apps, aiming for independent deployments. We're unsure if this can be achieved without upfront remote configuration using the runtime package.

We also aim to follow the 12-factor principles, using the same image across all environments. We're using importRemote from '@module-federation/utilities' to avoid defining remotes upfront.

Is this approach compatible with the runtime package? Any advice on achieving independent deployment and environment consistency with module federation would be appreciated.

from universe.

Dynamic remotes will cause singleton issue as you tear share scope, all remotes must be known upfront to initialize them.
There is no workaround to lazy remote injection, best you can do is register the remotes upfront and lazy load them as needed but they must all inialize at once.

When share scope "seals" no new keys or refs will be added to containers already sealed.

from universe.

Singletons are now working fine for me in 8.1.10. The resolution for me was switching from remote delegates to a runtime plugin.
Surprisingly, even the singleton sharing works now with dynamically injected remotes which were not known at startup.

from universe.

yes runtime plugin is the best way to go, its the first non-hack solution to this stuff haha. Glad it worked for you!

from universe.