-
Notifications
You must be signed in to change notification settings - Fork 2.2k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Module Federation Dev Server uses env variables to pass data, this breaks caching #21390
Comments
Hi @statop ! You can fix this easily by adding the following to the For Angular: "@nx/angular:webpack-browser": {
"inputs": [{
"env": "NX_MF_DEV_SERVER_STATIC_REMOTES"
}]
}, For React: "@nx/webpack:webpack": {
"inputs": [{
"env": "NX_MF_DEV_SERVER_STATIC_REMOTES"
}]
}, I will create a PR to add this to the nx.json when an MF generator is invoked. |
The problem I see with that is that It requires a new build of all deps. I actually just ended up writing our own dev server for various reasons. What I did was create a proxy expressjs instance for each static remote on the correct port that just forwards to the "master" static remote server and pre-pends the project name to the url. That way the build output is always the same for static and non-static builds. |
@statop this would mean you need an express instance for every static remote though right? |
Correct. I don't think that is too bad. Certainly not as bad as a whole nx nodejs process. Maybe a more lightweight http server could be used, but express is about as light as they get. |
So we did investigations around this, and we created forked processes to spin up individual servers for each remote. the result was that RAM usage increases as number of remotes increases. As such, it’s not a scalable solution. ~50 remotes is enough to kill a 2019 MacBook Pro (Intel) with 16gb RAM. My laptop is evidence to this. Which is what led us to the solution we currently have. a new build is only needed if the development configuration for the remote(s) has been built in a separate process not via shell. This shouldn’t occur often, and therefore cache will be hit more often than not. |
Creating forked processes, yes it would do that. But multiple expressjs in the same process will not do that. I just ran this code on my machine and the node process is running at 149mb of ram.
|
To be clear, in my dev server, all the epressjs instances are in the same process as the dev server. |
Ok I understand more clearly what you’re doing now. This seems like a neat solution. Let us evaluate it. |
Reopening this until we explore the option of multiple express servers in a single process further |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Current Behavior
If I build a module, and then run a federation dev server that uses that module as a static remote, the static remote does not work.
Expected Behavior
If I build a module, and then run a federation dev server that uses that module as a static remote, the static remote works.
GitHub Repo
No response
Steps to Reproduce
See above
Nx Report
Failure Logs
No response
Package Manager Version
pnpm 8.14.3
Operating System
Additional Information
This is the bad code - https://github.com/nrwl/nx/blob/master/packages/react/src/executors/module-federation-dev-server/module-federation-dev-server.impl.ts#L162
Basically env variables are ignored by the nx cache, so building the static remote will pull from cache even if the cached build did not include that env variable.
The text was updated successfully, but these errors were encountered: