Use node-api instead of NAN #6452
Conversation
|
I was a bit afraid that it could cause some drop of performance, but I benchmarked it with quite simple script available in PR and it seems there are no any issues with this(it seems that Node API version is even slightly faster). Result of benchmark.js(see code in PR) on this branch(numbers are in microseconds): On master: In both cases OSRM was built as Full code of benchmark(route from Gdansk to Krakow, i.e. ~600km): Node Version which was used: Hardware: |
399facf to
039768d
Compare
| }, | ||
| "main": "lib/index.js", | ||
| "binary": { | ||
| "napi_versions": [8], |
There was a problem hiding this comment.
Version 8 is the latest and it is compatible with any Node version we currently support:

https://nodejs.org/api/n-api.html#node-api-version-matrix
| "napi_versions": [8], | ||
| "module_name": "node_osrm", | ||
| "module_path": "./lib/binding/", | ||
| "module_path": "./lib/binding_napi_v{napi_build_version}/", |
There was a problem hiding this comment.
node-pre-gyp is designed to support multiple NAPI versions, that's why they require NAPI version to be part of module_path(as I understand it may be needed if you want to use some features from new versions of NAPI, but still provide builds for older Node versions which do not support this new version of NAPI) https://github.com/mapbox/node-pre-gyp#the-napi_versions-array-property
| target_no_warning(node_osrm suggest-destructor-override) | ||
| target_no_warning(node_osrm suggest-override) | ||
|
|
||
| # https://github.com/cjntaylor/node-cmake/issues/53#issuecomment-842357457 |
There was a problem hiding this comment.
We could use https://github.com/cmake-js/cmake-js here which is recommended by Node API docs, but it would require much more refactoring in the way how we build our binaries: they force us to use their own node script to run cmake commands what is not very convenient.
| } | ||
| } | ||
|
|
||
| inline bool IsUnsignedInteger(const Napi::Value &value) |
There was a problem hiding this comment.
Node API doesn't distinguish integers and floats, so I had to add this to be compatible with some input parameter checks we had before.
| run: | | ||
| node --version | ||
| npm run nodejs-tests | ||
| - name: Use Node 18 |
There was a problem hiding this comment.
Paranoia check that resulting binary is compatible with any Node version we currently support. I am going to revisit it and probably try to do it in more elegant and less verbose way(probably we can use nvm instead of GitHub actions in order to switch Node versions)
|
Hi @mjjbell @DennisOSRM |
| CXXCOMPILER: g++-8 | ||
| CXXFLAGS: -Wno-cast-function-type | ||
|
|
||
| - name: conan-macos-x64-release-node-16 |
There was a problem hiding this comment.
This PR allowed to get rid from this extra jobs, but at the same time we can now be compatible with more Node versions.
No red flags from my side. |
Issue
closes #4118
The problem is that with nan we have to rebuild binary for each major node version, e.g. it is one of the reasons why we have no support for Node 18 on Windows(we could add one more job though on CI, but it requires a lot of boilerplate etc). After migration to Node-API our binaries will become "forward compatible", i.e. they will work with any new Node version which support NAPI version it was built with. Besides that node-api(to be precise its C++ wrapper
node-addon-apiwe use here) has less verbose and more readable API rather than NAN.Tasklist
Requirements / Relations
Link any requirements here. Other pull requests this PR is based on?