|
|
@@ -2,7 +2,7 @@
|
|
|
|
|
|
|
|
|
|
|
|
-> Template project for writing node package with napi-rs.
|
|
|
+> Template project for writing node packages with napi-rs.
|
|
|
|
|
|
# Usage
|
|
|
|
|
|
@@ -49,23 +49,23 @@ With [ava](https://github.com/avajs/ava), run `yarn test/npm run test` to testin
|
|
|
|
|
|
### CI
|
|
|
|
|
|
-With GitHub actions, every commits and pull request will be built and tested automatically in [`node@14`, `node@16`, `@node18`] x [`macOS`, `Linux`, `Windows`] matrix. You will never be afraid of the native addon broken in these platforms.
|
|
|
+With GitHub Actions, each commit and pull request will be built and tested automatically in [`node@14`, `node@16`, `@node18`] x [`macOS`, `Linux`, `Windows`] matrix. You will never be afraid of the native addon broken in these platforms.
|
|
|
|
|
|
### Release
|
|
|
|
|
|
-Release native package is very difficult in old days. Native packages may ask developers who use its to install `build toolchain` like `gcc/llvm` , `node-gyp` or something more.
|
|
|
+Release native package is very difficult in old days. Native packages may ask developers who use it to install `build toolchain` like `gcc/llvm`, `node-gyp` or something more.
|
|
|
|
|
|
-With `GitHub actions`, we can easily prebuild `binary` for major platforms. And with `N-API`, we should never afraid of **ABI Compatible**.
|
|
|
+With `GitHub actions`, we can easily prebuild a `binary` for major platforms. And with `N-API`, we should never be afraid of **ABI Compatible**.
|
|
|
|
|
|
-The other problem is how to deliver prebuild `binary` to users. Download it in `postinstall` script is a common way which most packages do it right now. The problem of this solution is it introduced many other packages to download binary which has not been used by `runtime codes`. The other problem is some user may not easily download the binary from `GitHub/CDN` if they are behind private network (But in most case, they have a private NPM mirror).
|
|
|
+The other problem is how to deliver prebuild `binary` to users. Downloading it in `postinstall` script is a common way that most packages do it right now. The problem with this solution is it introduced many other packages to download binary that has not been used by `runtime codes`. The other problem is some users may not easily download the binary from `GitHub/CDN` if they are behind a private network (But in most cases, they have a private NPM mirror).
|
|
|
|
|
|
-In this package we choose a better way to solve this problem. We release different `npm packages` for different platform. And add it to `optionalDependencies` before release the `Major` package to npm.
|
|
|
+In this package, we choose a better way to solve this problem. We release different `npm packages` for different platforms. And add it to `optionalDependencies` before releasing the `Major` package to npm.
|
|
|
|
|
|
`NPM` will choose which native package should download from `registry` automatically. You can see [npm](./npm) dir for details. And you can also run `yarn add @napi-rs/package-template` to see how it works.
|
|
|
|
|
|
## Develop requirements
|
|
|
|
|
|
-- Install latest `Rust`
|
|
|
+- Install the latest `Rust`
|
|
|
- Install `Node.js@10+` which fully supported `Node-API`
|
|
|
- Install `yarn@1.x`
|
|
|
|
|
|
@@ -90,11 +90,11 @@ $ ava --verbose
|
|
|
|
|
|
## Release package
|
|
|
|
|
|
-Ensure you have set you **NPM_TOKEN** in `GitHub` project setting.
|
|
|
+Ensure you have set your **NPM_TOKEN** in the `GitHub` project setting.
|
|
|
|
|
|
In `Settings -> Secrets`, add **NPM_TOKEN** into it.
|
|
|
|
|
|
-When you want release package:
|
|
|
+When you want to release the package:
|
|
|
|
|
|
```
|
|
|
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | from-git]
|
tristan