этого момента мне казалось, что это идеальная структура, но сейчас возник момент, что в одних фичах захотели использовать компоненты из других фичей. Ну и пришла гениальная идея повыносить эти компоненты в :modules:components
У нас покомпонентый подход с щепоткой клина
Явно кто-то сталкивался с таким, что одни фичи начинают использовать другие, интересно, как разрешили эту проблему
p.s Я в своем пет-проекте так и сделал, но в продовом немного страшно
:modules :my-awesome-feature :cool-api-client :very-useful-utils
Ну да, вот у нас примерное так, токлько :cool-api-client и :very-useful-utils вынесены в :modules:services, чтобы отделять такое от фичей Спасибо
Ну вот для наглядности если что как в микро-пете у меня
Есть несколько возможных вариантов. Подробнее в этих статьях https://habr.com/ru/companies/cian/articles/670468/ https://habr.com/ru/companies/cian/articles/667776/
из за этого я использую другой подход)
Другой подход это замечательно, но какой?
мы проблему "одни фичи используют другие" решили тем, что не считаем это проблемой) Пусть используют, жалко, что ли.
Если не выделять какое-то апи фич, то может ломаться инкрементальная компиляция модулей https://www.youtube.com/watch?v=fVp3dnpMYzs
в большом масштабе и с длинным критическим путём компиляции этому надо уделять отдельное внимание, да
Мне просто страшно что однажды может случиться рекурсия между двумя фичами и гредл скажет что не хочет собираться
По-моему это не рекурсия, а циклическая зависимость)
Я только проснулся извините 🫣
Можно в этом случае и разрулить будет) На масштабе 500к+ LOC наверное ограничения на явное API модулей имеют смысл, как в статье циана
Обсуждают сегодня