I've done some attempts and I've figured out something more:

• I've tried working with previous versions of our packages, but the issue was already there, only I hadn't found out

• I've tried pointing to remotes that are reachable and not reachable, but the issue is always there, so I think that the content of the remote app doesn't impact the issue

• I wanted to try working without the runtime file, but the app stops working. With runtime set to false, I have to set experiments.outputModule to false to make the rest of the app work, but with those settings the import of the remote app appears without single quotes:

  module.exports = remote@http://localhost:3001/assets/remoteEntry.js;

• This happens even if I change the library settings in ModuleFederationPlugin to

  library: { type: 'var', name: 'host' }`

• Setting runtime to single doesn't solve the issue, because Webpack still outputs two runtime-app files

• Passing a runtime string to the ModuleFederationPlugin settings, or setting the field to false doesn't solve the issue

@gtempesta-pixartprinting This is expected, because with module federation you have two runtimes - one internal (for loading packages inside federation), the second is for main application (splitting and dynamic chunks)

I will look deeply soon at this

@alexander-akait Thanks for taking the time to look into the issue.

I've done some further investigation and I'd like to share what I've found.

Why I don't think it's expected

I don't think the behavior I'm experiencing is expected, because:

1. The two generated files have the same name, the only thing that changes is the chunk hash
2. The content of the files is also very similar, sometimes the only thing that changes is the chunk hash of the referenced file(s)
3. The first output of the watch command and the output of the build command don't have this issue.

To make it easier to reason about it, I've added a new folder to my repository generated-output-example.

In the folder there are two runtime-app files: runtime-app.d0415bae809a613ce32c.js and runtime-app.2f49b02885c5fb16b004.js. The first one is referenced under entrypoints in the asset-manifest.json file, while the second one is referenced by the app.51cd46ce3502605c797c.js file, which is also referenced in the asset-manifest.json file.

What is happening when running the code in the browser

First thing, I've discovered that this doesn't only happen when changing code in the file that loads the micro frontend, it happens with every change to any file that's dynamically loaded by the main file (app.js). Anyway this is what happens:

1. After we save a change in a file that's dynamically loaded, the changes are saved in a chunk
2. The correct chunk is referenced by one of the two runtimes that are generated
3. The browser loads the two runtimes (one is requested by the manifest and the other by the app.js file)
4. Only the runtime referenced in the manifest holds the reference to the chunk with the changes
5. The runtime referenced in app.js references a chunk that doesn’t have the changes
6. The browser only loads the chunk that’s referenced in the runtime that’s loaded by the app file and not the chunk that's references in the runtime that's listed in the manifest
7. If I look for the changes in the browser (Open the Developers Tools and Search) the change is never loaded by the browser

How to check this in my repository

1. Checkout the project
2. Clear the public folder
3. Run watch
4. Add a log to design-area.js (for example console.log(’test’);)
5. Look for the log inside the public folder and mark down the chunk hash. If there are more than one, mark all the chunk hashes of the files you find
6. Now open asset-manifest.json and open the runtime-app that’s referenced there
7. Open that file and look for the chunk hash: it should be there
8. Now go to the app file referenced in asset-manifest.json
9. Look for the runtime-app referenced there
10. Open the runtime-app file and look for the chunk hash(es) of the files with the initial log: it’s not there

Let's do the same check inside my generated-output-example folder.

1. I've added this log to the design-area.js file: console.log('second test log'); (the log is not committed to the project)
2. The output code is only present in this chunk: resources_js_chunks_design-area_js.6572e66ecc4cdcf33f12.js, so the chunk hash I should look for is 6572e66ecc4cdcf33f12
3. If I open asset-manifest, I will find this runtime-app under entrypoints: runtime-app.d0415bae809a613ce32c.js
4. If I look for the chunk hash 6572e66ecc4cdcf33f12 in this runtime, I can find it
5. Now I open the app that's referenced in the manifest, which is: app.51cd46ce3502605c797c.js
6. The app references a different runtime: runtime-app.2f49b02885c5fb16b004.js
7. If I open the file and look for the chunk hash 6572e66ecc4cdcf33f12, it is not there!

I hope this helps debugging.

Looks like a bug in https://github.com/gtempesta/webpack-issue-repro/blob/main/webpack/webpack.dev.config.js#L62 or your should use other logic for generations, because in our files we have the valid value and code is working

Looks like a bug in https://github.com/gtempesta/webpack-issue-repro/blob/main/webpack/webpack.dev.config.js#L62 or your should use other logic for generations, because in our files we have the valid value and code is working

But the chunk referenced in app is the one without the changes, so in my opinion there is an issue even without considering the asset-manifest generation.

So
app.51cd46ce3502605c797c.js
-> runtime-app.2f49b02885c5fb16b004.js
-> resources_js_chunks_design-area_js.2876b31bdeb0b3a137d5.js
-> no log here

The changes are in
resources_js_chunks_design-area_js.6572e66ecc4cdcf33f12.js
which is only referenced by runtime-app.d0415bae809a613ce32c.js which in turn is referenced in the manifest file.

If we will have wrong values for runtimes we will generate wrong runtime code and it will be broken, but your code works...

If we will have wrong values for runtimes we will generate wrong runtime code and it will be broken, but your code works...

I wouldn't say that my code works, because the app.js chunk references the wrong runtime, so I'm not able to see the correct changes in the browser when running watch.

I've done a couple more attempts to prove my point.

1. Overwrite the generated app file

With the current setup, I've looked for the linked runtime in the generated app file, let's say the line:

import __webpack_require__ from "./runtime-app.2f49b02885c5fb16b004.js";

And replaced it with the correct runtime, let's say:

import __webpack_require__ from "./runtime-app.d0415bae809a613ce32c.js";

In this case the code works.

2. Remove the Module Federation plugin

I've removed the Module Federation plugin from the Webpack configuration and replaced the import of the remote application with an empty object.

const { default: remoteMountMethod } = {};

Instead of:

const { default: remoteMountMethod } = await import(
  'remote_bucket/remoteMountMethod'
);

Now the app chunk doesn't even reference a runtime, and everything works as expected.

3. Configure a different plugin

I've configured webpack-assets-manifest instead of webpack-manifest-plugin: the two manifests generate files with the same issues.