Cringe Driven Development
Загрузка статьи…

Трек Вынос фронтовых библиотек в монорепу и автопубликация в npm через release-please · Модуль №2

← Обзор трека

Проверка выпуска и восстановление ​

Как проверить результат и восстановить выпуск ​

СценарийReactZustandOpenAPI
После bootstrap1.2.01.0.00.2.0
После описанного React-fix1.2.11.0.10.2.0

Это ожидаемый результат будущего сценария, не обещание наличия пакетов в npm сейчас.

  1. Проверяем registry, а не только GitHub Releases:

    sh
    npm view @cdd-team/react version
npm view @cdd-team/zustand version
npm view @cdd-team/openapi version
npm view @cdd-team/zustand@1.0.1 peerDependencies --json

  2. Устанавливаем второй выпуск в новом каталоге вне монорепозитория:

    sh
    mkdir cdd-libs-consumer
cd cdd-libs-consumer
bun init -y
bun add @cdd-team/react@1.2.1 @cdd-team/zustand@1.0.1

  3. Добавляем в этот чистый проект интеграционный тест компонента и store из раздела о совместимости и запускаем его через bun test; отдельно проверяем типы и сборку потребителя. Установка сама по себе не проверяет хуки.

  4. Для vanilla повторяем проверку в другом чистом проекте, устанавливая только Zustand и импортируя @cdd-team/zustand/vanilla без React.

Если публикация завершилась частично ​

Если React опубликован, а публикация Zustand упала:

  1. Сверяем логи publish job, теги и точные версии в registry:

    sh
    npm view @cdd-team/react@1.2.1 version
npm view @cdd-team/zustand@1.0.1 version

  2. Учитываем задержку доступности npm-метаданных: повторяем чтение после паузы, сопоставляем его с успешным ответом публикации. Один временный ответ «не найдено» ещё не повод немедленно повторять загрузку.

  3. Уже существующую пару name/version не перезаписываем. Исправляем причину сбоя (например, Trusted Publisher Zustand) и завершаем только отсутствующую публикацию из того же проверенного релизного коммита. Список восстановления содержит только отсутствующий путь; слепой повтор job с обоими путями упрётся в существующий React.

  4. Повторяем npm view и установку связки в чистый проект. Если исправление требует менять содержимое уже опубликованного пакета, готовим новую версию через обычный релиз, а не пытаемся заменить архив под прежней версией.