enforce-module-boundaries - Support secondary entry points in workspace libraries

Description

Currently the enforce-module-boundaries only looks at project level and not at the entry points for workspace libraries. This means that when using secondary entry points and importing between libraries can result in a circular dependency between projects.

Using the following library structure:

   .
   ├── ...
   ├── libs
   │   ├── api
   │   |   └── src/lib
   |   │     └── services
   |   └── util
   │       └── src/lib
   │          ├── logging
   │          └── validation
   ├── ...

With the following paths in TSConfig.base:

"paths": {
   "@api/service": ["libs/api/src/lib/service"],
   "@util/logging": ["libs/util/src/lib/logging"],
   "@util/validation": ["libs/util/src/lib/validation"]
 }

Using the logging module in service while using the service module in validation results in a circular dependency between projects. Error:

 Circular dependency between "util" and "api" detected: util -> api -> util
 
 Circular file chain:
 - libs/util/src/lib/validation/validator.ts
 - [
    libs/api/src/lib/services/reference/reference-service.ts
   ]

Motivation

Normally this would be correct, but since I am using secondary entrypoints in my libraries (index.ts in each separate folder with a TSConfig path pointing to it) I do not reference the whole project, what should mean there is no circular dependency. The linting rule should not throw a Circular dependency detected error.

Suggested Implementation

Since the current implementation of a creating a secondary entry point for a library only works with buildable & publishable libraries (it requires a package.json in the library itself), the feature should be extended to also support workspace libraries.

Alternate Implementations

An alternative option would be to be able to configure the linting rule to check for the actual import instead of only looking at projects. The only catch is that this should be configurable per project, since not all projects within the monorepo will use the secondary entry points.

[RobinvanTienhoven]

My apologies for the late response. I think you are right about ‘making the linter understand’ is not the right thing to do and that our implementation is wrong. We’ve decided to further look into this and restructure our libraries to fix this issue the correct way.

Thank you for the help!

[meeroslav]

Thank you @RobinvanTienhoven for follow-up. I will therefore close this issue.