NX upgrade from 18.0.3 to 18.0.4 breaks all microfrontend static remotes

[ekiliqua]

Current Behavior

I tried to update to the latest version of NX (19), but it caused several errors. One of those errors is the one I managed to locate by upgrading version by version, specifically from version 18.0.3 to version 18.0.4.

I have several applications (for example, app1, app2, app3). When I run the shell application without any application in devRemotes, everything seems to compile correctly, but when I try to access any of these applications from the shell, it always redirects to the same application (app3) without any console error or something.

I’m not sure if this is related, though I don't think so... One of the applications exposes the following modules:

And when I try to access one of them, I get the following error in the console:

Expected Behavior

Navigation between the applications should work correctly.

GitHub Repo

No response

Steps to Reproduce

upgrade 18.0.3 to version 18.0.4.

I have several applications (for example, app1, app2, app3). When I run the shell application without any application in devRemotes, everything seems to compile correctly, but when I try to access any of these applications from the shell, it always redirects to the same application (app3).

Nx Report

Node   : 22.0.0
   OS     : darwin-arm64
   npm    : 10.5.1
   
   nx (global)        : 19.6.5
   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/angular        : 18.0.4
   @nx/cypress        : 18.0.4
   @nx/devkit         : 18.0.4
   @nx/eslint-plugin  : 18.0.4
   @nrwl/tao          : 18.0.4
   @nx/web            : 18.0.4
   @nx/webpack        : 18.0.4
   typescript         : 5.3.3

Failure Logs

No response

Package Manager Version

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

In this upgrade, from 18.0.3 to 18.0.4 only changes package versions. Migrations file is empty.

[Coly010]

@ekiliqua Your error suggests that something went wrong when your remote application was built.

However, that error is also coming from older version of Nx. If you continue with your migration forward towards latest Nx, does the same error still get produced?

[ekiliqua]

@Coly010 yes, the problem is the same... The first attempt was to run 'nx migrate latest' but it was still breaking, so I went version by version to try to locate the error. If migrate to latest only change the literal of the error when try to load "./Agenda" from "utilidades" instead "63855" and the problem with routing is the same.

This "upgrade" only change files of nx from 18.0.3 to 18.0.4.

[Coly010]

@ekiliqua Can you continue from version 18.0.4 to latest following this order:

npx nx migrate 19.0.8
npx nx migrate --run-migrations
npx nx mgrate 19.3.2
npx nx migrate --run-migrations
npx nx mgrate 19.5.7
npx nx migrate --run-migrations
npx nx mgrate latest
npx nx migrate --run-migrations

Then, after all this run
npx nx reset

After the reset has completed, then try to serve your host again.

[ekiliqua]

@Coly010 The issue persists. After investigating a bit more into the generated remoteEntry.mjs files, they all have the same code. It seems that all of them are the same application exposed on all ports.

var moduleMap = { "./Module": () => { return Promise.all(/*! __federation_expose_Module */[__webpack_require__.e("default-webpack_sharing_consume_default_angular_core_angular_core"), __webpack_require__.e("default-webpack_sharing_consume_default_angular_common_angular_common"), __webpack_require__.e("default-webpack_sharing_consume_default_primeng_api_primeng_api"), __webpack_require__.e("default-webpack_sharing_consume_default_rxjs_rxjs"), __webpack_require__.e("default-webpack_sharing_consume_default_angular_router_angular_router"), __webpack_require__.e("default-webpack_sharing_consume_default_XXXXXXX_domain_XXXXXXX_domain"), __webpack_require__.e("default-webpack_sharing_consume_default_ngx-translate_core_ngx-translate_core"), __webpack_require__.e("default-webpack_sharing_consume_default_XXXXXXX_data-access_XXXXXXX_data-access"), __webpack_require__.e("default-apps_provision-usuarios_src_app_remote-entry_entry_module_ts")]).then(() => (() => ((__webpack_require__(/*! apps/provision-usuarios/src/app/remote-entry/entry.module.ts */ 18133))))); } };

It seems that they all export the same: apps/provision-usuarios/src/app/remote-entry/entry.module.ts

[ekiliqua]

Hello @Coly010,

Hello, I think I have found the source of the error. It seems that the migration is done correctly, but what actually breaks the navigation is my configuration of the project.json files...

I have removed my configuration and left the default one that comes with a newly created project in version 19.

Removing the configuration seems to work; maybe when the static servers are generated, they are not being taken into account, and the redirection does not work.

[Coly010]

That makes sense. I'll see what I can do around this

[Coly010]

@ekiliqua Was this the configuration for one of your remotes, or the host application?

I cannot reproduce it.

I have a repo here where I have attempted to.
Could you let me know what needs to be edited here to match the setup you had that was failing?
Alternatively you could open a PR to the repo which makes those changes.

https://github.com/Coly010/nx-mf-output-path-differences.git

[ekiliqua]

@Coly010
sorry, I don't have my github account set up properly in the IDE at work and I can't PR...

You don't need to put it in the shell. Just modify these two lines:

https://github.com/Coly010/nx-mf-output-path-differences/blob/b572181be8283ac86317e69c1fcf09b09791ab2f/remote1/project.json#L13

https://github.com/Coly010/nx-mf-output-path-differences/blob/b572181be8283ac86317e69c1fcf09b09791ab2f/remote2/project.json#L13

And delete this line:

https://github.com/Coly010/nx-mf-output-path-differences/blob/b572181be8283ac86317e69c1fcf09b09791ab2f/remote1/project.json#L32

If you don't modify the main outputPath of build, there is no problem because static server generates two internal folders correctly:

If you put two different outputPaths in both applications, it works correctly.

It only happens when you change the outputPath of the two applications and put the same final directory ‘dev’.

On the other hand, this seems to be another bug:

If in the static-server configuration you have set by default the production configuration profile... it should read the production outputPath and it keeps reading the default optionPath of ‘build’?

Thank you very much for your time, best regards.