Skip to content

Conversation

@crutch12
Copy link

@crutch12 crutch12 commented Nov 10, 2025

Problem

@module-federation/vite generates esm only remoteEntry.js file, thus you are not able to load it in "old fashion way"

Problem example:

// host
plugins: [
  federation({
    remotes: {
      remote: 'remote@http://localhost:3000/remoteEntry.js' // doesn't work with esm files
    },
  }),
]

Solution

We can generate additional varRemoteEntry.js file,

This file will just import() our esm remoteEntry.js file and call init/get methods. Example:

// varRemoteEntry.js
var remote; // name of remote app
remote = (function () {
  function getScriptUrl() {
    return document.currentScript.src
  }

  const entry = `${getScriptUrl()}/../remoteEntry.js` // path to esm remoteEntry.js

  return {
    get: (...args) => import(entry).then(m => m.get(...args)),
    init: (...args) => import(entry).then(m => m.init(...args)),
  };
})();

Thus host application may use it:

// host
plugins: [
  federation({
    remotes: {
-      remote: 'remote@http://localhost:3000/remoteEntry.js'
+      remote: 'remote@http://localhost:3000/varRemoteEntry.js'
    },
  }),
]

Moreover: I've added new property into manifest.json - varRemoteEntry, I hope it's okay...

Current problems

  • Handle publicPath/getPublicPath options
  • Write tests

Related issues:

@crutch12 crutch12 force-pushed the feature/var-remote-entry branch from 807ccea to 6dad215 Compare November 10, 2025 13:13
@crutch12
Copy link
Author

@gioboa @ScriptedAlchemy could you check it out? wdyt?

},
remoteEntry,
ssrRemoteEntry: remoteEntry,
varRemoteEntry,
Copy link
Author

@crutch12 crutch12 Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ScriptedAlchemy wdyt about additional varRemoteEntry field in manifest.json?

Or maybe we should generate the second item in manifest.json array. Sry, I couldn't find the manifest specification...


const isValidName = isValidVarName(name);

// @TODO: implement publicPath/getPublicPath support
Copy link
Author

@crutch12 crutch12 Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't handle publicPath/getPublicPath here. Should I? I rely on generated remoteEntry.js relative path

function getScriptUrl() {
const currentScript = document.currentScript;
if (!currentScript) {
console.error("[VarRemoteEntry] ${varFilename} script should be called from sync <script> tag (document.currentScript is undefined)")
Copy link
Author

@crutch12 crutch12 Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this logic. Maybe there is another way to indicate path of original remoteEntry.js file?
I've stolen it from __webpack_public_path__ ('auto') implementation...

const isValidName = isValidVarName(name);

if (!isValidName) {
warn(
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we fail if provided name is not valid js name?
In this case it's not possible to load this remote entry in old fashion way, it won't work:

remotes: {
  '@app/remote': '@app/remote@http://localhost:3000/varRemoteEntry.js',
}

But, as my example shows, this still works with dynamic loadRemote, therefore I've decided to handle it with globalThis and showing the warn message

@crutch12 crutch12 marked this pull request as draft November 10, 2025 13:46
@crutch12 crutch12 changed the title [DRAFT] feat: new varFilename option - allow generate additional globalVar remoteEntry.js file (#247) feat: new varFilename option - allow generate additional globalVar remoteEntry.js file (#247) Nov 10, 2025
@crutch12 crutch12 changed the title feat: new varFilename option - allow generate additional globalVar remoteEntry.js file (#247) feat: new varFilename option - allow generate additional "var" remoteEntry.js file (#247) Nov 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant