А, понял, ты о том, что некоторые модули будут и на версии 1 и на версии 2 сидеть?

Ну кстати тоже кейс

Я бы в общем для задела на будущее роутер сразу взял

/help

Ну, это еще мне напоминает о каком-то принципе из ооп, не могу сейчас вспомнить, крутится на языке)

Инкапсуляция?

Об этом я в курсе конечно, но вроде немного не тот случай

Как хорошо, когда не нужно версионироаать API, тот ещё головняк )

Похоже на принцип инверсии зависимостей)

Тут оно не в том плане что какая-то неправильная зависимость между модулями, скорее в том что в реализации будет хардкод версии, который должен быть на уровне выше

Ну, это чисто мое восприятие) Хз как на деле, но вот один минус мы нашли уже по части реюзабельности)

Можно закинуть через DI версию в него :)

Нууу наверное да, но что-то оверкилл)))

Но вообще если модуль является фасадом над API то он может и знать версию. На экспрессе такой фасад можно на раз-два накидать, но нест из коробки не даст конечно

Да, с нест-роутером удобней

Посмотрел nest-router, с его помощью всё можно сделать, но придется заниматься менеджментом конфига с роутами, т.к. для создания новой версии, потребуется полностью скопировать дерево роутов, при внесении изменений не забывать просматривать предыдущие деревья на предмет необходимости внесения изменений и в них и т.д. Для проекта в несколько сотен роутов это может стать проблемой в перспективе. Поэтому я посмотрел как nest-router реализует свою логику и сделаю свою реализацию с генерацией версионных деревьев автоматически, на основе наличия модулей в версионных директориях.

Я делал через квери параметр и просто разные сервисы

Но так как нет в несте мультипровайдинга приходилось копипасть многое🤦‍♂

Плохой диай в нест)

@Global() 😎