First-class support for secondary entrypoints in Angular libraries as individual nx projects

[daiscog]

Description

Allow individual entrypoints inside a buildable, publishable lib to be treated as individual nx projects, with full support for individual and cacheable builds, and dependency linting.

Motivation

We want to achieve the following structure:

|- libs
   |- domain-one
      |- project.json
      |- package.json    # "name": "@my-org/domain-one"
      |- src             # primary entrypoint sources
         |- index.ts
         |- etc...
      |- feature
         |- feature-a    # secondary entrypoint
            |- project.json
            |- src
               |- index.ts
               |- etc...
         |- feature-b    # secondary entrypoint
            |- project.json
            |- src
               |- index.ts
               |- etc...
      |- data            # secondary entrypoint
         |- project.json
         |- src
            |- index.ts
            |- etc...
   |- domain-two
      |- etc...
   |- shared
      |- etc...

We have many libs in many domains and we want to be able to use the enforce-module-boundaries lint rule to ensure certain lib types (e.g., feature/util/ui/data) within each domain can only import from certain other types of libs.

But we also don't want to have to publish hundreds of npm packages. Rather, we'd prefer to group our libs into domain-specific packages, where we have separate entrypoints for each lib.

We can sort of do this at the moment, but there are things that do not work so well.

Building

Currently, we have to build the entire package in one go with ng-packagr at the outer level. This means we lose the fine-grained cacheable builds of individual entrypoints. We would prefer if each entrypoint could be individually compiled and the build result be cacheable, so that changing one entry point does not require recompilation of all of the others.

Dependency linting

Where domain-one depends on shared/util/something, the @nx/dependency-checks lint rule thinks the package.json for @my-org/domain-one should contain a dependency on @my-org/shared/util/something instead of the @my-org/shared package it should depend on.

Also, when linting the package.json of the top-level project, the @nx/dependency-checks rule does not check that the dependencies of the secondary entrypoint projects are included in the top-level package.json, unless we enable the includeTransitiveDependencies - but doing that means we end up with all transitive dependencies being required instead of just the direct dependencies of the secondary entrypoints, which is the behaviour we want.

[FrozenPandaz]

I've converted this to a discussion so we can discuss more easily.

[daiscog]

Hey. I'm happy to answer any questions about our specific use cases, if you have any. :)

As an aside, I can imagine this might involve significant effort to get right when it comes to building the final package, particularly since ng-packagr have previously refused to add support for building secondary entry points independently. :(

[daiscog]

@FrozenPandaz how can we progress the discussion of this feature request?

It would be nice to know whether Nx are considering this or whether it's not likely to ever happen.

[vitor-dev-get]

I think it would be great if entry points were treated as libraries by Nx. This would help avoid adding unnecessary boilerplate configurations like tsconfig, package.json, and project.json, especially since, at least in the projects I work on, the configuration is always the same