В настоящее время реестр npm имеет наибольшее количество пакетов / модулей по сравнению с любым другим реестром пакетов для других языков (Source). Это также самый быстрорастущий реестр с более чем 500 новыми пакетами в день (и это только общедоступные пакеты).

Так как же можно внести свой вклад в этот растущий список пакетов? На самом деле это довольно просто ... просто разработайте что-нибудь и запустите npm publish. Ой, подождите ... при аутентификации произошла ошибка. Просто запустите npm login, введите свои учетные данные и снова запустите команду. Получится (скорее всего).

Но правильно ли это делать? Как можно управлять учетными данными npm? Можно ли сделать процесс управления версиями более плавным? И разве не было бы хорошо создать журнал изменений? И, конечно же, перед публикацией пакета было бы здорово, если бы тесты были запущены на всякий случай.

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

Предпосылки

  1. Прежде всего, должна присутствовать среда CI. Доступно множество бесплатных платформ CI, например. TravisCI. Вот где будет запускаться сборка / тесты / публикация.
  2. Во-вторых, у вас должна быть учетная запись npm, через которую вы будете публиковать пакет.

Понимание файла Package.json

Package.json - это точка входа / манифест для каждого пакета. Узел и npm могут понимать только файл json пакета. Пакет json должен содержать всю информацию о пакете. Некоторые из соответствующих свойств, которые необходимо настроить:

  1. имя: имя, под которым следует опубликовать пакет. Вы также можете установить масштаб своего пакета. Для получения дополнительной информации: https://docs.npmjs.com/files/package.json#name
  2. main: это основная точка входа в ваш пакет. Https://docs.npmjs.com/files/package.json#main
  3. файлы: сюда входит список файлов / каталогов, которые будут включены в пакет npm. Обычно это каталог сборки. Https://docs.npmjs.com/files/package.json#files
  4. «репозиторий»: содержит информацию о репозитории, в котором хранится исходный код.
  5. версия: это номер версии, под которой будет опубликован пакет. Https://docs.npmjs.com/files/package.json#version

Для публикации обязательны только поля «имя» и «версия». Остальные поля представляют собой дополнительную информацию, и их полезно иметь.

Публикация вашего пакета

Команда для публикации - npm publish, но мы не будем ее использовать. Вместо этого мы будем использовать другой пакет, который поможет нам публиковать и делать многое другое. Я говорю о пакете semantic-release. Это полностью автоматизированный инструмент управления версиями и публикации пакетов (по их собственным словам), и я убедился, что это правда. Пакеты NPM следуют семантическому управлению версиями. Версия, по которой публикуется пакет, определяется в файле package.json. Пакет semantic-release предоставляет механизм, с помощью которого можно определить тип выпуска (MAJOR, MINOR или PATCH), увеличить версию в package.json и опубликовать пакет.

Но для того, чтобы он работал эффективно, вам необходимо правильно его настроить и соблюдать дисциплину во время разработки. Для конфигурации вы можете иметь файл .releaserc, release.config.js файл или свойство release в файле package.json. Вот образец свойства выпуска:

Я использовал плагины для выполнения задач:

  1. @ semantic-release / commit-analyzer: этот плагин анализирует сообщения о фиксации из последнего выпуска и текущих изменений, чтобы определить текущий тип выпуска (основной, второстепенный или патч). По умолчанию плагин использует соглашение angular. Я использовал соглашение eslint для создания релизов.
  2. @ semantic-release / release-notes-generator: генерирует примечания к выпуску.
  3. @ semantic-release / npm: обновляет версию в файле json пакета и публикует пакет в npm.
  4. @ semantic-release / git: этот плагин выполняет несколько функций. Во-первых, он генерирует новый тег git для выпуска. Он фиксирует файлы, упомянутые в активах, с пользовательским сообщением, а затем отправляет фиксацию и тег в репозиторий git, упомянутый в файле package.json.
  5. @ semantic-release / changelog: этот плагин создает файл журнала изменений с примечаниями к выпуску.

Плагины семантического выпуска очень похожи на сборочную линию. Каждый плагин выполняет свою работу и подготавливает файлы для других плагинов.

Итак, после настройки семантического выпуска все, что вам нужно сделать, это просто запустить npx semantic-release. Он сделает всю работу, и все, что вам нужно сделать, это просто сесть и расслабиться.

Но подождите, еще не хватает одного важного момента: как вы можете публиковать в npm или нажимать на git без аутентификации? Вы просто не можете запустить команду npm login в конвейере CI как интерактивную команду (попробуйте запустить ее на своем локальном компьютере). Вам нужно сгенерировать токен из npm и добавить его в среду CI в качестве переменной среды. Для git вам нужно сгенерировать токен и добавить его как GH_TOKEN. Эти методы также описаны в документации соответствующих плагинов.

Осторожно: semantic-release довольно умен. Если вы попытаетесь запустить его локально для тестирования, он будет работать только в том случае, если текущая ветвь является главной, и будет работать в режиме пробного запуска, поскольку не обнаружит среду CI. Семантический выпуск автоматически определяет, работает ли он в среде CI или на вашем локальном компьютере. В режиме пробного запуска он будет генерировать примечания к выпуску, получать обновленный номер версии, но выводить все на консоль вместо того, чтобы вносить изменения в файлы и git. Вы, конечно, можете настроить его для работы в ветвях, отличных от master.

В конвейере CI вы также можете добавить конфигурацию для запуска сборки и тестирования перед запуском semantic-release. Или, если вы действительно впечатлены семантическим выпуском и хотите, чтобы все происходило через него, вы можете использовать @semantic-release/exec плагин для запуска пользовательских команд перед публикацией.

Вам нужно будет убедиться в том, что коммиты, которые вы делаете, должны соответствовать стандарту (независимо от стандарта, с которым вы используете анализатор коммитов). В противном случае автоматическое управление версиями не сработает, и, следовательно, дальнейшие конвейеры также не будут работать. Один из способов добиться этого - использовать ловушку git, чтобы проверить, следует ли сообщение фиксации определенному шаблону. Я лично обнаружил, что схема управления версиями eslint была довольно лаконичной и хорошо работала для меня.

Я обнаружил, что husky с commitlint - очень эффективная комбинация для настройки этой проверки. Husky может настраивать множество githooks. Вы можете настроить commit-msg githook для выполнения команды commitlint. В вашем package.json

"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

Но commitlint не поддерживает конфигурацию схемы управления версиями eslint. Таким образом, вам нужно убедиться, что ваша схема управления версиями и схема принудительного применения шаблона сообщения фиксации должны быть согласованы. Пример commitlint.config.js для принудительного управления версиями eslint

module.exports = {
    extends: ['@commitlint/config-conventional'],
    rules: {
        "type-case": [0, "always", "start-case" ],
        "type-enum": [2, "always", ["Fix", "Chore", "New", "Docs", "Breaking", "Upgrade", "Update", "Build"]],
        "subject-case": [0, "always", "start-case"]
    }
}

Уф! Поначалу это выглядит как слишком большая конфигурация. Но поверьте, после этого сотни минут будут сэкономлены в будущем.

Удачной публикации!