Proposal to improve react-hmr (or add some important info)

[nickrobillard]

I would like to point out some findings related to the react-hmr example. There is a note that says only liveReload is supported in the host. While this is very true in this example, I have found the reason for this is because the remote1 app is bi-directional - meaning it has "exposes" and "remotes". If sub-apps only have "exposes", then HMR works everywhere - in the host and in all sub-apps. I have found that this kind of design can be fairly easy to accomplish. For example, as an alternative, one can share react and other npm dependencies via WMF "shared" conf, instead of sharing them via libs app "exposes". Then remote1 app would not need to have "remotes". I think in many cases, especially when using mono-repos (consider a local custom lib that you want to re-use or share), it is quite feasible to avoid bi-directional sub-apps.

I realize there are likely other reasons for sharing react and other deps via "exposes" that I am not thinking about, so please let me know if I am missing something. I would be happy to add a new example, or maybe modify react-hmr somehow - either by changing the way it works, or just by adding a note in the README. Any ideas?

cc @burhanuday (I tagged you because it looks like you did most of the original work for react-hmr.)

[burhanuday]

@nickrobillard Hello.
In the example, HMR does work partially.
Changes in host are propagated to host via HMR
Changes in remote are propagated to remote via HMR if you run remote as standalone
Changes in remote are NOT propagated to host. From what i understand, this is a limitation in webpack
HMR for module federation is currently not implemented and is in the roadmap. vote for it here

If you have somehow achieved HMR between host and remote, can you send a PR with the changes or create an example repo?

[nickrobillard]

@burhanuday Sorry if I repeat some things but as I mentioned, I have found that the limitation of Webpack HMR with WMF only comes into the picture when a single app or host is bidirectional (ie: when the host or an app defines both "exposes" and "remotes"). To this point, keeping each app unidirectional is how NX achieves "HMR everywhere" when you create a WMF app using their setup commands. For HMR to "work everywhere", a single app - either the host or any of the sub-apps - cannot define both "exposes" and "remotes". It's that simple. :) And this is quite easy to accomplish, especially when using monorepos. I hope this makes sense.

So for your react-hmr example, we could easily make host only define "remotes" and remote1 only define "exposes". And we can change the way you share npm libs react, react-dom, react-router-dom to be shared via "shared" instead of using a libs app, which is a more standard way of sharing npm libs. I am happy to work on a PR for this.

[burhanuday]

@nickrobillard I created a minimal example from what you said. But cant get HMR to work across builds
Look at this branch in my repo - https://github.com/burhanuday/module-federation-with-webpack5/tree/feat/full-hmr

If you open the host on localhost:3000 and make a change in the RemoteCounter component, the console does log about HMR but does not actually do anything
Interested in knowing how you got HMR across builds. Can you share an example repo?

[nickrobillard]

I just tried your example locally and all you are missing is webpack output.uniqueName. After adding it, HMR works in both. :)

In host webpack.config.js:

  output: {
    ...
    uniqueName: "host",
  },

In remote1 webpack.config.js:

  output: {
    ...
    uniqueName: "remote1",
  },

[burhanuday]

Amazing! That did make it work!
Though not being able to use bi-directional containers is too limiting for most usecases. I'll try to investigate why setting uniqueName makes a difference. From the docs, if we dont explicitly set uniqueName, the name property from package.json should be used. I had those set and yet it wasnt working previously

[nickrobillard]

Great to hear.

While not allowing bi-directional containers may seem quite limiting, I am finding that when using mono-repos it is not as limiting as I first imagined. Again, NX approach to WMF is a good example here. In their mono-repo scenario, they heavily use WMF "shared", not just for sharing npm packages, but also for sharing internal libraries - like an internal UI Components library - via workspaces. This can remove the need for a "shared-components" container to expose the UI lib, and for another container to import it via "remotes". That being said, I am still determining the pros and cons of this approach, so take this with a grain of salt. Using "shared" in this way may have a negative impact on each container's build time, since each build has to bundle the shared libs independently. While the build times could be longer, I don't think application performance would be impacted because the "duplicate" chunks containing the same copy of "shared-components" should not be downloaded by the browser (I believe).