Процесс выпуска релиза

Релизы share — это ручная шестиступенчатая цепочка: публикация в npm выполняется локально (этапы проверки запускаются вручную), а метки и релизы на GitHub / Gitee архивируются автоматически средствами CI.

Шесть шагов

1. Записать changeset

pnpm changeset

Интерактивно выбирается уровень изменения (major / minor / patch) и пишется описание изменений; создаётся .changeset/<случайное-имя>.md. Накапливайте до попадания в master — один changeset на одну тему.

Соглашения по уровням:

Уровень	Когда использовать
`major`	разрушающие изменения (переименование, удаление API, изменение поведения). Помечайте серьёзно и на стадии 0.x — downstream по этому признаку решает, нужно ли менять код
`minor`	добавление функциональности (новый компонент, новый preset, новый экспорт)
`patch`	исправление багов, точечная правка стилей

2. Коммит и попадание в master

git add -A
git commit -m "feat: ..."      # сообщение коммита подробно расписывается в markdown
# затем PR или прямое попадание в master

3. Потребить changeset

pnpm changeset:version

Делает три вещи: объединяет все ожидающие релиза changeset’ы в описание изменения версии → меняет номер версии в package.json → пишет CHANGELOG.md и удаляет потреблённые файлы changeset.

Номер версии определяется максимальным уровнем среди всех ожидающих changeset’ов (например, если из 9 changeset’ов максимальный — minor, то 0.3.0 → 0.4.0).

4. Зафиксировать номер версии коммитом

git add -A
git commit -m "chore(release): 0.4.0"

Почему вручную: в .changeset/config.json стоит commit: false, и changeset не делает git commit автоматически. Сообщение коммита на этом шаге по традиции пишется как chore(release): x.y.z + подробное описание содержимого релиза на markdown.

5. Опубликовать в npm и создать локальный тег

pnpm release

Это changeset publish, порядок:

Выполняется prepublishOnly: pnpm build + pnpm verify:dts + pnpm verify:styles
Публикация в npm (npm publish)
Локально создаётся тег @lh-ui/share@x.y.z (только создаётся, не отправляется)

Предусловие: выполнен npm login. Это операция с учётными данными, AI её не выполняет.

Обратите внимание: prepublishOnly выполняет только три проверки — test / lint / typecheck / verify:theme необходимо явно запустить вручную перед релизом (см. полный цикл проверок).

6. Отправка и архивирование

pnpm release:push

Отправляет master + текущий тег в github-lhgb, что автоматически запускает .github/workflows/release.yml.

Автоматическое архивирование в CI (release.yml)

tarball, уже опубликованный в npm
  → создаётся GitHub Release (с вложенным lh-ui-share-<version>.tgz; можно установить офлайн через npm i ./xxx.tgz)
  → тег отправляется в Gitee
  → вызывается API Gitee для создания релиза (в тексте есть ссылка на скачивание GitHub tgz)

Ключевое решение: release.yml ничего не пересобирает — для установки берётся tarball, уже опубликованный в npm, и он побайтово идентичен тому, что получает пользователь при npm i. Сборка и двойная проверка выполняются локально через pnpm release (prepublishOnly) и по одному разу в ci.yml.

Благодаря этому можно и создать поздние исторические релизы, не падая из-за отсутствия pnpm-lock.yaml / сценариев в старых коммитах — просто отправьте недостающий тег в GitHub, и та же цепочка заархивирует его автоматически.

Реакция downstream (красная линия 5)

Жёсткое ограничение на порядок релизов: сначала выходит share, затем следуют UI-библиотеки.

После выхода share 0.4.0:

# репозиторий lh-ui-plus
pnpm up @lh-ui/share@0.4.0
pnpm test          # регрессия

# репозиторий lh-ui-vue2
pnpm up @lh-ui/share@0.4.0
pnpm test          # регрессия

Только после этого pnpm verify:versions снова пройдёт (до релиза диапазоны зависимостей в двух родственных репозиториях остаются ^0.3.0 — это ожидаемо).

Замечания

Локально отправляется только в GitHub (github-lhgb), не отправляйте тег в Gitee вручную — теги / релизы Gitee единолично обслуживаются release.yml, двойная запись приводит к конфликтам.
npm login — ручной шаг: если npm whoami возвращает 401, значит вход не выполнен; сначала войдите, потом pnpm release.
Создание исторических релизов: достаточно git push github-lhgb @lh-ui/share@0.2.0; release.yml идемпотентен (если Release уже существует, только дозаливается tarball). При неудачном создании релиза можно перезапустить его на странице Actions через workflow_dispatch, передав тег.
Релизы Gitee зависят от секрета GITEE_TOKEN (персональный токен доступа Gitee с правом releases), который настраивается в Settings → Secrets репозитория GitHub.
Не правьте исходники в середине релиза: prepublishOnly из pnpm release выполнит сборку заново, и на этот момент рабочая область должна быть чистой.
Историческое наследие 0.3.0: номер версии тогда был включён в один fix-коммит (791ff32) без отдельного коммита chore(release). Начиная с этого релиза соглашение восстанавливается; историю не переписываем.

Развёртывание (в другом репозитории)

Сайт документации разворачивается на семейном nginx; контракт описан в lh-ui/docs/部署/nginx-lhui.conf.md (другой репозиторий): добавляется location ^~ /lhui/share/, а список из восьми сайтов обновляется до девяти. Репозиторий share отвечает лишь за то, чтобы артефакты pnpm docs:build были пригодны к использованию.

Связанные документы

Список команд
Система проверок
Сценарии сборки
Руководство по участию
Как каждая платформа потребляет пакет —— как downstream реагирует на новую версию