[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-monorepo::ru":3,"gloss-cluster-monorepo::ru":20,"gloss-next-monorepo::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"monorepo","dev-tools","Монорепозиторий (Monorepo)","Монорепозиторий (monorepo) — это стратегия управления исходным кодом, при которой несколько отдельных, но связанных проектов — фронтенд-приложение, бэкенд-API, общая библиотека компонентов, внутренние инструменты — живут вместе в одном Git-репозитории, вместо того чтобы каждый выделялся в собственный отдельный репозиторий (стратегия «polyrepo» или «multirepo»). Такие компании, как Google, Meta и Vercel, славятся огромными монорепозиториями; в мире SaaS\u002Fстартапов распространён паттерн монорепозитория, содержащего фронтенд на Next.js, бэкенд-API и общую директорию `packages\u002F` с кодом, используемым обоими (типы, UI-компоненты, вспомогательные функции). Почему это важно для разработчиков AI\u002FSaaS: монорепозиторий делает межпроектные изменения атомарными — если вы меняете общий тип API, вы обновляете зависящие от него фронтенд и бэкенд в одном и том же коммите, и CI может проверить всё изменение целиком, вместо координации изменения между двумя отдельными репозиториями с отдельными PR и версиями. Он также делает совместное использование кода тривиальным (не нужно публиковать внутренний пакет в приватный реестр только чтобы поделиться вспомогательной функцией между двумя приложениями) и даёт единый источник истины для всей кодовой базы, что особенно полезно для ИИ-агентов кодирования — агент с доступом к монорепозиторию может увидеть и корректно обновить обе стороны фулстек-изменения за один проход, вместо того чтобы держать отдельный контекст и отдельные сессии для репозиториев фронтенда и бэкенда. Компромисс — сложность инструментария: наивная настройка монорепозитория запускает полный набор тестов и полную сборку при каждом изменении, независимо от того, что реально изменилось, что замедляется с ростом масштаба, поэтому монорепозиториям обычно нужны выделенные инструменты оркестрации сборки. Как это работает: инструменты для монорепозиториев вроде Turborepo, Nx или Bazel добавляют две ключевые возможности поверх обычного многопакетного репозитория — запуск задач с учётом графа зависимостей (пересборка\u002Fперетестирование только тех пакетов, которые реально затронуты данным изменением, плюс всё, что от них зависит) и удалённое кэширование (если другой разработчик или CI уже собрал данный пакет на этом же самом коммите, переиспользовать результат сборки вместо повторной работы). Практический пример: у команды в монорепозитории есть `apps\u002Fweb`, `apps\u002Fapi`, `packages\u002Fui` (общие React-компоненты) и `packages\u002Ftypes` (общие типы TypeScript). Разработчик меняет общий тип `Invoice` в `packages\u002Ftypes`, добавляя новое поле `taxAmount`. Запуск `turbo run build` проходит по графу зависимостей, видит, что `packages\u002Ftypes` изменился, и автоматически пересобирает и перетестирует не только этот пакет, но и всё, что от него зависит ниже по цепочке — `apps\u002Fapi` (которому теперь нужно заполнять `taxAmount`) и `apps\u002Fweb` (которому нужно его отображать), — пропуская при этом `packages\u002Fui`, который вообще не зависит от изменённого типа, экономя значительное время CI по сравнению с пересборкой всего репозитория при каждом изменении.","Монорепозиторий хранит несколько отдельных проектов или сервисов в одном репозитории с контролем версий вместо разделения на отдельные репозитории.",null,[11,14,17],{"slug":12,"name":13},"ci-cd","Непрерывная интеграция \u002F непрерывное развёртывание (CI\u002FCD)",{"slug":15,"name":16},"git","Git",{"slug":18,"name":19},"package-manager","Менеджер пакетов (Package Manager)",[21,25,28,32,35,38,41,44,47,48,51,54],{"slug":22,"category":5,"name":23,"updated_at":24},"agent","Агент (Agent)","2026-08-24T02:46:36+00:00",{"slug":26,"category":5,"name":27,"updated_at":24},"ai-code-assistant","AI-помощник по написанию кода",{"slug":29,"category":5,"name":30,"updated_at":31},"api-gateway","API-шлюз (API Gateway)","2026-08-24T02:46:37+00:00",{"slug":33,"category":5,"name":34,"updated_at":31},"api-versioning","API Versioning (версионирование API)",{"slug":36,"category":5,"name":37,"updated_at":24},"autonomous-agent","Автономный агент (Autonomous Agent)",{"slug":39,"category":5,"name":40,"updated_at":31},"blue-green-deployment","Blue-Green Deployment (сине-зелёное развёртывание)",{"slug":42,"category":5,"name":43,"updated_at":31},"canary-deployment","Canary Deployment (канареечное развёртывание)",{"slug":45,"category":5,"name":46,"updated_at":31},"chaos-engineering","Chaos Engineering (хаос-инжиниринг)",{"slug":12,"category":5,"name":13,"updated_at":24},{"slug":49,"category":5,"name":50,"updated_at":31},"circuit-breaker","Предохранитель (Circuit Breaker)",{"slug":52,"category":5,"name":53,"updated_at":31},"cli","Интерфейс командной строки (CLI)",{"slug":55,"category":5,"name":56,"updated_at":31},"cloud-development-environment","Облачная среда разработки (CDE)"]