How to publish a Node-API package
How to publish a Node-API version of a package alongside a non-Node-API version
The following steps are illustrated using the package iotivity-node
:
First, publish the non-Node-API version:
- Update the version in
package.json
. Foriotivity-node
, the version becomes 1.2.0-2. - Go through the release checklist (ensure tests/demos/docs are OK).
npm publish
.
- Update the version in
Then, publish the Node-API version:
- Update the version in
package.json
. In the case ofiotivity-node
, the version becomes 1.2.0-3. For versioning, we recommend following the pre-release version scheme as described by semver.org e.g. 1.2.0-napi. - Go through the release checklist (ensure tests/demos/docs are OK).
npm publish --tag n-api
.
- Update the version in
In this example, tagging the release with n-api
has ensured that, although version 1.2.0-3 is later than the non-Node-APl published version (1.2.0-2), it will not be installed if someone chooses to install iotivity-node
by simply running npm install iotivity-node
. This will install the non-Node-APl version by default. The user will have to run npm install iotivity-node@n api
to receive the Node-APlI version. For more information on using tags with npm check out "Using dist-tags".
How to introduce a dependency on a Node-API version of a package
To add the Node-API version of iotivity-node
as a dependency, the package.json
will look like this:
"dependencies": {
"iotivity-node": "n-api"
}
As explained in "Using dist-tags", unlike regular versions, tagged versions cannot be addressed by version ranges such as "^2.0.0"
inside package.json
. The reason for this is that the tag refers to exactly one version. So, if the package maintainer chooses to tag a later version of the package using the same tag, npm update
will receive the later version. This should be acceptable version other than the latest published, the package.json
dependency will have to refer to the exact version like the following:
"dependencies": {
"iotivity-node": "1.2.0-3"
}