Проверка совместимости
Что проверяет CI
В работающем примере TP-Prepare addon имеет обычную dependency на core: установка addon подтягивает core. В CDD связь другая: optional peer у Zustand позволяет использовать ./vanilla без React; React нужен для React-интеграции. Локальная devDependency нужна, чтобы тестировать именно текущий React из монорепы. Каскад версий не должен превращать optional peer в обязательную dependency.
До публикации CI выполняет следующие проверки и на feature PR, и на release PR:
| Проверка | Какую проблему обнаруживает |
|---|---|
| Сборка Bun | Ошибки сборки и отсутствующие выходные файлы |
| Проверка типов | Несовместимые типы и публичные декларации |
| Runtime-интеграция React/Zustand из workspace | Работа хуков, подписок, обновления состояния и повторного рендера |
| Установка собранных tarball в чистый проект | Ошибки exports, состава архива, semver и скрытую зависимость от файлов монорепозитория |
Отдельный сценарий ./vanilla без React | Возможность использовать vanilla API без установки optional peer |
Проверка архивов в чистом проекте
- Подготовить архивы через
bun pm packв каталоге каждого собранного пакета. - В отдельном каталоге вне workspace установить оба локальных архива, чтобы проверка новой связки до публикации не подтянула прежний React из registry.
- Проверить метаданные архивов, импорты и типы.
- Запустить runtime-сценарий: компонент читает store через хук, изменение store обновляет отображение.
- Отдельно проверить vanilla без React.
Release PR должен пройти эти проверки с окончательными версиями и диапазонами.
Успешная сборка не доказывает работу хуков. Если сборка проходит, а runtime сломан, соответствующий интеграционный тест должен остановить выпуск. Автоматическая замена peer-диапазона также не гарантирует совместимость с breaking-версией: это изменение метаданных, которое требует проверки поведения. После обновления библиотек собственные тесты потребителя сохраняются — в них могут быть сценарии, которых нет в монорепозитории.