Следующие шаги проиллюстрированы на примере пакета 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"
}