-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
"module_name": "node_osrm", | ||
"module_path": "./lib/binding/", | ||
"module_path": "./lib/binding_napi_v{napi_build_version}/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -21,6 +25,14 @@ set_target_properties(node_osrm PROPERTIES CXX_CLANG_TIDY "") | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
npm run nodejs-tests | ||
- name: Use Node 18 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
@@ -264,83 +264,7 @@ jobs: | |||
CXXCOMPILER: g++-8 | |||
CXXFLAGS: -Wno-cast-function-type | |||
|
|||
- name: conan-macos-x64-release-node-16 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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-api
we 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?