Remotes is not iterable

[vaibhavrja]

Current Behavior

I am created a nx monorepo workspace for react. After all the setup was done,2 days back it was working fine, but now when I am trying to run command nx serve host, it is giving error REMOTE IS NOT ITEABLE

Terminal O/P:-

nx run host:serve:development

NX Starting module federation dev-server for host with 2 remotes NX Building 2 static remotes... NX Built 2 static remotes NX remotes is not iterable

Expected Behavior

Is should be working as normal

GitHub Repo

No response

Steps to Reproduce

NA

Nx Report

NA

Failure Logs

No response

remotes is not iterable

TypeError: remotes is not iterable at startRemotes (/Users/cars24/c2b-portal-temp/node_modules/@nx/react/src/executors/module-federation-dev-server/module-federation-dev-server.impl.js:63:23) at moduleFederationDevServer (/Users/cars24/c2b-portal-temp/node_modules/@nx/react/src/executors/module-federation-dev-server/module-federation-dev-server.impl.js:197:39) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async getLastValueFromAsyncIterableIterator (/Users/cars24/c2b-portal-temp/node_modules/nx/src/utils/async-iterator.js:13:19) at async iteratorToProcessStatusCode (/Users/cars24/c2b-portal-temp/node_modules/nx/src/command-line/run/run.js:43:29) at async handleErrors (/Users/cars24/c2b-portal-temp/node_modules/nx/src/utils/params.js:9:16) at async process. (/Users/cars24/c2b-portal-temp/node_modules/nx/bin/run-executor.js:59:28)

Package Manager Version

No response

Operating System

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

Additional Information

No response

[ScottMorse]

I experienced this when my @nx/webpack and @nx/react packages were off of each other by a major version, @nx/react at 18 and @nx/webpack at 17. I hadn't noticed this for a little while since only the dev server had broken while builds were successful.

I would have thought perhaps peer dependencies or something similar would have been in place to catch this type of issue, since I don't believe I had disabled validating them on install, but I guess not. It looks like the @nx/react package had listed some other Nx packages in its package.json dependencies such as @nx/web, but no mention of @nx/webpack anywhere in package.json despite utilizing it in its code. This still seems to be the case with the latest version I installed.

Nx is powerful and complex, but the ease of ending up in these hairy situations on top of constantly questioning whether I'm just experiencing a caching-related issue when any internal errors like this surface makes it feel more complex to manage than necessary sometimes, as this unvalidated dependency of @nx/webpack in @nx/react is a minor form of magic that can lead to rare and confusing errors such as this one.

As far as what exactly causes this error, similarly running the serve target but with the --verbose tag showed me this would fail due to this argument passed to startRemotes in @nx/react that is expected to always be an iterable being undefined thanks to dynamicRemotes not being present in the result of getRemotes from import { getRemotes } from '@nx/webpack/src/utils/module-federation' at @nx/webpack version 17.

I simply took this as an opportunity to upgrade all my Nx packages to get them all on consistent and compatible versions, but just make sure to read up on the breaking changes to Nx and watch out for ESLint rule changes when upgrading the eslint package if you do this.

[ScottMorse]

I wanted to add that my criticisms for Nx in the previous comment is not to insult but to provide for feedback this tool that I want to see continue to succeed. I am a monorepo fan, and Nx came into my radar just as I was about to waste my own time building out similar but likely worse tooling on top of vanilla npm workspaces for myself.

However, I often feel that it is like having a glass box that is supposed to be treated as a black box, where you are encouraged to just trust the good magic of the generators/executors etc., but when you have complex things to solve and need to adjust the details of things yourself, you are free to do so, which I'm a fan of, but then you run into the bad magic like this and can get lost in the Nx packages/executors/generators, the many configuration files you end up generating that I inevitably end up refactoring heavily to make DRYer so I can manage them without going crosseyed, issues in the CLI due to the cache, etc. I have gained a level of paranoia lately in that I end up blasting my whole node_modules often when testing fixes to ensure I'm working with a clean setup.

[jaysoo]

@vaibhavrja A link to a repro would help us debug this issue. As @ScottMorse alluded to, it's possible it's a misalignment of @nx/* package versions. Can you make sure they are all aligned and try again? If you still see an error, link a repro an provide what nx report outputs in your terminla.

[jaysoo]

@ScottMorse Feedback is alway welcome. We want the best DX we can create for our users. peerDependencies may not always work here since @nx/react doesn't need @nx/webpack, and vice versa (for example if users are using Next.js or Vite then they would not use @nx/webpack). For package managers that install peer deps, it would lead to unnecessary installs.

If you have some concrete issues please open a new issue, or if you have a feature request or a question you can open a new discussion. Thanks!

[ScottMorse]

@jaysoo Thanks, I've created #26477 to suggest using optional peer dependencies in order to make up for this.

[github-actions[bot]]

This issue has been automatically marked as stale because no reproduction was provided within 7 days. Please help us help you. Providing a repository exhibiting the issue helps us diagnose and fix the issue. Any time that we spend reproducing this issue is time taken away from addressing this issue and other issues. This issue will be closed in 21 days if a reproduction is not provided. If a reproduction has been provided, please reply to keep it active. Thanks for being a part of the Nx community! 🙏