Comments 6
Без явного графа зависимостей CI запускает всё, не понимает, что реально изменилось и тратит 90% времени впустую
Это шутка какая-то? Берём nx и читаем документацию: https://nx.dev/docs/features/ci-features/affected
Раз в статье пример про Turbo, то и там есть такое же: https://turborepo.dev/docs/reference/run#--affected
Напиши сама чё думаешь, зачем нужен этот нейрослоп?
Тут по ощущению... монорепо нужно в начале проекта, когда стабильности еще мало... так быстрее либы или модули перестраивать, если что то пошло не так... И если людей не хватает, да даже если есть, чтобы не толкались... но по мере роста проекта его структура стабилизируется.. и либы превращаются в прототипы отдельных микросервисов-проектов, которые лучше растаскивать и подключать новых разработчиков.
Монорепа - норм. Но надо на берегу договориться что где и как будет лежать, версионироваться и тд. Иначе - не норм
Монорепо должно быть логичным продолжением грамотной архитектуры которая была заложена ещё в самом начале, еси изначально у вас там каша типа "все зависит от всего" то это не потому что нет монорепо или бизнес торопил, а обычная безответственность разработчика который стоял в истоках. Конечно, на стадии прототипа не стоит заниматься оверинжинирингом когда ещё нет какой то конкретной формы у продукта, но это не значит что нужно забить болт на элементарные базовые принципы проектирования которые известны уже давно.
Монорепозиторий — это не про скорость. И не про хайп. Это инструмент управления сложностью. И если вы готовы зафиксировать границы, описать зависимости и инвестировать в CI - он станет точкой роста. Если нет, то он просто сделает хаос очевидным.
Именно, но опять так и границы нужно зафиксировать в самом начале
Монорепозиторий — стрем или норм?