feat: cjs interop #720
Open
feat: cjs interop #720
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We do it this way to prevent reloading a share scope module
hugs7
commented
Sep 29, 2025
| format: "esm" | "systemjs" | "var"; | ||
| from: "vite" | "webpack; | ||
| from: "vite" | "webpack"; | ||
| } |
hugs7
commented
Sep 29, 2025
| return import(/* @vite-ignore */ name).then(module => ()=> { | ||
| if (${REMOTE_FROM_PARAMETER} === 'webpack') { | ||
| if ((globalThis.__federation_shared_remote_from__ ?? ${REMOTE_FROM_PARAMETER}) === 'webpack') { | ||
| return Object.prototype.toString.call(module).indexOf('Module') > -1 && module.default ? module.default : module |
Author
There was a problem hiding this comment.
as per my PR description, if you think it's better to rebind the share scope instead of taking __federation_shared_remote_from__ to be the accepted remote from, let me know. This does have the downside of not allowing a merge in the case of a conflicting share scope format.
Author
|
Unit tests Some of the e2e tests fail for me on main branch. Can one of the maintainers run these locally on my branch? I get the following same result on main or my branch |
hugs7
force-pushed
the
feature/cjs-interop
branch
from
e7a4420 to
fad8803
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Hi. Love your package. In my team, we have a small issue where we are running a nested microfrontend setup with the inner most MFE being Webpack (var) and the other two being Vite (esm). When running the middle MFE with the nested MFE things are all fine, since the shared scope initialises as expected (var). However, when running all three together, the shared scope initialises as Vite (ESM) since that is what the middle MFE is running as. When the inner-most MFE goes to import modules, the
mergefunction call in /packages/lib/src/dev/remote-production.ts - Line 150 makes the assumption that the remote format/from is the same as what is already loaded intoglobalThis. However, in such as situation as I describe above, this is not the case!I acknowledge on the README there is the following point
... however, my PR aims to fix this issue by ensuring shared modules are seeded correctly even in cases of cross-runtime federation interoperability!
Additional context
My solution involves setting a global variable to the "remote from" of the share scope which is being loaded. Then in the
getcallback, we use this as a priority over the already-bound${REMOTE_FROM_PARAMETER}parameter (set when the outer-most app or host begins its share scope initialisation).I tried to curry the remote from into the
getcallback but since we rely on Webpack to actually call thegetfunction, I don't think this is possible without reinitialising the share scope (around wheregetModuleMarkeris called). This could be a viable solution but might slightly hurt performance. Thoughts welcome.Hugo
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123).