Архитектура фронтенда
Monorepo: обзор с выбором ответа
Суть Синтез по всему юниту про monorepo в формате выбора: граф зависимостей, affected-детекция, ключи remote cache, границы модулей и трейдофф monorepo против polyrepo.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих через весь юнит. Каждый отражает решение, которое ты принимаешь на реальном CI-пайплайне, — не определение для заучивания, а трейдофф, который надо взвесить, когда очередь на мердж встаёт.
Цель
Убедись, что можешь связать граф зависимостей, affected-детекцию, remote cache и границы модулей в одно решение: собирать изменённое и его зависимых, кэшировать остальное и никогда не давать hub-пакету заставлять каждый PR пересобирать весь мир.
Викторина
Completed
Правка одной строки текста на маркетинговой странице висит в CI 41 минуту; пересобрались все 38 проектов. Импорт резолвился через @acme/utils, от которого зависят все приложения и библиотеки. В чём настоящая причина?
Heads-up Кэш не спасёт hub. Изменение в utils порождает новый хэш входов для каждого зависимого, поэтому каждый зависимый — это законный cache miss. Промах корректен; неверен граф.
Heads-up Раннеры помощнее соберут те же 38 проектов быстрее, но ты всё равно собираешь 38 ради одной строки — платишь размером репозитория, а не размером изменения. 41-минутная задача вернётся с ростом репозитория.
Heads-up Он заметил изменение верно. Единица affected — это проект, и обход зависимых от hub законно достаёт весь репозиторий. Фикс — разбить hub, а не сузить scope.
Викторина
Completed
Что affected (Nx) / filtered (Turborepo) на самом деле вычисляет для PR, ещё до учёта кэша?
Heads-up Это собрать-всё. Affected существует именно чтобы пропускать нетронутые проекты; запуск их всех параллельно всё равно масштабируется размером репозитория, а не изменения.
Heads-up Единица не файл, а проект, и зависимых надо включать: изменение в библиотеке может сломать приложения, которые её импортируют, поэтому их тоже надо перетестировать.
Heads-up Это отдельная работа кэша. Affected решает, какие проекты — кандидаты; кэш затем решает, каких кандидатов можно пропустить, потому что их вывод уже существует.
Викторина
Completed
PR отдал устаревшую сборку из remote cache и выпустил баг, хотя hit rate был высоким. Самая вероятная причина?
Heads-up Вытеснение даёт промах и пересборку, а не отдачу устаревшего артефакта. Устаревшее попадание значит, что хэш совпал, когда не должен был, — отсутствующий вход в ключе.
Heads-up Если affected его пропустил, для проекта вообще ничего не отдавалось. Отданный устаревший артефакт значит, что задача запустилась, проверила кэш, попала и получила неверную запись, — проблема ключа.
Heads-up Высокий hit rate — не баг; баг — неверный ключ. Корректный ключ даёт корректные попадания. Цель — именно высокий hit rate с ключом, который ловит каждый реальный вход.
Викторина
Completed
Почему забытый разработчиком glob во входах задачи приводит к тихому замедлению CI, а не к поломке?
Heads-up Это противоположный сбой. Слишком МАЛО реальных входов даёт false hit (устаревшие артефакты); слишком МНОГО или волатильные входы дают false miss (нет переиспользования). Этот вопрос — про сторону false miss.
Heads-up Глобы входов питают ключ кэша, а не порядок задач. Порядок идёт из графа зависимостей (dependsOn / targetDependencies) и не затрагивается шумным глобом входов.
Heads-up Affected вычисляется из git diff с базой, а не из входов ключа кэша. Волатильный вход бьёт по hit rate, а не по размеру affected-набора.
Викторина
Completed
Команда задаёт Nx-теги так, что feature → ui → util — единственное разрешённое направление. Разработчик добавляет импорт из util-библиотеки в feature-библиотеку, и CI падает на линте. Почему это задуманное поведение, а не трение?
Heads-up Невыставленные границы — это как раз то, как формируется hub @acme/utils. Падение линта дёшево; граф «все зависят от всех» — это та самая 41-минутная задача, с которой начинается юнит.
Heads-up enforce-module-boundaries — про форму графа и радиус взрыва, а не про форматирование. Оно управляет тем, какие проекты могут зависеть от каких, что напрямую задаёт affected-scope и инвалидацию кэша.
Heads-up Тайпчекер резолвит импорт нормально; в этом и проблема. Правило границ ловит архитектурно плохое ребро, которым компилятор доволен, — структурный вопрос, а не ошибка типов.
Викторина
Completed
Команда из четырёх независимых продуктовых отрядов почти не делит код и общается только по HTTP API. Они выбирают между monorepo и polyrepo. Какая формулировка верна?
Heads-up Скорость monorepo идёт из affected-скоупинга и кэширования поверх ОБЩЕГО графа. При почти нулевом общем коде каждый polyrepo и так тривиально быстр и независим; накладные расходы monorepo-инструментов ничего не зарабатывают.
Heads-up Polyrepo меняет проблему CI на проблему координации: любой общий код едет через registry с бампами версий и lockstep-PR. Это верный размен здесь только потому, что они почти ничего не делят.
Heads-up Это про связанность, а не размер. Решающий вопрос — делят ли пакеты код и меняются ли вместе (в пользу monorepo) или они по-настоящему независимы и говорят только по API (в пользу polyrepo).
Итог
Сквозная линия юнита — один пайплайн: граф зависимостей задаёт порядок и радиус взрыва, affected-детекция сужает каждый PR до изменённых проектов плюс их зависимых, remote cache превращает большинство из них в мгновенные попадания — и ключ кэша решает всё, где отсутствующий вход — опасный false hit, а волатильный — расточительный false miss. Ничто из этого не выживает при плохом графе, поэтому выставленные границы модулей (Nx-теги, правило enforce-module-boundaries, package exports) не дают сформироваться hub. А выбор monorepo против polyrepo — про связанность: общий код, меняющийся вместе, — в пользу monorepo; по-настоящему независимые команды — в пользу polyrepo.