The Best Way To Architect Your Angular Libraries

Sometimes it’s just worth doing it right from start 😉 (📸 by Gabriel Sollmann )

Check out video from Berner JS meetup with live coding of the concepts presented in this article!

The context

The ideas presented in this article are based on extensive experience from large enterprise environment (100 Angular SPAs and 30+ libs )…

🤫 Wanna know how we can manage such a large environment without going full crazy 😵 Check out Omniboard!😉

To be more precise, the initial impulse to explore this topic was creation of a second “component framework” (think internal Angular Material) following this approach and comparing it to the original one which does NOT use the ng-packagr sub-entries…

The sub-entries facilitated tree-shaking means that when we import something, eg a MyOrgDropdownModule then we’re only getting implementation of that sub-entry (and sub-entries it explicitly imports, eg it may use MyOrgIconModule ) and nothing else!

Think 1.5 MB vs 50 KB in such scenarios…

More so, this also works wonders in the context of lazy loaded modules (so not just main / eager vs lazy) as the sub-entries enable Angular CLI to do further optimization like extracting a sub-entry into virtual chunk that will only be loaded for particular set lazy loaded features that really…