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

контроллеры всё равно привязаны к модулю же

Ну как я понял они могут быть привязаны к модулю app

модуль изолирует какую-то предметную область.

Что ты имеешь ввиду?

А что это такое?)

кстати в динамические модули терь можно и импорты передавать  норм выходит

Например, ты хочешь отключить какой-то кусок функционала, отвечающий за генерацию документов.
Если всё, что за отвечает за генерацию, сгруппировано в модуль, то ты лезешь в app.module.ts  и убираешь там только один import. А если у тебя это не сгруппировано, то ты как патологоанатом начинаешь скальпелем вырезать ненужные куски.

То же самое если ты вдруг решил вынесть генерацию доков в отдельный npm модуль

ооо, понял. Спасибо!

не тока подменил но и добросил модули которые нужны новой версии сервиса

это можно сделать, но это не так явно как бы хотелось
на уровне объявления провайдера
тут проблема в js

да, но как же это неприятно

делал типа так

abstract class FsService { //some abstracts methods }

class LocalFS extends FsService { // impl abstracts methods }

у провайдере
{ provide: FsService, useClass: LocalFs } например, можно через useFactory и с env вытянуть какой адаптер юзать для fs

и в конструкторе
constrcutor( private fs: FsService )

Инверсия зависимости нужна для того, чтобы выскоуровневые политики не заисили от низкоуровневых (т.е. например, бизнес-логика не зависела от отображения). Фактически нужно избавиться от прямых импортов низкоуровневых политик внутри высокоуровневых политик. Это даёт DI. Но ‘нормальный’ DI должен быть построен на интерфейсах, nest же предлагает по умолчанию DI на типах классов, которые мы импортим откуда? из реализации. Т.е. наши зависимости остаются не развернутыми.

ага, боллерплейта больше, но становится сильно гибче.

Камиль это странно объяснил “ну у нас нет интерфейсов, потому ребята извините, мы будем предлагать плохие практики”.

Ах, ты про это. Ну да, это проблема. Я остановился на использовании констант для инжекта зависимостей и экспорте интерфейсов из сервиса, которые потом где-то имплементирую

Тогда ты сваливаешься в сервис-локатор

Всё же писать чистый конструктор без завязки на IoC-контейнер гораздо приятнее

Согласен