Монорепозиторий (Monorepo)

Монорепозиторий (monorepo) — это стратегия управления исходным кодом, при которой несколько отдельных, но связанных проектов — фронтенд-приложение, бэкенд-API, общая библиотека компонентов, внутренние инструменты — живут вместе в одном Git-репозитории, вместо того чтобы каждый выделялся в собственный отдельный репозиторий (стратегия «polyrepo» или «multirepo»). Такие компании, как Google, Meta и Vercel, славятся огромными монорепозиториями; в мире SaaS/стартапов распространён паттерн монорепозитория, содержащего фронтенд на Next.js, бэкенд-API и общую директорию `packages/` с кодом, используемым обоими (типы, UI-компоненты, вспомогательные функции). Почему это важно для разработчиков AI/SaaS: монорепозиторий делает межпроектные изменения атомарными — если вы меняете общий тип API, вы обновляете зависящие от него фронтенд и бэкенд в одном и том же коммите, и CI может проверить всё изменение целиком, вместо координации изменения между двумя отдельными репозиториями с отдельными PR и версиями. Он также делает совместное использование кода тривиальным (не нужно публиковать внутренний пакет в приватный реестр только чтобы поделиться вспомогательной функцией между двумя приложениями) и даёт единый источник истины для всей кодовой базы, что особенно полезно для ИИ-агентов кодирования — агент с доступом к монорепозиторию может увидеть и корректно обновить обе стороны фулстек-изменения за один проход, вместо того чтобы держать отдельный контекст и отдельные сессии для репозиториев фронтенда и бэкенда. Компромисс — сложность инструментария: наивная настройка монорепозитория запускает полный набор тестов и полную сборку при каждом изменении, независимо от того, что реально изменилось, что замедляется с ростом масштаба, поэтому монорепозиториям обычно нужны выделенные инструменты оркестрации сборки. Как это работает: инструменты для монорепозиториев вроде Turborepo, Nx или Bazel добавляют две ключевые возможности поверх обычного многопакетного репозитория — запуск задач с учётом графа зависимостей (пересборка/перетестирование только тех пакетов, которые реально затронуты данным изменением, плюс всё, что от них зависит) и удалённое кэширование (если другой разработчик или CI уже собрал данный пакет на этом же самом коммите, переиспользовать результат сборки вместо повторной работы). Практический пример: у команды в монорепозитории есть `apps/web`, `apps/api`, `packages/ui` (общие React-компоненты) и `packages/types` (общие типы TypeScript). Разработчик меняет общий тип `Invoice` в `packages/types`, добавляя новое поле `taxAmount`. Запуск `turbo run build` проходит по графу зависимостей, видит, что `packages/types` изменился, и автоматически пересобирает и перетестирует не только этот пакет, но и всё, что от него зависит ниже по цепочке — `apps/api` (которому теперь нужно заполнять `taxAmount`) и `apps/web` (которому нужно его отображать), — пропуская при этом `packages/ui`, который вообще не зависит от изменённого типа, экономя значительное время CI по сравнению с пересборкой всего репозитория при каждом изменении.