feat: cjs interop

[hugs7]

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 merge function 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 into globalThis. However, in such as situation as I describe above, this is not the case!

I acknowledge on the README there is the following point

2. It is not recommended to mix Vite and Webpack in React projects, as there is no guarantee that Vite/Rollup and Webpack will generate the same chunk when packaging commonjs, which may cause problems with shared.

... 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 get callback, 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 get callback but since we rely on Webpack to actually call the get function, I don't think this is possible without reinitialising the share scope (around where getModuleMarker is called). This could be a viable solution but might slightly hurt performance. Thoughts welcome.

Hugo

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Code of Conduct and follow the Commit Convention guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[hugs7]

I noticed a small typo here

[hugs7]

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.

[hugs7]

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