На этой странице

Следующие шаги проиллюстрированы на примере пакета iotivity-node:

  • Сначала опубликуйте не-Node-API-версию:
    • Обновите версию в package.json. Для iotivity-node версия становится 1.2.0-2.
    • Пройдите чек-лист релиза (убедитесь, что тесты/демо/документация в порядке)
    • npm publish
  • Затем опубликуйте Node-API-версию:
    • Обновите версию в package.json. В случае iotivity-node версия становится 1.2.0-3. Для версионирования рекомендуем следовать схеме предрелизных версий, как описано на semver.org, например 1.2.0-napi.
    • Пройдите чек-лист релиза (убедитесь, что тесты/демо/документация в порядке)
    • npm publish --tag n-api

В этом примере пометка релиза тегом n-api гарантировала, что, хотя версия 1.2.0-3 новее опубликованной не-Node-API-версии (1.2.0-2), она не будет установлена, если кто-то решит установить iotivity-node, просто выполнив npm install iotivity-node. Это по умолчанию установит не-Node-API-версию. Пользователю придётся выполнить npm install iotivity-node@n-api, чтобы получить Node-API-версию. Больше информации об использовании тегов с npm см. в [«Using dist-tags»][].

Чтобы добавить Node-API-версию iotivity-node как зависимость, package.json будет выглядеть так:

"dependencies": {
  "iotivity-node": "n-api"
}

Как объяснено в [«Using dist-tags»][], в отличие от обычных версий, версии с тегом нельзя адресовать диапазонами версий вроде "^2.0.0" внутри package.json. Причина в том, что тег ссылается ровно на одну версию. Так что, если сопровождающий пакета решит пометить более позднюю версию пакета тем же тегом, npm update получит более позднюю версию. В большинстве случаев это должно быть приемлемо. Если вам нужна версия, отличная от последней опубликованной, зависимость в package.json должна будет ссылаться на точную версию, например так:

"dependencies": {
  "iotivity-node": "1.2.0-3"
}