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

Обычный сценарий: один репозиторий = один пакет/сервис.
Сложный сценарий: десятки мелких реп, которые зависят друг от друга и требуют синхронизации.

Монорепа — это один репозиторий, много пакетов и сервисов, единые правила для зависимостей и релизов.

Когда монорепа уместна

- общий стек и общие зависимости
- нужен единый стандарт качества и релизов
- есть связность между пакетами/сервисами
- хочется упростить локальную разработку и интеграцию
- релизы «цепочкой» — норма, а не исключение

Когда монорепа НЕ нужна

- проект маленький и автономный
- релизы независимы и редки
- разный стек, разные команды, разные процессы
- есть жёсткие ограничения по доступам
- нет ресурсов поддерживать дисциплину CI/CD

Подводные камни

1. Линковка пакетов
Без нормальной схемы линковки легко получить «работает только у меня».

2. Установка зависимостей
Чем больше пакетов, тем больше хаоса в node_modules.
Нужны единые версии, lockfile‑политики и дедупликация.

3. Версионирование

- _Fixed_ (все пакеты одной версии) — проще, но тяжелее для частых релизов.
- _Independent_ — гибче, но требует строгих правил и автоматики.

4. CI/CD
Сборка всего на каждый чих = боль.
Нужны инкрементальные сборки, кэширование и селективный запуск — только затронутые пакеты.

5. Границы
Монорепа не должна превращаться в безразмерную свалку.
Нужны чёткие зоны ответственности и правила владения.

Шпаргалка: «как прижечь шею»

1) Определись с правилами:

- единый стиль и линтер;
- единый lockfile;
- единая политика версий.

2) Определи структуру:

- packages/* для пакетов;
- apps/* или services/* для сервисов;
- общий tools/ или scripts/.

3) Настрой релизы:

- changelog‑генерация
- автоматическая публикация
- согласованные теги и правила

4) Ускорь CI:

- кэш зависимостей;
- запуск только затронутых пакетов;
- параллельные задачи.

Личный опыт.

Работал в команде общих компонентов — занимался версионированием и автопубликацией монорепы.

Система контроля версий у нас была не git, поэтому open-source инструменты (все завязаны на git) не подходили. Пришлось писать своё. Здесь пригодилась теория графов: пакеты — узлы, зависимости — рёбра. Чтобы при независимом версионировании не выставить кому-то лишнюю версию, нужна топологическая сортировка.

Для версионирования использовали conventional commits: разработчик прямо в коммите указывает тип изменения (patch/minor/major), дальше автоматика. Просто и предсказуемо.

Если есть вопросы про организацию монорепы — пишите в комментарии.

Выводы

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

Если хочется больше погружения:
- Гайд от создателей Nx (сами участвуют в сравнении, но материал полезный): https://monorepo.tools/
- Хороший доклад про монорепу от Вовы Гриненко: https://youtu.be/okN-o7BseSg?si=oOIY0qAHuyJIWqfZ
- Conventional commits: https://www.conventionalcommits.org/en/v1.0.0/