So I want to create shared libs in my angular project. I have listed down below my two approaches, which both do their job, but I don't which is the better one, that I should implement.
libs
├── [...]
└── shared
└── ui (lib)
├── ui-card (component)
└── ui-*
libs
├── [...]
└── shared
├── ui-card (lib)
│ └── card (component)
└── ui-* (lib)
└── *
This article states that I should follow my second approach, but it's not explained why you should create a lib for each ui: https://medium.com/showpad-engineering/how-to-organize-and-name-applications-and-libraries-in-an-nx-monorepo-for-immediate-team-wide-9876510dbe28
It would also be nice to know, if the solution to my problem can also be used for data-access and util libs
If you have multiple components in one module, your final bundle will contain all of them, even if you use just a fraction of it.
If you create one module per component (or components that always are used together), your bundle size is more efficient but you end up having more boilerplate code.
The second approach is also the one that is followed by Angular Material.
When we are dealing with a UI lib which is part of an application, I don't see the need to have one module per component.
If you publish your UI library as "real npm library" like Material, it is a different story.
I would definitely not follow the second strategy for data-access, util and feature libs. Those are usually designed for the specific needs of an application, i.e. you will need all of them and in that case less boilerplate counts more.