Fetching remote-entry files dynamically and support of experiments.outputModule

[harirsskrishna]

Hello Webpack contributors,

I've encountered an issue with dynamically loading remote-entry files (fetching remote-entry files as needed) using Module Federation. I have a custom module loader that uses __webpack_require__.l() to fetch remote-entry files dynamically, as described in the Module Federation Plugin documentation.

To ensure __webpack_require__.l() is defined, I'm employing a workaround that involves dynamically importing a fake module (await import('./FakeModule.js')). While this successfully generates the __webpack_require__.l() definition, it has an unintended side effect: the webpack/runtime/publicPath (__webpack_require__.p) is set based on the baseURL of my module loader, rather than being recalculated for each use.

This has led to incorrect URLs for chunk loading, as __webpack_require__.f.j() calculates the chunk URL using the following pattern:

var url = __webpack_require__.p + __webpack_require__.u(chunkId);

I've found that setting output.library.type: 'module' and enabling experiments.outputModule allows __webpack_require__.p to be set correctly using import.meta.url. However, this is not an ideal solution as it relies on experimental features.

I have two questions for the community:

1. I would like to avoid building my own script tag creation and eventing code, and utilize as much in model webpack code as possible.

2. Are there any plans to support experiments.outputModule in future Webpack versions, or to stabilize this in the feature?

Any insights or suggestions on this matter would be greatly appreciated.

Thank you for your time and assistance.

Best regards,
Hari

[harirsskrishna]

@ScriptedAlchemy do you have any inputs?

[jdehaan]

For us problems with module federation (stack trace within a federation entry file, i[e] is not a function on the console => i[e] is a chunk usually but appears to be undefined) by switching from 5.90.1 (working) to 5.90.2 (broken). I tested 5.90.3 as well (still broken in seemingly the same way to this regard).

It's a huge project with loads of modules, only one of these looks like creating some kind of trouble for some reason. I lack experience in debugging within the packager. Is there anything useful I can/should provide to help. I have the feeling it might be related to what is being described here, but could also be an unrelated error.

[alexander-akait]

@harirsskrishna Please format your issue using the issue template, otherwise I will move it in Dicussions, thank you

[harirsskrishna]

@alexander-akait , I believe this better fits in the Discussions section. Please feel free to move it to Discussions.

[ScriptedAlchemy]

Look at module-federation/enhanced. I forked it out of webpack and added a hook lifecycle for runtime plugins.

Or module-federation/runtime which has all the mechanics.

[alexander-akait]

@ScriptedAlchemy Do we need something improve on webpack side?

[ScriptedAlchemy]

Im not sure if webpack will accept the enhancements made in here, it is also easier to maintain parity with webpack and rspack when both depend on a central runtime vs it coupled deeply to bundler.

What i did is extract the runtime code from webpack and author a library, then i added the hooks on require as needed, like f.consumes etc to bind it back to the bundler runtime.

If users want to adjust internals etc. You can write a runtime plugin that gives you access to the lifecycles.
for example:
https://github.com/module-federation/module-federation-examples/blob/master/runtime-plugins/remote-control/app1/pick-remote.ts

Might be useful.

[alexander-akait]

@ScriptedAlchemy sounds intresting, it can be useful, we have hooks, so I think we can solve it by them

[ScriptedAlchemy]

indeed, im not sure what your opinion is on depending on module-federation/runtime - but we would always introcude this back into the webpack plugin, otherwise one can use the enhanced plugin