NX error after updating to 19.5.3

[Aubrey-Russell]

Current Behavior

Unable to compile federated types, Error: compile TS failed, the original command is 'npx tsc --project ...\node_modules.federation\tsconfig.11a9cb42-e0ab-4650-9dbd-e50a75fd14d6.json'
Error: ENOENT: no such file or directory, open '...\[email protected]'
at Object.openSync (node:fs:581:18)
at Object.readFileSync (node:fs:457:35)
at _GenerateTypesPlugin. (...\node_modules@module-federation\dts-plugin\dist\index.js:2470:140)
at Generator.next ()
at fulfilled (...\node_modules@module-federation\dts-plugin\dist\index.js:54:24)
at processTicksAndRejections (node:internal/process/task_queues:95:5) {
errno: -4058,
code: 'ENOENT',
syscall: 'open',
path: '...\dist\@mf-types.zip'
}

Expected Behavior

Error should not occur

GitHub Repo

No response

Steps to Reproduce

1. Install a micro front end with a shell and federated module
2. yarn nx serve shell

Nx Report

Node   : 21.1.0
OS     : win32-x64
yarn   : 4.3.1

nx (global)        : 19.1.1
nx                 : 19.5.3
@nx/js             : 19.5.3
@nx/jest           : 19.5.3
@nx/linter         : 19.5.3
@nx/eslint         : 19.5.3
@nx/workspace      : 19.5.3
@nx/cypress        : 19.5.3
@nx/devkit         : 19.5.3
@nx/eslint-plugin  : 19.5.3
@nx/node           : 19.5.3
@nx/react          : 19.5.3
@nrwl/tao          : 19.5.3
@nx/web            : 19.5.3
@nx/webpack        : 19.5.3
typescript         : 5.5.4
---------------------------------------
Registered Plugins:
@nx/eslint/plugin

Failure Logs

No response

Package Manager Version

yarn 4.3.1

Operating System

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

Additional Information

No response

[Aubrey-Russell]

Here's what seems to be happening--some MFEs seem to have an extracted zip folder while others have a zip folder with contents. The ones that are already extracted cause the problem

[jame-earnin]

I have the same issue.

  [ Module Federation Manifest Plugin ]: Manifest will use absolute path resolution via its host at runtime, reason: publicPath='auto'
  Unable to compile federated types, Error: compile TS failed, the original command is 'npx tsc --project /home/runner/_work/web-app-frontend/web-app-frontend/apps/earnin-app/node_modules/.federation/tsconfig.7309c320-88f2-42dc-ac1d-628451765d5c.json'
  Error: ENOENT: no such file or directory, open '/home/runner/_work/web-app-frontend/web-app-frontend/apps/earnin-app/dist/@mf-types.zip'
      at Object.openSync (node:fs:581:18)
      at Object.readFileSync (node:fs:457:35)
      at _GenerateTypesPlugin.<anonymous> (/home/runner/_work/web-app-frontend/web-app-frontend/node_modules/@module-federation/dts-plugin/dist/index.js:2470:140)
      at Generator.next (<anonymous>)
      at fulfilled (/home/runner/_work/web-app-frontend/web-app-frontend/node_modules/@module-federation/dts-plugin/dist/index.js:54:24)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
    errno: -2,
    code: 'ENOENT',
    syscall: 'open',
    path: '/home/runner/_work/web-app-frontend/web-app-frontend/apps/earnin-app/dist/@mf-types.zip'
  }

➜  web-app-frontend git:(WBPP-4057) ✗ nx report                            

 NX   Report complete - copy this into the issue template

Node           : 18.18.2
OS             : darwin-arm64
Native Target  : aarch64-macos
npm            : 9.8.1

nx                 : 19.5.6
@nx/js             : 19.5.6
@nx/jest           : 19.5.6
@nx/linter         : 19.5.6
@nx/eslint         : 19.5.6
@nx/workspace      : 19.5.6
@nx/cypress        : 19.5.6
@nx/devkit         : 19.5.6
@nx/eslint-plugin  : 19.5.6
@nx/next           : 19.5.6
@nx/playwright     : 19.5.6
@nx/react          : 19.5.6
@nx/storybook      : 19.5.6
@nrwl/tao          : 19.5.6
@nx/vite           : 19.5.6
@nx/web            : 19.5.6
@nx/webpack        : 19.5.6
typescript         : 5.5.4

[Aubrey-Russell]

@jame-earnin Any chance you are using shared libs as part of your MFE repo? Is this repo you have here shareable?

[OlgaShishka]

I have the same issue with 19.5.6 version

does anyone understand why nx tries to compile federated types and put them into @mf-types.zip inside every MFE's /[APP]/dist folder?
should it now work like that? I haven't found anything about that in the docs or in the Release notes.

[madangryscientist]

I am also experiencing flaky builds due to this.

[iconag-bbasmer]

I have the same issue.

[kondensat01]

I have the same issue.

[tbhag]

I also have the same issue unforunately

[vadimka123]

I have the same issue.

[Aubrey-Russell]

@OlgaShishka its a good question. Why was this broken feature stealth released randomly with no explanation and no notes? It isn't helpful either and it clutters the heck out of the dist folder when the zip folder is expanded. Furthermore, if you try to delete the dist folder it slows things down massively because now you're deleting many smaller files. Just.......why?

The rationale for this design is totally baffling to me. The way it worked before seemed perfect--now we've downgraded to this bizarre zipped type folder thing. I don't want a bunch of junk type files everwhere, and I don't see even any theoretical benefits for such a solution.

[iconag-bbasmer]

@Aubrey-Russell I totally agree and speaking of slowing down things: I just upgraded to the latest version and my builds are now significantly slower than before. Didn't have much time yet to have a deeper look but I guess I have to (try to) investigate soon.

[Coly010]

Hey everyone!

The Federated Types Plugin is a feature of the @module-federation/enhanced package.

This package is where all development of Module Federation itself (not owned by us) is now taking place by Zack Jackson (https://x.com/ScriptedAlchemy) and the ByteDance team (https://x.com/ByteDanceTalk).

We switched to this package because it is a drop in replacement for Webpack’s native Module Federation, and includes all the latest bug fixes, improvements and features of Module Federation.

You can learn more about it here: https://module-federation.io

This wasn’t simply a quick change to what package we used. This has been planned for months, and I tested as many scenarios as I could before we merged the change. We even have e2es testing Module Federation setups.

All that is to say, that this choice to use the new package was made to allow everyone using Module Federation with Nx to continue to receive the best Module Federation support from the people actively working on Module Federation as well as providing access to the new features.

The purpose of the Federated Types Plugin is that it will create typings for remotes that may not actually live in the same repository as other parts of your MFE architecture, covering cases where our typing support is unable to because we don’t have any information about these remotes.

Now back to the issue at hand.

I will investigate this to determine if it’s an issue with @module-federation/enhanced package solely, or if it’s related to it being used in an Nx workspace.

I understand that this is incredibly frustrating, but @Aubrey-Russell a clear reproduction with each step defined makes reproducing issues like this much easier.

Simply stating install mfe and a federated module is not overly helpful because it doesn’t tell me the steps you took that resulted in seeing the error and it is also ambiguous over tech stack (React/Angular), SPA or SSR, static federation or dynamic federation, if you’re federating a module from a library, or if it’s just a standard remote, etc.

To speed this along, if you could provide a minimal reproduction repo that I can clone, it would be very much appreciated.

[Coly010]

A workaround for now would be to turn off the dts plugin (https://module-federation.io/configure/dts.html) by adding the following to your withModuleFederation() in the webpack.config file:

withModuleFederation(config, { dts: false })

[madangryscientist]

A workaround for now would be to turn off the dts plugin (https://module-federation.io/configure/dts.html) by adding the following to your withModuleFederation() in the webpack.config file:

withModuleFederation(config, { dts: false })

Thanks that works for me.

[rbirkgit]

This update also broke all our MFE remotes. none of them are loading anymore. I see no errors.

It seems it all changed very drastically. Ports etc all changed. I find it strange this big breaking change was done in a point release without much info.

I also tried with 19.6.5 which adds the dts:false, but no difference.

[Aubrey-Russell]

There has got to be some test cases that ensure basic module federation with remote apps work. I'd be happy to give some example repos that would allow the nx team to test remote module cases such as this one which showcased a different error:

https://github.com/Aubrey-Russell/grommet-react-mfe-issue-example

I created this one a while back. I can create another example with maybe 5-10 apps and a shell in react. That way as part of a new release the NX team can ensure that remote federated modules don't break

[iconag-bbasmer]

I have updated my NX version to 19.7.3 and have found this blog entry that showed me how to setup the module federation with NX and RSBuild: https://blog.soumyanildas.com/nx-rspack-micro-frontend

I was able to make it work, even with dynamic module federation, which has some special twists coming with it, but anyway.
Also these 2 videos helped me a lot with the setup:
https://www.youtube.com/watch?v=oJY92rZV8NE
https://www.youtube.com/watch?v=VE1FWi2L_-g

I'm still struggling with using css modules and rspack, though. But that's a different story.

[iconag-bbasmer]

Ok, I have now also figured out how the (s)css modules have to be integrated with Rspack and Nx.
I updated to Nx 19.7.4 and you can find my setup for Nx with Rspack including module federation, handling of parths in tsconfig and css / scss modules handling here.

I hope this helps anymore.

[github-actions]

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.