Извините... стоит все таки разобраться с базовой идеологией ангулара. Компоненты НИКОГДА не передаются инстансами. Более того, вы НЕ СМОЖЕТЕ взять компонент и использовать его "как есть" - вам понадобится МОДУЛЬ, в котором данный компонент задекларирован. Соответственно, обращаясь к компоненту (да вообще к любой сущности ангулара) - что через верстку, что через роут - вы запрашиваете МОДУЛЬ.

они разбросаны не по всему проекту, а лежат рядом с lazy loading модулем, путь к которому прописывается в app-routing или еще каком-то рутовой модуле

отлично. значит код ангуляра написан достаточно хорошо чтобы через неделю я это уже понял! спасибо

да. у меня лежит вот
app-routing.ts
куда подключаю фронтенд модули материал там разные гриды и компоненты

и апп модуль
куда подключаются сервисы ресурсы и вся дичь

апп модуль старше, роутинг - отвечает за внешку. он один. но forChild/forRoot написано в смысле что мы будем дробить роутер чуть ли не на группы страниц - одна доменна область - один роутер

и получается 2 помойки, одна со всеми компонентами и зависимостями для всех компонентов, и одна со всеми роутерами без ленивой загрузки

я так на бекенде делал и ничего хорошего кроме путаницы и трепачества это не дало

ну так там роуты лежат и десяток фронт модулей, которые без вызова ничего не делают.
отличный контейнер зависимостей так и делают

не надо практики бэкенда тащить в сферу с другими инструментами и концептами. Бэкенду не надо думать что браузер не должен получать 1 js файл на 10 мегабайт, а получать приложение частями по мере надобности

в беке. в джаве. в пыхе.
делают ящик с зависимостями которые создают обьект когда в конструктор чегото попадают. а делкарируются в общем конфиге. в этом и есть идея

в этом есть соль!
в таком случае как дебажнуть папку dist на предмет того на какие чанки сие дробится?

и чем будет отличатся дробление 10 роутеров каждый из которых подключен в родителя от одного роутера

с глубочайшим уважением к вашему опыту бекэнда... это НЕ бекэнд. Это другая экосистема со своей идеологией. Ее можно принять и пытаться разобраться и работать. Можно не принять и пытаться переломать через колено. Вот и вся вилка. Пока что ситуация выглядит следующим образом: "тут все сделано не так как я привык, надо все сделать по другому". Правомочная точка зрения. Берется и пишется СВОЙ фреймворк, где делается все так, как хочется самому.

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

а сегодняшние девы (а я сменил 10 компаний) именно такие.

если это фронтенд то он не бекенд поэтому не лезте, мы здесь шарим. отлично. шарите. как делать? не знаю. так вы ж шарите.

в моем бекенде я знаю до запятой как что делается и диссертацию написал бы и не одну. просто на сцене у нас тренера, у которых бизнес. а не ученые у которых диссертация

смешались в кучу кони, люди...

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

посмотрите доку по билду. там есть все флаги, в тч по тому, как чанки проверить. я за рулем, гуглить неудобно