-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Dev remotes appears to only work with the last alphabetized remote. #11615
Comments
I'm seeing the same issue. Would love a fix. |
I wondered if anyone could point me in the general direction of where a fix for this might live - this is quite critical for us so I'm more than happy to submit a fix ! |
A workaround for us at the moment would be to always include the last alphabetized remote in your list of |
Any updates here? This is still an issue on latest NX from what I can tell. |
After some investigation, it looks like the behavior is coming from webpack's We will continue to look into this issue, but in the meantime you can unshare some workspace libraries using the following: // module-federation.config.js
module.exports = {
shared: (libName, libConfigFromNx) => {
return libName === '@react-module-federation/shared-components'
? false
: libConfigFromNx
},
// ...
}; This will force the remote app to load its own version of the workspace library. Be careful though, if the library requires shared state (like redux) then this strategy will not work. You also need to define this config for each app, so it might be good to have a base config at the workspace root and reuse it. |
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. |
Not stale, still an issue |
We have a solution for this finally by using the |
- feat(module-federation): use @module-federation/enhanced for withModuleFederation - feat(module-federation): expose API for users to override module federation plugin options - fix(module-federation): angular mf ssr projects should not create vendor chunks - feat(module-federation): add nx-runtime-library-control-plugin <!-- Please make sure you have read the submission guidelines before posting an PR --> <!-- https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr --> <!-- Please make sure that your commit message follows our format --> <!-- Example: `fix(nx): must begin with lowercase` --> <!-- If this is a particularly complex change or feature addition, you can request a dedicated Nx release for this pull request branch. Mention someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they will confirm if the PR warrants its own release for testing purposes, and generate it for you if appropriate. --> ## Current Behavior <!-- This is the behavior we have today --> A common occurrence when working with NX Module Federation is that a shared library may get resolved from a static remote. Any changes to the shared lib are therefore not reflected in the dev server. ## Expected Behavior <!-- This is the behavior we should expect with the changes in this PR --> Add the `nx-runtime-library-control-plugin` to ensure that shared libraries are shared from a remote that is served via webpack-dev-server. ## Related Issue(s) <!-- Please link the issue being fixed so it gets closed when this is merged. --> Fixes #11615
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. |
Using the React sample https://github.com/nrwl/react-module-federation, if you run
nx serve host --open --devRemotes=shop
You can modify the greeting.tsx and see the HMR work and update the component.
If you run
nx serve host --open --devRemotes=about
The HMR does not reload and the changes are not reflected.
The text was updated successfully, but these errors were encountered: