Если после каждого «небольшого» рефакторинга сборка падает не у вас, а у коллеги — у вашей команды не монорепо, а полирепо с ручной синхронизацией.

Кажется, что это мелочь: обновил зависимости здесь — забыл там, поднял версию внутреннего пакета — не поднял в другом приложении. Но цена координации растёт не линейно: с каждым новым пакетом ревью превращается в сверку версий, CI собирает всё целиком, потому что никому не ясно, что реально затронуто, а «зелёный» пайплайн на машине разработчика перестаёт совпадать с пайплайном в основном ветке. Через пару месяцев команда начинает бояться трогать общие пакеты: фичи копятся в длинных ветках, мержи становятся конфликтными, а онбординг нового разработчика занимает неделю вместо дня. Дальше — хуже: зависимость от того, кто последний трогал пакет, выделенный интегратор вместо код-ревью и необъяснимые баги в проде, которые никто не может повторить локально.

Разбираю, как это чинится, в канале: какие границы пакетов действительно держат, как настроить affected CI, чтобы собиралось только затронутое, и почему версионирование внутренних пакетов важнее выбора между Nx и Turborepo. Ответа в этом посте не будет — следите за публикациями 👇

Подписывайтесь, чтобы не пропустить разбор. Полный курс «Monorepos для мобильных команд»: import-from-course.ru/courses/monorepos-for-mobile