@nx/enforce-module-boundaries wants relative import to main lib in secondary entrypoint, but MFE share lib fail

[Wykks]

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 from ModuleFederationConfig 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 that additionalShared 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

1. Create a simple module federation projet following https://nx.dev/concepts/module-federation/micro-frontend-architecture
2. Add a library with two entry points "@acme/myLib" "@acme/myLib/context"
3. Add a relative import from the first entry point to the second entry point
4. Configure additionalShared in module-federation config, for all apps like this:

  additionalShared: [{
    "@acme/myLib",
    sharedConfig: {
      requiredVersion: '0.0.1',
      eager: false,
    }, {
    "@acme/myLib/context",
    sharedConfig: {
      requiredVersion: '0.0.1',
      eager: false,
    }]
  })),

6. Import the library from the both micro-frontend apps
7. And some console log to check if the entry points are exactly loaded once

Nx Report

Node   : 20.14.0
OS     : linux-x64
npm    : 10.7.0

nx                 : 19.2.3
@nx/js             : 19.2.3
@nx/jest           : 19.2.3
@nx/linter         : 19.2.3
@nx/eslint         : 19.2.3
@nx/workspace      : 19.2.3
@nx/cypress        : 19.2.3
@nx/devkit         : 19.2.3
@nx/esbuild        : 19.2.3
@nx/eslint-plugin  : 19.2.3
@nx/react          : 19.2.3
@nrwl/tao          : 19.2.3
@nx/vite           : 19.2.3
@nx/web            : 19.2.3
@nx/webpack        : 19.2.3
typescript         : 5.4.5
---------------------------------------
Registered Plugins:
@nx/vite/plugin
@nx/eslint/plugin

Failure Logs

No response

Package Manager Version

No response

Operating System

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

Additional Information

No response

[Coly010]

I think this is fine and makes sense.

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.

// eslint-disable-next-line @nx/enforce-module-boundaries

Or you can configure it in the eslintrc file.

[Wykks]

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)