napi-rs / napi-rs Goto Github PK

View Code? Open in Web Editor NEW

5.6K 24.0 237.0 29.57 MB

A framework for building compiled Node.js add-ons in Rust via Node-API

Home Page: https://napi.rs

License: Other

Rust 73.73% JavaScript 4.12% TypeScript 21.44% Dockerfile 0.71%

napi rust javascript napi-rs nodejs neon node node-api

napi-rs's People

Contributors

Stargazers

Watchers

Forkers

amilajack frando hoangpq anshulrgoyal oyyd mike-dax monocodus-demonstrations bltavares isgasho rottenpen biztrology-kd matheus-fdte strong-roots-capital getditto fanatid icodein c-nixon kdy1 demoorjasper nikolasmelui orangecms sociosarbis pimeys mfoonirlee hellomouse dennis-zhang-sh xzlinux skywalker512 zongkelong pantharshit00 lyhourchhen niuniuanran fireairforce therakeshpurohit bmacnaughton joaomoreno promise94 idan-at h-a-n-a liulinboyi mischnic dystudio screetbloom kiliaosi transparencies linecode pepoviola knewbie zeroslope dceddia alcalzone jose-acevedoflores joostk zh30 redstrike dev-resources simonvandel a2670392079 martinjlowm heka666 huntragon stephank antoniomuso messense killagu adumbidiot kwonoj wcisco17 jzeuzs waltonseymour u-c-s kielan cgqaq bnoordhuis devongovett tpisto jperocho speedy-js hywan ahaoboy lishoulong ringozzt sunli829 dirtybit ms-jpq jplatte erichdongubler nzxtcorp seritools vishnuchandrappan yssource amrbashir hhy5277 xhuz liby blessed4eva estk jserfeng noneofyourbusiness1415252 mat-if

napi-rs's Issues

Checksum after node.lib downloaded

https://github.com/nodejs/node-gyp/blob/master/lib/install.js#L340

Can't transfrom JsNumber into u8

I'm trying to send an array of numbers from JS to Rust, but I can't transform the JsNumbers into u8. Here's my attempt:

    let js_object = ctx.get::<JsObject>(1)?;

    let mut chunk: Vec<u8> = vec![];
    for i in 0..js_object.get_array_length()? {
        let val: JsNumber = js_object.get_element::<JsNumber>(i)?.into()?;
        let val: u8 = val.try_into()?;
        chunk.push(val);
    }

Error message:

no method named `try_into` found for struct `napi::JsNumber` in the current scope
items from traits can only be used if the trait is in scope

Continuous Integration

We need test these codes in differences platforms and rust versions.

Auto generate .d.ts

Rough notes:

Provide a new crate named napi-bindgen-rt for Rust users.
Provide a new macro in napi-derive named bindgen
Convert rust types in macro and generate runtime codes:

use napi_bindgen_rt::Maybe;
use napi_derive::bindgen;

#[bindgen]
pub fn sum(x: u32, y: Maybe<Option<u32>>) -> u32 {
  x + y.unwrap_option_or(|| 0)
}

export function sum(x: number, y: number | undefined | null): number

TODO

List Rust types => ts types convert table
What about async codes?
What about JsClass? Should we provide class bindgen like PyO3 or node-bindgen ?
What about Node.js builtin modules? Should we provide node-sys crate like web-sys in wasm-bindgen

ThreadSafeFunction is unsafe

According to the docs:

napi_threadsafe_function objects are destroyed when every thread which uses the object has called napi_release_threadsafe_function() or has received a return status of napi_closing in response to a call to napi_call_threadsafe_function

Upon receiving a return value of napi_closing from napi_call_threadsafe_function() a thread must not use the thread-safe function anymore because it is no longer guaranteed to be allocated.

This library should check if any calls to a threadsafe function result in napi_closing in order to prevent a use-after-free bug.

Maybe we could signal a "poisoned" function by setting the inner raw_tsfn to null, and either asserting that it isn't null or returning an error?

Also, what do you think about calling the release function on drop?

This type also look like it used to implement Clone. However, this impl was unsafe and looks like it has been removed. Maybe we could reintroduce a manual implementation of clone again, calling napi_acquire_threadsafe_function?

In any case, this invalid Clone impl makes it fairly easy to cause use-after-frees in the current crates.io version of napi, myabe you should consider yanking it?

Electron Support

While experimenting with this library, I realized that I can't get any generated modules to be loaded by Electron on Windows. I'm running on Windows 10 and trying to use Electron 9.1.1.

I think the problem is with linking to the wrong version of node.lib, as the build script appears to unconditionally link to the node.lib of the installed node, while it should be linking to electron's node.lib. I think this library is also missing a delay-load hook implementation.

Electron throws "A dynamic link library (DLL) initialization routine failed" error on Windows

I compiled my library with vs2019+cmake+llvm on Windows 10.
Then I use the generated .node file in an electron project, it throws error with info "A dynamic link library (DLL) initialization routine failed".

Reproduce on Windows:

git clone https://github.com/napi-rs/package-template
cd package-template
electron .

But it works fine with Node 14 on Windows, and Electron on macOS.

Some useful(maybe) links:
electron/electron#19884
cmake-js/cmake-js#188

it seems like napi build cannot assure package.name exist

as this code fragment

?? syntax only assure package field exact but not package.name

maybe tomlContent.package && tomlContent.package.name or tomlContent.package?.name

Support BSD

Node.JS Async callback convention

Hello,

Here you prepend a null value to the arguments that you pass to the callback:

napi-rs/napi/src/threadsafe_function.rs

Lines 207 to 213 in 2ff09ea

 let values = ret.unwrap(); 

 let js_null = env.get_null().unwrap(); 

 let mut raw_values: Vec<sys::napi_value> = vec![]; 

 raw_values.push(js_null.0.value); 

 for item in values.iter() { 

 raw_values.push(item.0.value) 

 }

I don't think this is a convention? I can't find any reference to this in the Node.JS documentation.

Would it be possible to remove this null and move that responsibility to the user if they need to have it?

I can make a PR if you prefer.

CLI does not support versions like alpha

I tried to publish @swc/[email protected], which should publish @swc/core-*@v1.2.27, but npm script published @swc/core-*@v1.2.27

Powerful CLI

Init project from scratch
Support monorepo (Cargo & Lerna)
Build and copy dylib
Release different platform/arch packages

Module did not self-register

internal/modules/cjs/loader.js:1188
return process.dlopen(module, path.toNamespacedPath(filename));
^

Error: Module did not self-register: '/mnt/e/rust/node-binding-comparision/napi-rs-demo/index.node'.
at Object.Module._extensions..node (internal/modules/cjs/loader.js:1188:18)
at Module.load (internal/modules/cjs/loader.js:986:32)
at Function.Module._load (internal/modules/cjs/loader.js:879:14)
at Module.require (internal/modules/cjs/loader.js:1026:19)
at require (internal/modules/cjs/helpers.js:72:18)
at Object. (/mnt/e/rust/node-binding-comparision/napi-rs-demo/index.js:1:11)
at Module._compile (internal/modules/cjs/loader.js:1138:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
at Module.load (internal/modules/cjs/loader.js:986:32)
at Function.Module._load (internal/modules/cjs/loader.js:879:14)

Remove bindgen

Bindgen rely on the llvm and many other dependecies, which make the build slower and complicated.

/cc @adumbidiot

register_module results in a compile error if function name is init_module

I'm currently migrating swc, and I hit the bug with

register_module!(native, init_module);

fn init_module(module: &mut Module) -> Result<()> {
    module.create_named_method("transform", transform::transform)?;
    module.create_named_method("transformSync", transform::transform_sync)?;
    Ok(())
}

error[E0061]: this function takes 2 arguments but 1 argument was supplied
  --> native/src/lib.rs:21:1
   |
21 | register_module!(native, init_module);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   | |
   | supplied 1 argument
   | defined here
   | expected 2 arguments
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Doesn't build on Fedora 32, fatal error: 'node_api.h' file not found

Update: After installing nodejs-devel the project now builds. Might be something worth mentioning in the readme?

Ubdate 2: After using the version of napi on master running cargo test now works again. I guess it has been fixed between the latest release and now? In any case, everything is now working flawless 😄

I'm evaluating a few different crates for building node packages using Rust, but I can't manage to install napi-sys without manually setting the NODE_INCLUDE_PATH, otherwise it just fails outright when compiling with the following error:

error: failed to run custom build command for `napi-sys v0.4.7`

Caused by:
  process didn't exit successfully: `/home/sondre/Code/ts/fargelegging/target/debug/build/napi-sys-0f27819659c839d1/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=NODE_INCLUDE_PATH
  cargo:rerun-if-changed=src/bindings.h
  cargo:rerun-if-changed=src/lib.rs
  cargo:rerun-if-changed=src/sys.rs

  --- stderr
  src/bindings.h:1:10: fatal error: 'node_api.h' file not found
  src/bindings.h:1:10: fatal error: 'node_api.h' file not found, err: true
  thread 'main' panicked at 'Unable to generate napi bindings: ()', /home/sondre/.cargo/registry/src/github.com-1ecc6299db9ec823/napi-sys-0.4.7/build.rs:53:6
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
     1: core::panicking::panic_fmt
               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/panicking.rs:85
     2: core::option::expect_none_failed
               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/option.rs:1221
     3: core::result::Result<T,E>::expect
               at /home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:933
     4: build_script_build::main
               at ./build.rs:46
     5: core::ops::function::FnOnce::call_once
               at /home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I'm using Fedora 32 (Linux neptune 5.8.18-200.fc32.x86_64) and tried both Node v14 and v15. If I set the environment variable to the error paths .node_header it works:

❯ NODE_INCLUDE_PATH=~/.cargo/registry/src/github.com-1ecc6299db9ec823/napi-sys-0.4.7/.node-headers/ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s

Any idea what the problem could be?

EDIT: Though I managed to get it to build, it still fails when running cargo test:


error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-Wl,--eh-frame-hdr" "-L" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1546fl3rjasrg3wa.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.17fjqt9tp8i8il7y.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.19nn6vz8vf9ggoot.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1aj0nl3fclgwnqbt.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1b2npgrbkif3b7rs.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1by9gkic8a4zt3k.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1em4cvihvdnitkij.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1sd1zuh4lxefknw7.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1syokc6y2avs5ro4.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1xduz1wsly5mlaxd.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.24lr6h04scv2nopi.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.24y3fsbtcu8iuecu.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.26cslcosnpojh8ec.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.2dh43d708n620uny.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.2e6ta37wtcjsa8en.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.2esogdf25a3uslwf.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.2hwr8wl8snr8p164.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.2jxrnnagfda3tslx.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.2k1mf9gzqy9gqjbp.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.2mb4c9p329i14vyu.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.2szlgm7rzvns3par.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.32455byjlyje0ttk.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.3aixmx4n1jfik0rf.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.3d6k6iz2zixbw89n.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.3n835haa9k0gknm5.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.3nhhgeoekhmzf9tg.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.3pplxyqxu4byklqj.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.3qrwwv2dirsmnoyn.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.3xlt8tze9hskgehn.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.3yi1rkacs8btxuum.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.42ctx7wxivyanun8.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.47ijb7vydm8yuhcf.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4e15liczznrylwti.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4gnotfcbk1w2zgy9.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4grv07majo77qyp9.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4ij40rscfycipu1b.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4il6360ex7r2wzg5.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4jxb1md00p66rrem.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4la6txtdfvi3h5p3.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4lzqp3o80c06f3yh.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4mo3bvflfdlsfzke.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4n71mwq4ylra9ars.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.4qh3tydls2id4ena.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.5bcf66cdunhnxjt7.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.5bfk8w6k4jch9r3i.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.5di1fwo6jbktnnma.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.d6mzura48n42mxu.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.j2jfl51p6iixh80.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.jl9nmaf14ndtpp0.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.qbsh1s6d1hozt8j.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.x5hjkn0p1jmoznl.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.z2592a0hhr5td1r.rcgu.o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.zcstbzfn8ramrgf.rcgu.o" "-o" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930" "/home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.rsgn0ytvn3rgnv0.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/home/sondre/Code/ts/fargelegging/target/debug/deps" "-L" "/home/sondre/Code/ts/fargelegging/target/debug/build/fargelegg-fe667e8d947edcfa/out" "-L" "/home/sondre/Code/ts/fargelegging/target/debug/build/tree-sitter-ffd1d2088ee8870c/out" "-L" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-ltree-sitter-javascript" "-Wl,--no-whole-archive" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-1a99bd050f5bcac9.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libterm-c3c443d72de8b429.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-8b34c4c4a224fb59.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode_width-b247e4f3706e4767.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_std-45a697d9a5a880a0.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libtree_sitter_highlight-6bcb2be562cd1092.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libnapi-c172e8bbcc151f68.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libnapi_sys-69a3099a92802cfe.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libonce_cell-c70fff6b9c258bb0.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libtree_sitter-71637ced495b7234.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libregex-5e98b4c8206d764c.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libthread_local-b2a88e4d32219c25.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/liblazy_static-bf21cfb31a9e28ca.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libregex_syntax-f43e01483191abd2.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libaho_corasick-8b3a916093d8aba6.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libmemchr-cc7fb82aea1c10a1.rlib" "/home/sondre/Code/ts/fargelegging/target/debug/deps/libstrum-e939436eefa24e18.rlib" "-Wl,--start-group" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-f14aca24435a5414.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-48d342a8b48d1d01.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-14bc0820888c8eb3.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-9cbd9e217bff06bc.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-31826136df98934e.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-075976a117c8fd5d.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-2d5cbedfbf17a011.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-0474372ff08c5319.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-d437c34460d2315a.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-fb61ed1b8cc4de79.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-bf76d1b643bfc9f0.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-a1b53aa7fddcf418.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-28585e57fac45c73.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-64801769bc15ab28.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-541997b56bb98660.rlib" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-cdea3c81adab3d12.rlib" "-Wl,--end-group" "/home/sondre/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-cd9f15a39fb65cbc.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-ldl" "-lutil"
  = note: /usr/bin/ld: /home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1em4cvihvdnitkij.rcgu.o: in function `fargelegg::__REGISTER_MODULE::register_module':
          /home/sondre/.cargo/registry/src/github.com-1ecc6299db9ec823/napi-0.5.1/src/lib.rs:179: undefined reference to `napi_module_register'
          /usr/bin/ld: /home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1em4cvihvdnitkij.rcgu.o: in function `fargelegg::__REGISTER_MODULE::register_module::init_module':
          /home/sondre/.cargo/registry/src/github.com-1ecc6299db9ec823/napi-0.5.1/src/lib.rs:203: undefined reference to `napi_throw_error'
          /usr/bin/ld: /home/sondre/Code/ts/fargelegging/target/debug/deps/fargelegg-da8046ecbed67930.1em4cvihvdnitkij.rcgu.o: in function `fargelegg::parser':
          /home/sondre/Code/ts/fargelegging/src/lib.rs:18: undefined reference to `napi_get_cb_info'
          /usr/bin/ld: /home/sondre/Code/ts/fargelegging/src/lib.rs:18: undefined reference to `napi_throw_error'
          /usr/bin/ld: /home/sondre/Code/ts/fargelegging/target/debug/deps/libnapi-c172e8bbcc151f68.rlib(napi-c172e8bbcc151f68.napi.1c36xmkc-cgu.0.rcgu.o): in function `napi::env::Env::create_string_from_chars':
          /home/sondre/.cargo/registry/src/github.com-1ecc6299db9ec823/napi-0.5.1/src/env.rs:163: undefined reference to `napi_create_string_utf8'
          /usr/bin/ld: /home/sondre/Code/ts/fargelegging/target/debug/deps/libnapi-c172e8bbcc151f68.rlib(napi-c172e8bbcc151f68.napi.1c36xmkc-cgu.0.rcgu.o): in function `napi::env::Env::create_function':
          /home/sondre/.cargo/registry/src/github.com-1ecc6299db9ec823/napi-0.5.1/src/env.rs:305: undefined reference to `napi_create_function'
          /usr/bin/ld: /home/sondre/Code/ts/fargelegging/target/debug/deps/libnapi-c172e8bbcc151f68.rlib(napi-c172e8bbcc151f68.napi.1c36xmkc-cgu.2.rcgu.o): in function `napi::js_values::object::JsObject::set_named_property':
          /home/sondre/.cargo/registry/src/github.com-1ecc6299db9ec823/napi-0.5.1/src/js_values/object.rs:39: undefined reference to `napi_set_named_property'
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error; 25 warnings emitted

Build fails with 32bit target

Trying to build for MSVC x86 due to loading 32bit Dlls on WIndows...

This fails with the NAPI library being the cause. Attached is a log of the build process:

Seems to compain a lot about expecting u32 but finding u64

build_log.txt

Communicate with threads from JS

I have a js_function that creates a thread every time it gets called. Is there a way to send messages to this thread from the JS side of things?

Here's what I'm trying to do, but this obviously doesn't work:

#[js_function(4)]
fn command(ctx: CallContext) -> napi::Result<JsFunction)> {
    let (sender, receiver) = unbounded();

    thread::spawn(move || {
      loop {
        // ...
        let message = receiver.recv();
      }
    });

    // call sender.send() somehow from JS
    // ...
}

I had a few ideas in mind, but couldn't make either of them work:

Initialize a HashMap in the init() function that keeps track of the senders based on an id and provide them to the command alongside ctx
Return a JsFunction from command that calls sender.send when its invoked

Is there a way to to achieve what I'm trying to do?

Finish all N-API binding

API remains:

Pattern `napi_bigint` not covered

I am really new to rust and all that universe.

i tried to install napi and so on, but i get:

error[E0004]: non-exhaustive patterns: `napi_bigint` not covered
   --> ../.cargo/registry/src/github.com-1ecc6299db9ec823/napi-0.5.1/src/js_values/value_type.rs:46:11
    |
46  |     match value {
    |           ^^^^^ pattern `napi_bigint` not covered
    | 
   ::: ../target/debug/build/napi-sys-c52f7ba1a7f9b699/out/bindings.rs:358:5
    |
358 |     napi_bigint = 9,
    |     ----------- not covered
    |
    = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
    = note: the matched value is of type `napi_sys::napi_valuetype`

Thanks :)

Benchmark action is broken for PRs from users without "collaborator" privileges

This action fails for PRs from people who don't have collaborator privileges. I elaborated slightly more here.

I think we could either disable it on PRs, or switch back to a manually specified secret and skip that action if it is not present. Maybe there is another may I'm missing.

N-API TheadSafeFunction

Need this for running future with Libuv

`NapiValue` trait functions are unsafe

The NapiTrait functions are unsafe as creating an napi_value from a null pointer, or even a valid pointer to another type is "safe". As such, the from_* methods should be unsafe.

Should napi-rs be a dependency or devDependency?

Hi,

I'm learning rust to be able to create N-API rust modules, so I find this project incredibly interesting.

I'm creating my first module, and I noticed that the README indicates that napi-rs should be a dependency, but it's not one in the example module.

Maybe it should be a dev dependency?

exit 3221225477 running with nodejs x32 on windows 64 in release mode

Everything is just fine in debug mode, but node.exe exit with status 1 while loading the .node file compiled with --release flag

See https://github.com/napi-rs/package-template/actions/runs/361398266

Threadsafe this context lost on call

Hi, I discovered your repo today, and was delighted how quickly I had a very basic function call working with callback.call(Some(js_this), &[js_string, js_num]);

Then I wanted to move on to testing the threadsafe functions using ToJs, but got a bit stuck.
I'm under the impression that the call_js_cb in threadsafe_function.rs, will always use 'undefined' as the value for the recv arg in the napi_call_function. Which I need to be the correct context or my js function won't have the proper this context.

Any ideas/suggestions?

napi_create_external

resolve segmentation fault in napi-rs/node-rs#61

Build fails if the cargo package is in a workspace

If you try to call the build script from a cargo package that is inside a cargo workspace, the script will look for the target directory in the directory of the package

However, building a package in a workspace produces a target directory that is at the level of the cargo workspace, so the build will fail with a "ENOENT: no such file or directory" error.

Higher level codegen API for Threadsafe function

with default feature:

#[async_function(0..n)]
async fn read_file(...args: NapiValue) -> Result<NapiValue>

with tokio feature:

#[tokio_async_function(0..n)]
async fn read_file(...args: NapiValue) -> Result<NapiValue>

Most sys enums are unsafe

According to the bindgen docs for rustified enums:

Use this with caution, creating this in unsafe code (including FFI) with an invalid value will invoke undefined behaviour. You may want to use the newtype enum style instead.

This is problematic, as NAPI often adds to these enums across editions. This causes UB if, for example, an napi 3 module is loaded in an napi 6 context and calls typeof on a bigint, creating a rust enum with an invalid state.

This can be fixed by not using rust enums for these types and using constant values instead. Many From/Into impls will have to be replaced with TryFrom/TryInto, but these impls were unsafe anyways.

I ran into this issue while working on #271. If you want, I can push fixes there or I can just make a new PR fixing this.

Aarch64 support wanted

For example, in Termux, can use.
Thanks.

Serde integrated

Equivalent to Napi::ObjectWrap and Class with Private Data

From a cursory look at the classes test case it appears that the property internally used is still represented as a JsNumber. Is there a way to represent a class that holds rust structs that can't be represented as a JS property (like a File or reqwest::Client, etc). I see that C++ Napi::ObjectWrap is a bit what I'm after:

class Example : public Napi::ObjectWrap<Example> {
  public:
    static Napi::Object Init(Napi::Env env, Napi::Object exports);
    Example(const Napi::CallbackInfo& info);
    static Napi::Value CreateNewItem(const Napi::CallbackInfo& info);

  private:
    double _value;
};

In the above example, _value field isn't exposed and can pretty be anything.

I took a look at some of the downstream napi-rs packages and there isn't too much in the way classes, so I figured that this feature may not be implemented and it be best to raise an issue.

ThreadsafeFunction not available

Hey @Brooooooklyn, tried to follow this example, but I can't use ThreadsafeFunction.

no method named `create_threadsafe_function` found for reference `&napi::Env` in the current scope
method not found in `&napi::Env`

I have version 5.1 installed, does only 4.x support these methods?

Call overhead benchmark

Pass JsObject to N-APi functions vs Encode object into Flatbuffers and decode it in the N-API side.

Cross Compilation

It would be nice to be able to cross compile NAPI modules, like from x64 to arm64. Maybe we could add that functionality to the CLI.

Testing framework in JavaScript side

Node crashed with Illegal instruction: 4

I am using this library to implement a sync ipc library with tokio tcp. But I found that if I call the tokio sync method from node.js multiple times with a big(>1000 bytes) buffer, it results in a node.js crash with error message: Illegal instruction: 4.

But it works fine if call a rust method without any tokio operation. (even with larger buffer data)

Here is the example:
example.zip

Need to run demo_server.js firstly, then run demo.js

(Example is based on the official example and made some modification in index.js file)

`Env::from_raw` should be unsafe

Env::from_raw(env: sys::napi_env) takes a pointer that may or may not be valid.

Serde Value <=> JsValue

I'd like to have API like:

let result: Value<'env, Any> = env.from_serde(SerdeValue)?;

Add a guide of how to setup a basic project

It would be nice if there is a guide(or a CLI, a template repo) to help users setup a project so that they can take a try and play around as quickly as possible.

I guess building for different platforms would be the most challenging part and I hope it could be included.

Got wrong value from JS ArrayBuffer

Pass the same ArrayBuffer and JsBuffer from NodeJS but got different results

declare_class macro, like declare_types in neon

https://api.neon-bindings.com/neon/macro.declare_types.html

Wrapped objects don't get dropped?

When wrapping a native struct in a js object, the struct never seems to be dropped. No matter if the node process crashed or exits gracefully, a impl Dropon a struct that was wrapped never gets called.

I can provide a test case - would be useful though if before the changes from @cztomsik could be pulled in because I worked upon these.

Website

API documentation and real world examples

Decouple sys module of new napi-rs into a crate

napi-rs/napi#4

Windows build: PermissionDenied

When building napi-rs on Windows, I get this error:

error: failed to run custom build command for `napi-package-template v0.1.0 (C:\Data\Projects\package-template)`

Caused by:
  process didn't exit successfully: `C:\Data\Projects\package-template\target\release\build\napi-package-template-7c08280ff4b54a5f\build-script-build` (exit code: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }', C:\Users\fluxx\.cargo\registry\src\github.com-1ecc6299db9ec823\napi-build-0.2.1\src\lib.rs:42:66
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Caused by this line of code:
https://github.com/napi-rs/napi-rs/blob/master/build/src/lib.rs#L42

It looks like the build script tried to write lib file to nodejs install folder which by default is

C:\Program Files\nodejs

Is it better to save the lib file to the current user's home dir? Otherwise, we need Admin privilege to build napi-rs modules.

Thanks

	let values = ret.unwrap();
	let js_null = env.get_null().unwrap();
	let mut raw_values: Vec<sys::napi_value> = vec![];
	raw_values.push(js_null.0.value);
	for item in values.iter() {
	raw_values.push(item.0.value)
	}