When importing different modules from @angular/material
, each module is imported from a unique package path, following the format of
@organization/library/<module>
. For example:
import { MatSidenavModule } from '@angular/material/sidenav';
import { MatSnackBarModule } from '@angular/material/snack-bar';
import { MatSortModule } from '@angular/material/sort';
import { MatTableModule } from '@angular/material/table';
import { MatProgressSpinnerModule } from '@angular/material/progress-spinner';
Queries:
How can this method be implemented in a library?
I have a similar folder structure where each module has its own directory containing components/services/directives, and a
public-api.ts
file exporting all members. Additionally, there is a main barrel file at the root level that exports everything. When used in applications, modules are imported as follows:
import { FooModule, BarModule } from '@my-org/my-lib'
// Instead of
import { FooModule } from '@my-org/my-lib/foo'
import { BarModule } from '@my-org/my-lib/bar'
- What advantages does this approach offer compared to exporting all members directly from the root
@my-org/my-lib
path (if any)?