Library secondary entry points

Description

I am not sure if this would be possible, but it could have a great potential of building publishable libraries within Nx workspaces.

I am wondering if it would be possible to get introduce secondary entries to publishable libraries, similar like ng-packagr is doing, but with the detached build from the main library?

Right now ng-packagr builds the whole library including all the entry points. This defeats the purpose of Nx. So my suggestion or rather question is, if would be possible to build only the entry point changed and use the rest from cache? I am aware this would probably have to be implemented in Nx completely without reusing much of ng-packagr functionality, but in my eyes this could be well worth it.

Example

Library structure:

• @myOrg/library
• @myOrg/library/first-entry
• @myOrg/library/second-entry

Change detected in @myOrg/library/first-entry:

• Nx only builds first-entry and leaves the rest as is

Currently:

• Nx triggers ng-packagr which builds whole library with both entry points

Solution

Speculating enormously here, but maybe we could use non-publishable libraries instead of ng-packagr entry points to get the result?

[olofens]

Hey guys, I’m using ng-packagr secondary entry points in my Nx monorepo. Here’s what I did: https://olofens.medium.com/secondary-entry-points-in-an-angular-nx-library-8d01a80634cc

I realize though that it doesn’t help with detached build.

[BeSpunky]

I actually tried something similar last week, where I created a lib for every entrypoint, then created the main (publishable) lib with the same structure as before, but only including imports and exports. Something like this:

libs/
|-- main-library
     |-- entrypoint-1 (imports from libs/entrypoint-1 + exports)
     |-- entrypoint-2 (imports from libs/entrypoint-2 + exports)
|-- entrypoint-1 (actual code)
|-- entrypoint-2 (actual code)

This builds successfully and computational caching works. However, and I should’ve guessed it, the dist/main-library folder only contains maps and definition files. The actual code is not there which makes the folder useless.

Maybe there’s some webpack config to force the code to be copied from the compiled libs and not just referenced, but my webpack knowledge is not there yet. Furthermore, as @rcuddy mentioned, this may quickly lead to chaos in the codebase.

Conclusion, the NX team should find a way to seamlessly integrate computational caching for secondary entrypoints. This is VITAL for a publishable library. Any other solution is probably going to involve hacking or unmaintainable configuration…