Implement Node-API in bun.js (napi) #158
Comments
|
I made a test repo that exercises a number of things that are currently having problems with the bun napi interface:
You will have uncomment NAPI_MODULE from apw.cpp (and comment NODE_MODULE_INIT) when you want to test that, figured the other things were more important. Hope that helps, thanks for the great work! |
|
I also wanted to check to see if this is roughly the right approach loading a module for napi + ffi usage. I think the hybrid strategy is good: use napi for general purpose stuff like building objects, async work, and use ffi for "hot" functions that need to be fast. Here is an example from my code where I am loading the platform's binary with the napi loading package, and then, if running in bun, loading it through the FFI loader. But, I think this raises a couple points:
Anyway, here is my loading sequence right now: |
For bun you can also do
This is a good point. I don't know either, but worth checking.
This is an oversight – require.resolve should exist but does not currently. There are at least 5 other ways you can resolve without loading modules though:
|
My evidence is that when I set the value of a static C variable from a NAPI call, that value was accessible/correct from an FFI call, so I think working correctly, but I am not claiming this as absolute proof.
Ok, so you plan on adding require.resolve? I think in node-gyp-build it would either need to go through Anyway, thanks for the progress here, I know these are probably annoying details of the napi/node machinery, but I think node-gyp-build is pretty commonly used. |
Support for both of these was added in Bun v0.0.83 (released today) |
|
FYI, I tried to run parcel-css with Bun, but got the following error (logging with Example: const parcelCss = require('./parcel-css.darwin-arm64.node');
parcelCss.transform({
filename: 'test.css',
code: Buffer.from('.foo { color: red }'),
minify: true
}); |
|
If I attempt to load a native module that uses Node-API, I get a crash on missing symbols. Additionally, I don't see any of the Node-API symbols in the bun binary (0.1.1, macOS x86_64). Is there something additional that needs to be done to load these symbols or was this possibly optimized out in the latest release? Edit: It appears to be only the macOS release where they are missing. The symbols are present in linux. |
|
What do you mean by As bluebird uses async_hooks and requires it explicitly like this for example: Which then results into: |
|
async_hooks will need to be polyfilled but initially just disabled so it is
a no-op rather than failure on require()
Also in bun at least, you should try to avoid Bluebird. It’s a many X
slowdown
…On Sun, Jul 10, 2022 at 10:13 AM Laurens Lavaert ***@***.***> wrote:
What do you mean by async_hooks resource tracking will not be supported,
it will just ignore them.
As bluebird uses async_hooks and requires it explicitly like this for
example:
var AsyncResource = util.isNode && util.nodeSupportsAsyncResource ?
require("async_hooks").AsyncResource : null;
Which then results into:
Could not resolve: "async_hooks". Maybe you need to "bun install"?
—
Reply to this email directly, view it on GitHub
<#158 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFNGSZC646YQEGC6NGCNRTVTMAFNANCNFSM5VDV6N3Q>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
What would you say is recommended to use (instead)? Par example, (async () => { for (let i=0; i<800000; i++) { await functionCall(i); } })();...would work, but only one execution at a time. P. S. http://bluebirdjs.com/docs/benchmarks.html claims to be faster (in node) than async-await. |
|
PrismaJS also requires async_hook |
|
Hey folks! Is there any progress on |
Added in dddbce8 |
|
When running @parcel/watcher, even just trying to import it with |
Yes, there are at least three issues blocking |
|
Looks like https://github.com/cztomsik/zig-napigen/tree/main/example
|
|
@Jarred-Sumner Either I did something wrong or did not help :-/
|
|
Sorry, please try again after 4be3548 This time it should work |
|
Hey guys! Any plans to support gdb outputlldb output |
|
Any updates on this? |
|
|
|
i got the error at uWS.js also TypeError: symbol 'napi_register_module_v1' not found in native module. Is this a Node API (napi) module? |
|
@TomieAi |
hmm i know but i just wanna say uws dint work at bun sadly. throwing me error about "napi_register_module_v1" then i google about it XD and it leads me here. |
|
@TomieAi That issue would need to be filed with uWebSockets.js. This isn't an issue with |
|
For anyone experiencing NAPI issues with |
|
My issue regarding |
|
Hey, Excuse me ignorance but I am working with OpenCV, I see that the NAPI Register module is indeed complete but at the same time I am running into an issue with @u4/opencv4nodejs where by I run into a node API error: As mentioned by @kjvalencik, I will also ask |
|
@ArthurTimofey that addon looks like it's built with NAN and not Node-API. It won't be portable. |
|
One thing I've noticed is that Node can handle null if (napi_get_reference_value(env, md->js_env, &js_env) == napi_ok
&& napi_get_boolean(env, true, &released) == napi_ok) {
napi_set_named_property(env, js_env, "released", released);
}
|
|
It seems that |
+1 trying to run tree-sitter binding for node get: |
|
Hey everyone! I've been following this issue for over a year and am very excited to see progress. Is it possible to slightly extend the list? NAPI doesn't provide a single good interface to inspect the contents of strings and other buffers without copying them, which makes writing high-performance native extensions for binary data a complete nightmare. I was stuck with this while working on StringZilla JS bindings and can't afford to copy a string if the operation in question is something like substring search, fuzzy matching, hashing, or something else lightweight. Assuming Bun's focus on performance and development velocity, I felt it's wiser to propose such extensions here rather than to NAPI directly. I'm happy to open a separate issue if it makes sense 🤗 Thanks to everyone involved! |
and others
Node-API is Node.js' native addon API. The goal of this project is for many Node-API addons in bun.js to just work, without asking maintainers of node modules to make changes or rebuild their code specifically for Bun.
The first version will be scoped specifically to the
napi_*functions. It will not include support foruv_*functions or the V8 C++ functions. A good initial target is napi.rs support.Internal changes
.nodefilesprocess.dlopensupport for native modulesrequiresupport for native modulesAPI implementation
JSC::VM::lastException())Test coverage
The tentative plan is to rely on napi.rs tests, but haven't checked yet if that's possible.
The text was updated successfully, but these errors were encountered: