ESLint enforce-module-boundaries rule fails with library split in secondary entry points and mixed loading scenarios

[edbzn]

Current Behavior

The ESLint rule enforce-module-boundaries enforce libs to be lazy loaded as far as a dynamic import is detected. This is great for most scenarios, but not working well when a library is split into multiple secondary entry points.

Consider the following scenario where lib A is split into 2 secondary entry points core and feature, and lib B needs to lazy load feature and to statically load core:

Then the enforce-module-boundaries rule is failing because lib A is marked as "lazy", and everything should be lazy loaded as far as a dynamic import is detected.

import { CommonModule } from '@angular/common';
import { NgModule } from '@angular/core';

/* Here is the line that throws "Static imports of lazy-loaded libraries are forbidden."
   but static import of the secondary entry point "core" should be allowed. */
import { CoreModule } from '@myorg/lib-a/core';

/* Only "feature" is lazy, not the whole library and all the secondary entry-points. */
async function getFeatureModule() {
  const  { FeatureModule } = await import('@myorg/lib-a/feature');
  return FeatureModule;
}

getFeatureModule();

@NgModule({
  imports: [CommonModule, CoreModule],
})
export class LibBModule {
}

Expected Behavior

Statically importing core secondary entry points should not throw static imports of lazy-loaded libraries are forbidden.

Secondary entry points should be taken into account when checking for static imports when a library is considered lazy, allowing the rule to statically import secondary entry points that have not been imported dynamically.

GitHub Repo

https://github.com/edbzn/nx-static-import-issue/tree/main

Steps to Reproduce

1. Clone the reproduction
2. Run nx lint lib-b
3. See the line that is failing

Nx Report

nx 16.6.0

Failure Logs

No response

Operating System

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

Additional Information

No response

[meeroslav]

Thank you @edbzn for reporting this.

To be honest, this was on our list for a while. We will get to it as soon as possible.

[plutotv-aaa]

Thank you for working on this. Is there any update @meeroslav? Much appreciated.

[meeroslav]

Sadly not yet

[montella1507]

Hi i have come here to create issue when i saw i had been already created.

This is really common for shared libraries with secondary entry points as a code-splitting / tree-shaking implementation.

We have several huge applications with libraries (@company/ui for the instance) which are usually small and eagerly loaded (in HTML template of parent components, imported etc)...

however there are huge components too, which are usually loaded lazily (with custom dyanimc-component, dynamic import(), or... with the latest defer() angular feature).

import('@company/ui/secondary-entry-point')

defer() is at the moment not possible to use as far as the component is usually loaded as secondary entry point...

@meeroslav is it possible to escalate this issue, pllease?

[de-don]

+1

[tiddlypip]

Looks like theres a checkDynamicDependenciesExceptions option, seems you can add lazy loaded imports to this but haven't had the opportunity to try it yet: https://nx.dev/nx-api/eslint-plugin/documents/enforce-module-boundaries

[montella1507]

Yeah, however this will lead to 40 exceptions in our case as far as we have /ui library with lot of components and secondary entry points and ...as far as defer does not work effectively without that and we have lot of "3rd party" huge libraries involved in them (spreadsheets etc.)

IT does not sound so "exceptional" then :D

[supernaut]

Not sure if this would cover it, but similarly I would love for the @nx/enforce-module-boundaries rule to be enforced on components in Next.js libraries with 'use client' but not server components.

[wizardnet972]

Any updates?

[frozenwings]

Any updates?

[joarkm1]

I see that secondary entry points do not appear as separate nodes in nx graph. Maybe they should be?

[pvds]

Thank you @edbzn for reporting this.

To be honest, this was on our list for a while. We will get to it as soon as possible.

HI @meeroslav is this issue planned or on any roadmap?
Would be awesome if NX can also "understand" secondary entrypoints!

[github-actions]

This issue has been automatically marked as stale because it hasn't had any activity for 6 months.
Many things may have changed within this time. The issue may have already been fixed or it may not be relevant anymore.
If at this point, this is still an issue, please respond with updated information.
It will be closed in 21 days if no further activity occurs.
Thanks for being a part of the Nx community! 🙏

[montella1507]

@joarkm1

I see that secondary entry points do not appear as separate nodes in nx graph. Maybe they should be?

Please no. Or opt-in. Every bigger monorepo has hundreds of SEPs...

[meeroslav]

This issue will have to be fixed with two PRs.

The first one (#30809) solves the problem for Angular, which has a clearly defined secondary entry point definition.

Follow-up for standard ESM packages should include general support for secondary entry points.

See update below 👇

[meeroslav]

Decided to fix everything in a single PR:

• Add support for package.json-based entry points
  • Include parsing of conditionals and nested exports
• Check if the static import belongs to the secondary entry point before raising the Static imports of lazy-loaded libraries... error

Please note that right now, our graph does not track the exact import expression. We only store the project name and type of import. This limits us to covering all corner cases. For example, importing from the same secondary entry point both statically and dynamically would not be flagged as an error.

[github-actions]

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.