Member-only story
The Best Way To Architect Your Angular Libraries
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-packagrsub-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 use it!
What we’re going to learn
- How to create Angular library implementing clean architecture from scratch (demo project included)
- How to implement sub-entry per feature (and how to simplify the process using
ng-samuraischematics) - How to define proper Typescript
“paths”aliases - How this architecture and setup automatically saves us from using incorrect imports or introducing circular dependencies
- How to analyze our library structure with
madge - How to consumer library in other applications
- How to make stuff private
- How to bring dependencies into consumer applications (dependencies vs peer dependencies)
- How to create demo application for a library in local workspace
- How to make this work with…
