-
Notifications
You must be signed in to change notification settings - Fork 243
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
React module federation gives __federation_shared_react-dom-6fc2ee8d.js:224 TypeError: Cannot read properties of null (reading 'useContext') at react_production_min.useContext (__federation_shared_react-af90d75c.js:59:144) #595
Comments
To reproduce create a component based on @mui/x-date-pickers on remote project. |
The root component might be @mui/material/Popper. Can anyone help check it? Thanks. |
After further digging, it is caused by @mui/system/useThemeWithoutDefault. Not sure how to solve it in vite federation plugin, webpack module federation works fine. |
Hi, I think your error is repeated Issue 294. When I have had the same problem I have solved it by adding to the host component the dependencies of the remote component, this is not an optimal solution but it can get you out of trouble. |
Same problem here, it looks like it's using |
I cannot stress enough how critical managing dependency versions is when using this plugin, especially when dealing with singleton patterns like React's context. Recently, I encountered issues related to context API failures in a federated module which was indirectly caused by mismatched library versions. It turns out, the root cause was related to how versions were specified in package.json. For instance, specifying a dependency version with a caret (^), such as react-router-dom:"^6.8.2", allows npm to install minor updates automatically. This can lead to scenarios where your lockfile points to a newer version than you explicitly tested with, like 6.23.0 in this case. Here’s what you might see in your yarn.lock or package-lock.json:
This scenario highlights the importance of using exact versions in federated modules or at least being very deliberate about version ranges. In a federated environment, unexpected updates can lead to incompatibilities, especially if different versions of the same package end up being loaded in the host and remote apps. A safer approach could be to remove the caret (^) and pin the dependencies to exact versions to prevent such issues in both your host and remote apps:
This ensures that all instances of the application, across different federated modules, use exactly the same version, reducing the risk of runtime errors due to version mismatches. While this might reduce flexibility in quickly receiving updates, it adds a layer of reliability and predictability to your build and deployment processes in a federated architecture. Hope this helps anyone struggling with similar issues, if anyone has any alternative solutions please let me know! The plugin should ideally manage these dependencies more effectively, especially as the number of federated apps grows, making manual dependency management increasingly complex which is not an ideal scenario. |
see this #596 (comment) |
@J-cyber-d try to add date-picker and @emotion/styled in host and remote shared scope. |
Host App vite.config.js file
Remote app vite.config.js
Getting an Same Error |
Here is my vite.config.js
|
Does anyone have a working solution or work around for this? |
I can confirm this is exactly where it falls over.
All other packages, including |
React module federation gives __federation_shared_react-dom-6fc2ee8d.js:224 TypeError: Cannot read properties of null (reading 'useContext') at react_production_min.useContext (__federation_shared_react-af90d75c.js:59:144)
Is it due to the removal of singleton option in shared?
The text was updated successfully, but these errors were encountered: