Skip to content

Commit 46ae677

Browse files
aruneshchandragibfahn
authored andcommitted
doc: how to publish N-API package (#1236)
1 parent 75ba429 commit 46ae677

File tree

1 file changed

+53
-0
lines changed

1 file changed

+53
-0
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
## To publish N-API version of a package alongside a non-N-API version
2+
3+
The following steps are illustrated using the package `iotivity-node`:
4+
- First, publish the non-N-API version:
5+
- Update the version in `package.json`. For `iotivity-node`, the version
6+
becomes `1.2.0-2`.
7+
- Go through the release checklist (ensure tests/demos/docs are OK)
8+
- `npm publish`
9+
- Then, publish the N-API version:
10+
- Update the version in `package.json`. In the case of `iotivity-node`,
11+
the version becomes `1.2.0-3`. For versioning, we recommend following
12+
the pre-release version scheme as described by
13+
[semver.org](http://semver.org/#spec-item-9) e.g. `1.2.0-napi`.
14+
- Go through the release checklist (ensure tests/demos/docs are OK)
15+
- `npm publish --tag n-api`
16+
17+
In this example, tagging the release with `n-api` has ensured that, although
18+
version 1.2.0-3 is later than the non-N-API published version (1.2.0-2), it
19+
will not be installed if someone chooses to install `iotivity-node` by simply
20+
running `npm install iotivity-node`. This will install the non-N-API version
21+
by default. The user will have to run `npm install iotivity-node@n-api` to
22+
receive the N-API version. For more information on using tags with npm check
23+
out ["Using dist-tags"][].
24+
25+
## To introduce a dependency on an N-API version of a package
26+
27+
To add the N-API version of `iotivity-node` as a dependency, the `package.json`
28+
will look like this:
29+
30+
```JSON
31+
"dependencies": {
32+
"iotivity-node": "n-api"
33+
}
34+
```
35+
36+
**Note:** As explained in
37+
["Using dist-tags"][], unlike regular versions, tagged versions cannot be
38+
addressed by version ranges such as `"^2.0.0"` inside `package.json`. The
39+
reason for this is that the tag refers to exactly one version. So, if the
40+
package maintainer chooses to tag a later version of the package using the
41+
same tag, `npm update` will receive the later version. This should be acceptable
42+
given the currently experimental nature of N-API. To depend on an N-API-enabled
43+
version other than the latest published, the `package.json` dependency will
44+
have to refer to the exact version like the following:
45+
46+
```JSON
47+
"dependencies": {
48+
"iotivity-node": "1.2.0-3"
49+
}
50+
```
51+
52+
53+
["Using dist-tags"]: https://docs.npmjs.com/getting-started/using-tags

0 commit comments

Comments
 (0)