Публикация модуля NPM, часть 4

Как разработчики, мы должны стремиться автоматизировать как можно больше. Установка значений SemVer — это, безусловно, то, что мы должны сделать. Одна из причин — уменьшить объем памяти для выполнения обычных задач, другая — удалить эмоции из управления версиями. Посмотрите это видео по другим интересным причинам. Это довольно просто настроить.

Сначала давайте установим его глобально.

$ npm install -g semantic-release-cli

Теперь, когда он установлен, мы можем запустить небольшой симпатичный мастер для его настройки. Убедитесь, что вы находитесь в папке вашего модуля:

$ semantic-release-cli setup

Есть несколько подсказок:

Независимо от того, является ли ваш репозиторий GitHub общедоступным или частным.
Какой реестр NPM вы хотите использовать (по умолчанию: http://ift.tt/1bx8DsD)
Ваше имя пользователя NPM (если пароли ранее не были сохранены в связке ключей)
Ваш адрес электронной почты NPM
Ваш пароль NPM
Ваше имя пользователя на GitHub
Ваш пароль GitHub (если пароли ранее не были сохранены в связке ключей)
Какую систему непрерывной интеграции вы хотите использовать. (Варианты: Travis CI/Pro/Enterprise или другое)
Хотите ли вы протестировать одну версию node.js (например, 0.12) или несколько версий node.js (например, 0.10, 0.12 и т. д.)

Введите свою информацию, большинство из них по умолчанию будут правильными, просто убедитесь, что для вопроса CI выбран Travis-CI, а для версии узла выберите один узел.

Посмотрим, что произошло! Глядя на package.json мы видим новый скрипт semantic-release.

"semantic-release": "semantic-release pre && npm publish && semantic-release post"

Также обратите внимание, что раздел version файла package.json исчез. Travis-CI справится с этим сейчас, однако, чтобы подавить предупреждающее сообщение, когда мы выпустим пакет npm, давайте добавим его обратно как:

"version": "0.0.0-semantically-released"

Он также обновляет URL-адрес до https и добавляет semantic-release к зависимостям dev. Давайте немного настроим travis.yml, добавив наш тестовый скрипт в цепочку между before: и after: и добавим:

Script:
        - npm run test

Это обеспечит выполнение наших тестов, когда наш CI попытается их опубликовать.

Чтобы узнать больше, перейдите к ридми модулей здесь.

Быть хорошим приверженцем

Давайте установим commitize, чтобы наши сообщения о коммитах были согласованными, чтобы помочь нашей системе управления версиями быть еще более эмоционально независимой.

В вашем терминале запустите:

$ npm i -D commitizen

Затем нам нужно сообщить ему, какому стандарту следовать для наших сообщений. Я использую довольно стандартный журнал изменений, используемый командой AngularJS, который называется… обычный журнал изменений!

Вы можете прочитать больше об этом здесь".

Чтобы установить его, просто введите:

$ npm i -D cz-conventional-changelog

Если вы достаточно уверены в них, вы можете установить их с параметром -g вместо -D. Если вы это сделаете, потребуется немного больше настроек. Перейдите здесь для получения дополнительной информации.

Это добавляет bin к модулям узлов, которые мы можем использовать в наших сценариях npm, называемых git-cz. Вы можете просто запустить следующее вместо git commit:

$ git cz

Вы можете использовать все параметры git commit с git cz, например:
git cz -a.

Однако мы собираемся настроить скрипт в нашем package.json, чтобы сделать все немного чище и немного более очевидным. Просто добавьте новый скрипт со следующим:

"commit": "git-cz"

Затем нам нужно сообщить ему, чтобы он использовал наш cz-conventional-changelog, в разделе конфигурации (создайте его, если у вас его нет) добавьте:

"config": {
    "commitizen": {
        "path": "node_modules/cz-conventional-changelog"
    }
  },

Давайте инсценируем эти изменения.

$ git status
$ git add -A
$ git status

Прежде чем мы запустим наш новый изящный скрипт, зайдите в свой репозиторий на github и создайте задачу. Для этого давайте сделаем что-то вроде «стандартизовать сообщения фиксации». Это, вероятно, ваша первая проблема, однако, если это не так, обратите внимание на число и используйте его для последней подсказки.

Теперь, когда все настроено, мы можем запустить (по последнему приглашению put закрывается # 1):

$ npm run commit

Автоматический выпуск с помощью Travis-CI

$ git status
$ git push

Посмотрите на репо и обратите внимание на закрытую проблему. Зайти на http://ift.tt/2cmaXK5 заметили проблему? Он застрял на этапе тестирования. Это потому, что у нас есть -w в нашей тестовой команде, поэтому она никогда не закроется. Чтобы исправить это, мы собираемся добавить скрипт в наш package.json:

“test:single”: “mocha src/index.test.js”

Нам также нужно отредактировать .travis.yml и изменить наш вызов запуска npm:

- npm run test:single

Вернитесь на travis-ci.org и отмените сборку.

Давайте попробуем это снова в вашей консоли:

$ git status
$ git add .
$ npm run commit

Теперь посмотрите travis-ci, обратите внимание на изменение номера версии. Посмотрите на выпуск github, посмотрите на npm, посмотрите, как изменение версии распространилось на несколько дистрибутивов. Теперь готовим на газу!

Далее… Автоматизация тестирования и покрытия кода!

Ключ: