На мой взгляд, самое важное — это время загрузки первого экрана. Это можно достичь просто разбив приложение на lazy modules, как вы уже делаете сейчас.

Когда приложение уже запущено и что-то отображает, то не так важно, сколько будет весить дополнительный чанк, потому что хорошей практикой будет этот чанк предзагрузить до того, как он понадобился. Иначе пользователю придется ждать, пока необходимые модули загрузятся. А так как это происходит по сети, то не особо важно на 10кб меньше или больше придется загружать — лаг все равно будет.

Если хочется попрофилировать зависимости, которые попадают в основной бандл и другие чанки, то можно воспользоваться этими тулзами:
https://angular.io/guide/deployment#inspect-the-bundles
https://www.npmjs.com/package/webpack-bundle-analyzer (не забудьте добавить флаг ng build --stats-json при сборке)

.
└── src
    ├── modules
    │   ├── auth
    │   │   ├── auth.guard.ts
    │   │   ├── auth.interceptor.ts
    │   │   ├── auth.module.ts
    │   │   └── auth.service.ts
    │   └── user
    │       ├── user.component.html
    │       ├── user.component.scss
    │       ├── user.component.ts
    │       ├── user.directive.ts
    │       ├── user.module.ts
    │       ├── user.pipe.ts
    │       └── user.service.ts
    └── pages
        ├── login
        │   ├── login.component.html
        │   ├── login.component.scss
        │   ├── login.component.ts
        │   └── login.module.ts
        ├── logout
        │   ├── logout.component.html
        │   ├── logout.component.scss
        │   ├── logout.component.ts
        │   └── logout.module.ts
        └── settings
            ├── settings.component.html
            ├── settings.component.scss
            ├── settings.component.ts
            └── settings.module.ts

login и logout импортируют auth, и используют оттуда только сервис, чтобы выполнять действия
settings тоже импортирует auth, но использует только гард, чтобы пускать только залогиненного юзера. также settings импортирует user и использует его компонент, чтобы вывести информацию о юзере

как-то так примерно. я прав?

спасибо большое. юзаю webpack-bundle-analyzer, хорошая штука

а по структуре я правильно понял? предыдущее сообщение

я там пропустил папку app и не делал routing модули, но не суть)

Да, в целом норм

.
└── src
    ├── modules
    │   ├── auth
    │   │   ├── auth.guard.ts
    │   │   ├── auth.interceptor.ts
    │   │   ├── auth.module.ts
    │   │   └── auth.service.ts
    │   └── user
    │       ├── user.component.html
    │       ├── user.component.scss
    │       ├── user.component.ts
    │       ├── user.directive.ts
    │       ├── user.module.ts
    │       ├── user.pipe.ts
    │       └── user.service.ts
    └── pages
        ├── login
        │   ├── login.component.html
        │   ├── login.component.scss
        │   ├── login.component.ts
        │   └── login.module.ts
        ├── logout
        │   ├── logout.component.html
        │   ├── logout.component.scss
        │   ├── logout.component.ts
        │   └── logout.module.ts
        └── settings
            ├── settings.component.html
            ├── settings.component.scss
            ├── settings.component.ts
            └── settings.module.ts

Всё хорошо ток вот забрать pages modules

зачем?

А зачем они?

чтобы структура легко сканировалась глазами, а не прям всё в куче. хоть минимальное разделение на features и pages

А теперь представь что их нет, и что измениться ?

Я также быстро нахожу всё что нужно

Ребята, всем привет, подскажите, пожалуйста, почему не отрабатывает пайп у возвращаемого observable?

delay(500) судя с контекста

Стивен флюин советовал вместо webpack-bundle-analyzer использовать source-map-explorer

будет не ясно, какой из модулей представляет из себя страницу и содержит роутинг. я так-то в любой структуре в своём приложении быстро ориентируюсь, потому что помню наизусть. но посадите нового человека, и как быстро он разберётся в общей куче модулей? если у человека стоит задача "пофикси то-то на такой-то странице". ему будет проще, если искать страницу нужно будет только в pages

У вас задача заводиться контекстно? По страницу по модулю

Задачу заводит рандомный куа какой не шарит вашу архиектуру

И скорее всего он в баге напишет сраницу а не фичу

вот именно. и я ж о чём. в задаче будет говориться про "страницу", поэтому и искать нужный модуль легче в папке "страницы"

У меня такое чуство, что у вас имена фичи и пейджы совпадают