Как можно ограничить или контролировать изменение версий общих пакетов в монорепозитории с несколькими командами?

Проблема управления версиями в монорепозитории

В монорепозитории несколько команд работают над общими пакетами. Без контроля версий изменение, сделанное одной командой, может сломать код другой. Основная задача — обеспечить обратную совместимость и предсказуемость обновлений.

Основные подходы

• Семантическое версионирование (SemVer): Каждый пакет имеет версию MAJOR.MINOR.PATCH. Breaking changes требуют увеличения MAJOR версии, что сигнализирует другим командам о необходимости адаптации.
• Инструменты монорепозитория: Lerna, Nx, Turborepo или Changesets автоматически вычисляют изменения и предлагают версии. Changesets, например, позволяет разработчику описать изменение, а затем бот генерирует changelog и обновляет версии.
• CI/CD проверки: В пайплайне можно добавить шаг, который проверяет, что изменения в общем пакете не нарушают контракты (например, тесты зависимых проектов).

Пример с Changesets

// .changeset/config.json
{
  "$schema": "https://unpkg.com/@changesets/config@2.3.0/schema.json",
  "changelog": "@changesets/cli/changelog",
  "commit": false,
  "fixed": [],
  "linked": [],
  "access": "public",
  "baseBranch": "main",
  "updateInternalDependencies": "patch",
  "ignore": []
}

// Команда для создания changeset
npx changeset
// Выбираем тип изменения: major, minor, patch
// Описываем изменение
// После PR бот автоматически обновит версии

Практические рекомендации

• Договоритесь о политике: например, все изменения в общих пакетах проходят код-ревью от представителей всех команд.
• Используйте feature flags для постепенного внедрения breaking changes.
• Автоматизируйте генерацию changelog и уведомления о новых версиях.

Вывод: Контроль версий в монорепозитории строится на комбинации SemVer, инструментов автоматизации и командных соглашений. Это позволяет избежать хаоса и сохранить стабильность при параллельной разработке.