Why are component modules exported as separate entry-points?

[Nathaniel Palmer]

I'm building an Angular library for internal use at my company and initially we followed a layout similar to @angular/material where each component is part of a separate NgModule and is exported via a separate secondary entry-point (e.g. "@angular/components/button" instead of "@angular/components"). However I can't find any documentation for why @angular/material is structured this way and I'd like to understand the rationale in order to decide whether this pattern still makes sense for my project. I seem to remember it being related to tree-shaking but nothing in the official Angular docs indicate that would be the case.

[Shane Hsu]

Probably beachside people can then import what they need. For example, my application imports only one part of the library.

Though tree-shaking, in theory, can shake those unnecessary code away. It is just simpler to let people include only what they need.

[Shane Hsu]

*because

[Adrien Crivelli]

I have the exact same use-case and question. The maintenance and usage of multiple modules for a single library is a small overhead. And I have been wondering if there is any benefit to it. Given that my library is not too huge I assume that it would be reasonable to import the whole thing and let tree shaking do its job automagically.

I didn't test out the idea in practice though. And I don't know if this would have any impact on the final bundle size (smaller or bigger). So I too would like to hear from Angular team, or other lib maintainers, what is the rationale of having multiple modules ?