You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now back to the main issue: since @nx/enforce-module-boundaries "force" me to do a relative import, the relative import doesn't match in the additionalShared configuration, and thus break the share (and everything breaks, because the context is not a singleton anymore).
Wykks
changed the title
@nx/enforce-module-boundaries wants relative import to main lib in secondary entrypoint, but MFE shared fail
@nx/enforce-module-boundaries wants relative import to main lib in secondary entrypoint, but MFE share lib fail
Jun 26, 2024
Both aspects are working as expected. You've created an alias essentially by having the secondary entrypoint and are expecting that alias to be treated as a package in your MF setup.
Enforce module boundaries sees it as a child and wants a relative import.
You can disable the enforce module boundaries eslint rule for that particular import.
Humm, yes what's happening make sense , but it does take a while to understand what's happening with shared lib, and this behavior doesn't help at all (which is the opposite of what an eslint rule should do).
It does work out of the box with Angular. Also I'm pretty sure secondary entry points are shared out of the box in Angular too (because, again there's some Angular specific code in the main code path).
At least there should be some notice in the doc that creating a secondary entry point in a MFE setup doesn't work out of the box when using something else than Angular.
Listing all entrypoints of all libs to fill additionalShared of MFE config, and the allow option of @nx/enforce-module-boundaries is not something you should expect to do with nx, I think. (Which is why you actually support this with Angular)
Current Behavior
In a Module Federation context:
I have an React library with some code in the main entrypoint.
I want to import a context, which is located in a secondary entrypoint.
I use
additionalShared
fromModuleFederationConfig
to explicitly all entry point of my lib.By the way this config
additionalShared
is really missing some documentation, it took us a while to find a way the share secondary entry points, as it's supposed to share automatically https://nx.dev/concepts/module-federation/manage-library-versions-with-module-federation#how-are-library-versions-determined , but it doesn't work out of the box. And this documentation doesn't mention thatadditionalShared
exist.Now back to the main issue: since @nx/enforce-module-boundaries "force" me to do a relative import, the relative import doesn't match in the
additionalShared
configuration, and thus break the share (and everything breaks, because the context is not a singleton anymore).Expected Behavior
I've seen that the code of @nx/enforce-module-boundaries check for secondary entry points only for Angular https://github.com/nrwl/nx/blob/master/packages/eslint-plugin/src/rules/enforce-module-boundaries.ts#L385 (because in Angular we can't do relative import to secondary entry points to build the lib). But it should also do it for others framework/lib because of this.
GitHub Repo
No response
Steps to Reproduce
additionalShared
in module-federation config, for all apps like this:Nx Report
Failure Logs
No response
Package Manager Version
No response
Operating System
Additional Information
No response
The text was updated successfully, but these errors were encountered: