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 becomes1.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 becomes1.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-API 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-API version
by default. The user will have to run npm install iotivity-node@n-api to
receive the Node-API 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"
}