Ability to disable sub entry points

Type of Issue

[ ] Bug Report
[x] Feature Request

Description

As a library developer, I would like to have the possibility not to build sub entry points (for dev builds).

Details

We are experiencing build performance issues with our Angular library (30+ sub entries) even after migrating to Angular 10 (related to #1222).

lib build time (seconds)	ng 8	non-Ivy (ng 10)
with sub-entries	194	90.93
without sub-entries	36	32.08

This is why we decided to have 2 separate builds:

• a production one with sub-entries so that the library is tree-shaked
• a development one without sub-entries - anindex.dev.ts barrel that exports the sub-entries.

In order allow both builds without chaing the code, we created a custom Angular builder that:

1. generates package.json files for each sub-entry
2. builds
3. cleans-up previously generated package.json file.

Expected Behaviour

I would like to have a configuration flag so that ng-packagr ignores sub-entries. This way we can run ng-packagr for the dev build without the pre/post build processing.

Version Information

$ node_modules/.bin/ng-packagr --version
ng-packagr: 10.1.0
@angular/compiler: 10.0.14
typescript: 3.9.7
rxjs: 6.6.3
node: 12.13.1
yarn: 1.21.1

[victorsc]

Hi @SchnWalter

I generated a skeleton library and added 50 modules.

yarn && yarn run build // build time ~ 8 seconds
git checkout sub-entries && yarn run build // build time ~47 seconds

[SchnWalter]

From what I can tell, scheduleEntryPoints is creating a lot of class instances for each entry point. We might be able to reduce the resource usage and the build duration by reusing some of the instances, but this will be tricky when it comes to external packages like the mainNgcc process from @angular/compiler-cli/ngcc:

https://github.com/ng-packagr/ng-packagr/blob/2f470e0b7742b1a517ddd2bb33c603344c3294c5/src/lib/ngc/ngcc-processor.ts#L57-L65

For any change, we’ll need to make sure that we don’t introduce regressions and we’ll need to start adding benchmarks and tests. And we’ll need to check with the Angular Core team if the ngcc process can be reused, it probably can, because we have support for live-reload.