Federated modules don't work going from nx 17 to nx 18

[Aubrey-Russell]

Current Behavior

Upgrading to NX 18 from 17 breaks all federated module stuff

Expected Behavior

Remote federated modules should work as expected when migrating from nx 17 to nx 18

GitHub Repo

No response

Steps to Reproduce

1. Create an NX remote federated module project in nx 17
2. Create a react shell host application
3. Create a react remote federated module
4. Reference a dynamic federated module using the module exports in module-federation.config.js
5. Launch the shell
6. Observe Shell finding remote Entry and launching on a server and port
7. run mx migrate --latest
8. pnpm install
9. nx serve shell
10. Observe errors saying cannot find remoteEntry

Instead of the shell, running on localhost:4200, referencing federated module remote entry on, say, localhost:9007 like on nx 17 as is configured in remote app project.json, now bizarrely its looking on localhost:4201/remoteEntry.js

NX never launches anything on localhost:4201; there's nothing there and I never configured it to run anything on localhost:4201 so it makes sense why remote entry cannot be found

Nx Report

Node   : 21.1.0
   OS     : win32-x64
   pnpm   : 8.14.2

   nx                 : 18.0.1
   @nx/js             : 18.0.1
   @nx/jest           : 18.0.1
   @nx/linter         : 18.0.1
   @nx/eslint         : 18.0.1
   @nx/workspace      : 18.0.1
   @nx/cypress        : 18.0.1
   @nx/devkit         : 18.0.1
   @nx/eslint-plugin  : 18.0.1
   @nx/react          : 18.0.1
   @nrwl/tao          : 18.0.1
   @nx/web            : 18.0.1
   @nx/webpack        : 18.0.1
   typescript         : 5.3.3

Failure Logs

Failed to load resource: net::ERR_CONNECTION_REFUSED
remoteEntry.js:1 

        Failed to load resource: net::ERR_CONNECTION_REFUSED
remoteEntry.js:1 

        Failed to load resource: net::ERR_CONNECTION_REFUSED
remoteEntry.js:1

Package Manager Version

No response

Operating System

• [ ] macOS
• [ ] Linux
• [X] Windows
• [ ] Other (Please specify)

Additional Information

No response

[ptakpatryk]

I couldn't reproduce it on the macOS. Everything works fine after migrating. What I can suggest tho is running nx reset before and after migration. I found caching sometimes a pain when changing configurations etc.

Additionally, you could take a look at the shell's webpack.config.prod.ts and see what the path is configured to each of the remotes as this is what controls where the host will be looking for the remotes.

Sorry if I teach you how to suck eggs here, but trying to be helpful 😄

@Edit Just realised that the type of remotes changed from string[][] to string[] after migrating. But for me after changing remotes to be just ['shop', 'cart'] and playing with ports in remotes it knew where to find remote anyway, so my suggestion above might not be valid, although for some reason it wasn't throwing any errors when running serve even with wrong types of remotes so you can still try it and see if it changes anything.

[Aubrey-Russell]

@ptakpatryk Thanks very much for your response here this is helpful, I will try nx reset as well and see if that fixes it, if not I will attempt to replicate and strip down the project as an example. The remotes thing you mentioned here is interesting too. In nx 17 I didn't have to specify these remotes in a development configuration in the webpack config on localhost. Of course for production and stuff I have to refer to where the federated module is hosted, but using the module-federation.config.js was sufficient previously:

module.exports = { name: 'shell', remotes: ['app1', 'app2', 'app3'], };

In nx 17 what would happen is it seemed like nx would look at all my of my remote app project.json 's, start all of the project on the port specified in project.json, then dynamically reference localhost:port as i had it specified in the module-federation.config. Did the logic change under the hood here to where it operates differently when ingesting remotes and now it requires you to specify the localhost remote as well?

[Aubrey-Russell]

@ptakpatryk It looks like now I must specify --devRemotes when starting shell. Previously it seemed like NX would automatically determine which --devRemotes to use

[isunilmekala]

Even after specifying --devRemotes its failing to load those remote hosts as in development mode.

[ptakpatryk]

Hi @Aubrey-Russell, @isunilmekala,

Could you please create a repo with this issue reproduced? Here's my attempt and all works smoothly on Mac - https://github.com/ptakpatryk/nx-17-to-18-migration. Whether I spin it up using devRemotes or not everything works as expected (with hot module replacement when running MFE as dev remote).

You could also try running it on your end, who knows - it might be specific to the Windows platform. If that's the case I will try my luck on debugging it on my Windows machine.

[rbirkgit]

Can this be related to this issue? https://github.com/nrwl/nx/issues/20974

We cannot update to Nx 17.3+ since now we are forced to have all static remoted starting up on the same port. But that doesn't work as they use different ports in devRemote mode. Is there a solution to this? or we will not be able to update top any newer Nx?

[leosvelperez]

The original issue reported in this thread should have been addressed by https://github.com/nrwl/nx/pull/21709, which was released in Nx 18.0.4. There was an issue with the remapping done to the remote URL when the project had a single remote (when serving static remotes).

It looks like now I must specify --devRemotes when starting shell. Previously it seemed like NX would automatically determine which --devRemotes to use

You need to specify which remotes you want to serve in development mode. Those specified with the --devRemotes flag will be watched, rebuilt, and live-reloaded on changes. The rest of the remotes will be built once and served with a static server for a faster startup.

Can this be related to this issue? #20974

That's a different issue, and you can continue the conversation over that thread.

@Aubrey-Russell could you please try again with the latest version and see if the issue is solved for you?

[Aubrey-Russell]

@leosvelperez thanks for your message, I will try the latest version today and see if that works

[Aubrey-Russell]

@leosvelperez Weirdly enough it completely fails to launch now. Running with verbose doesn't give me any more information

\nodemodules.pnpm\@nx+react@18.0.4@swc-node+register@1.8.0@swc+core@1.4.1@types+node@20.11.17_nx@18.0.4_typescript@5.3.3\node_modules\@nx\react\src\executors\module-federation-dev-server\module-federation-dev-server.impl.js:111 throw new Error(Remote failed to start. See above for errors.); ^

Error: Remote failed to start. See above for errors. at ChildProcess. (nodemodules.pnpm\@nx+react@18.0.4@swc-node+register@1.8.0@swc+core@1.4.1@types+node@20.11.17_nx@18.0.4_typescript@5.3.3\node_modules\@nx\react\src\executors\module-federation-dev-server\module-federation-dev-server.impl.js:111:23) at ChildProcess.emit (node:events:515:28) at ChildProcess._handle.onexit (node:internal/child_process:294:12)

Node.js v21.1.0

Report

Node : 21.1.0 OS : win32-x64 pnpm : 8.15.2

nx : 18.0.4 @nx/js : 18.0.4 @nx/jest : 18.0.4 @nx/linter : 18.0.4 @nx/eslint : 18.0.4 @nx/workspace : 18.0.4 @nx/cypress : 18.0.4 @nx/devkit : 18.0.4 @nx/eslint-plugin : 18.0.4 @nx/react : 18.0.4 @nrwl/tao : 18.0.4 @nx/web : 18.0.4 @nx/webpack : 18.0.4 typescript : 5.3.3

[Aubrey-Russell]

Ill see if I can create a separate repo that replicates this issue that I can share

[Aubrey-Russell]

if I specify devRemotes on 18.0.4 then there's no error or problem. To clarify--I don't want to start the federated modules in development mode, but this enables nx to detect and point to the federated modules without error

[leosvelperez]

That's definitely not expected. Something else might be going on. Please provide a reproduction so we can troubleshoot it.

[github-actions[bot]]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. If we missed this issue please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[isunilmekala]

Don't know how much this is correct but with below change I am now able to run the remote app in development mode properly

[github-actions[bot]]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. If we missed this issue please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[github-actions[bot]]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.