Cache invalidation with @module-federation/enhanced

[ATakaSKY]

Describe the bug

Hi team,

I'm encountering an issue with remote entries consistently being the same every time I try to consume them using the following setup:

new ModuleFederationPlugin({
  name: "test",
  filename: "remoteEntry.js",
  remotes: {
    testEditor: "testMF@/ui/remoteEntry.js?v=[Date.now()]"
  },
  new ExternalTemplateRemotesPlugin()
}),

Previously, we relied on the ExternalTemplateRemotesPlugin package before transitioning to @module-federation/enhanced, and it effectively generated date timestamps, ensuring the creation of new remote entries each time. Is there a similar approach available in the new enhanced package? I noticed some changes in the nextjsmf package here, but I'm uncertain if there's a direct equivalent in the enhanced package.

Reproduction

NA

Used Package Manager

npm

System Info

NA

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.

[ScriptedAlchemy]

You would use a runtimePlugin https://module-federation.io/plugin/dev/index.html

in the init() hook.

args.options.remotes. = args.options.remotes.map((remote)=>{
  remote.entry = remote.entry + '?' + Date.now()
})

[ATakaSKY]

Great, thanks

I ended up creating a separate file for it:

const CacheBustPlugin = () => {
  return {
    name: "cache-bust-plugin",
    beforeRequest: (args) => {
      const { options, id } = args;
      const remoteName = id.split("/").shift();
      const remote = options.remotes.find((remote) => remote.name === remoteName);
      remote.entry = `${remote.entry}?v=${Date.now()}`;
      return args;
    },
  };
};

module.exports = CacheBustPlugin;

and then used it in runtimePlugins option:

new ModuleFederationPlugin({
      name: "test",
      filename: "remoteEntry.js",
      remotes: {
        testWeb: "testWebMF@/ui/remoteEntry.js"
      },
      runtimePlugins: [CacheBustPlugin.name],
 }),

I'm using beforeRequest as it's serving the same purpose, do you feel init is a better method to do such things or beforeRequest would also be fine in this case?

[ScriptedAlchemy]

Init is better imo as you want to change this script source as the system starts. Think about if other runtime plugins are used in the future. Init is the best place personally. But before request can do it, it'll just be during runtime which could be problematic if you have some other plugins who attempt to read configs during init.

Both will work but my preference is init hook.

[ScriptedAlchemy]

You can also register a global plugin if you want this to apply to the entire system. I can show you sample of global plugin but use them wisely if you do as they will impact everyone with no option to opt out

[ATakaSKY]

You can also register a global plugin if you want this to apply to the entire system. I can show you sample of global plugin but use them wisely if you do as they will impact everyone with no option to opt out

That will be interesting to see, could you please share it here

[ScriptedAlchemy]

core/packages/runtime/src/global.ts

Line 289 in b3530d7

// If a plugin is already registered, a warning message is logged.

import {registerGlobalPlugin} from mfruntime