Пакет semantic-release — это удобный способ автоматизировать части процесса выпуска вашего пакета NPM.

Он может автоматически

Я создал пакет semantic-release-example, чтобы проиллюстрировать, как реализовать пакет semantic-release в существующем пакете NPM.

Важно отметить, что для пакета semantic-release требуется Node 8 или выше.

Начальный пакет

Пакет semantic-release-example пытается максимально имитировать структуру типичного пакета Javascript — в нем есть тесты (ну, тест), даже пара функций (гм, я думаю ровно две), linting, использует babel и создает Travis CI.

Когда я впервые опубликовал semantic-release-example в NPM (до внедрения semantic-release), версия была 1.0.0.

Переход на семантический релиз

Настройка семантического выпуска

  1. Создал новую ветку implement-semantic-release Git
  2. Глобально установлен пакет semantic-release-cli NPM.
  3. Запустите команду semantic-release-cli setup в окне терминала.
  4. Ввел данные аутентификации GitHub и Travis CI как часть инструкций по установке.
  5. После успешного выполнения команды semantic-release-cli setup я заметил, что в моем package.json появилось три новых обновления: поле версии было перезаписано (изменилось с 1.0.0 на 0.0.0-development), в devDependencies был добавлен пакет semantic-release, а также был добавлен скрипт semantic-release. Мой файл .travis.yml был перезаписан, чтобы включить недавно добавленный сценарий semantic-release как часть шага after_success.
  6. Были также обновления для моей среды сборки Travis. Были добавлены две переменные среды, GH_TOKEN и NPM_TOKEN. Это мои личные токены доступа к GitHub и NPM.

Настройка линтинга сообщений фиксации

Важным аспектом semantic-release является то, что он использует формат сообщений фиксации для определения значения следующей версии (при необходимости).

Из коробки, semantic-release следует Соглашению о сообщениях фиксации Angular и применяет следующие семантические правила управления версиями, учитывая формат сообщения фиксации.

// Patch Release
fix(pencil): stop graphite breaking when too much pressure applied
// Minor Release
feat(pencil): add 'graphiteWidth' option
// Major Release
perf(pencil): remove graphiteWidth option

BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons.

Я думаю, важно отметить, что в соответствии с соглашением о сообщениях фиксации Angular любое сообщение фиксации, не соответствующее ни одному из этих четырех форматов, не приведет к обновлению версии NPM.

  1. Для простоты я придерживался соглашения о сообщениях коммитов Angular при реализации линтинга сообщений коммитов.
  2. Решил использовать commitlint, потому что он имеет относительно простой в использовании интерфейс командной строки и простой способ реализации перехватчиков сообщения фиксации Git с использованием husky.
  3. Установил свой новый devDependencies (`npm i -D @commitlint/cli @commitlint/config-angular @commitlint/prompt-cli husky` для ленивых)
  4. Добавлено "commitmsg": “commitlint -e $GIT_PARAMS" к моему scripts в моем файле package.json. husky сопоставляет скрипт commitmsg с commit-msg Git hook.
  5. Добавил "semantic-commit": "commit" к моему scripts. Это вызовет commitlint CLI.
  6. Добавлен файл commitlint.config.js, который настраивает commitlint на использование соглашения о сообщениях коммитов Angular при линтинге, а также при форматировании сообщений коммитов с помощью инструмента CLI (подробнее об этом позже).

Неправильно отформатированный Commit Fail Linting

Полезный интерфейс командной строки для фиксации

Создание PR

  1. Подтолкнул мою ветку implement-semantic-release
  2. Создал пиар
  3. Сборка Travis PR не выполнила успешно команду semantic-release как часть шага after_success, поскольку распознала, что текущая сборка была запущена PR.

Слияние PR и вырезание нового релиза

  1. Слил PR
  2. На этот раз сборка Travis удачно выполнила команду semantic-release, так как распознала, что ветка сборки была master (это ветка выпуска по умолчанию) и что сборка не была запущена PR.
  3. Версия пакета NPM увеличилась до второстепенной версии, поскольку сообщение фиксации было feat(semantic-release): Implementing semantic-release automation.
  4. Тег Git и релиз GitHub созданы

Последние мысли

Опять же, пакет semantic-release-example является очень простым примером — он не реализует настраиваемое соглашение о сообщениях фиксации и даже не запускает сборку разных версий Node в Travis.

При этом я надеюсь, что он все же смог проиллюстрировать некоторые полезные возможности автоматизации semantic-release.