Hi Wayne!

So everything in here will be based on latest Angular 12.1.2 (with IVY as I have learned today is no longer possible to disable it anyway in the latest version)... I have a small test repo for that so I re-run all scenarios today...

Now, we have a commonjs dep in library `ModuleC` and we want to consume it in consumer app `LazyModuleC`, the dependency is for example moment but any should behave the same...

Without it we get...

main.js ~ 206.98 KB

With it we get...

main.js ~ 578.63 KB

So this is JUST importing module `ModuleC` from lib which has a declaration for component which imports `moment`, the component itself IS NOT used in any template of any component in the consumer...

So here we see that using ANY commonjs dep will break tree shaking without sub-entries...

We have successfully tree shaked such deps with sub entries when developing component libraries (eg ngx-datatable was pretty heavy)

Now for the components itself, there was a problem without IVY which we reproduced when importing `LibModuleA` in eager part of the consumer and `LibModuleB` in some lazy loaded module of the consumer and `LibModuleC` which has declaration to `LibCompC` which has 100kb of random string in its property would end up in main.js even though the `LibModuleC` was never imported (not just in webpack bundle analyzer which is often out of sync but physically in bundle file we could find the string)

This is because without sub-entries, everything ends up in a single file and then some other stuff around webpack, module concatenation and inlining of contexts when the eager / lazy boundary confuses optimization so it can't determine which parts of that single lib file are safe to delete...

Now this seem to work just fine with IVY, in a way that if we dont use 100kb `ComponentC` then it is tree shaken, BUT if we use it in LAZY C in consumer... the 100kb end up in main.js not in lazy-c.js which is a problem.

This happens in case some of the LIB modules are consumed in eager and some in the lazy part, it does NOT happen if every lib module is consumed in the lazy part...

Summary of NOT using sub-entries:

* breaks commonjs

* breaks code splitting when imported in both eager and lazy parts (even with IVY)

Hence we went with sub entries which represent some overhead BUT also come with other cool properties like enforcing clean architecture in the lib itself!

Hope that helps, cheers!