napi-rs/napi-rs

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

napi-rs

This project was initialized from xray

A framework for building compiled Node.js add-ons in Rust via Node-API. Website: https://napi.rs

Platform Support

MSRV

Rust 1.65.0

	node12	node14	node16	node18	node20
Windows x64	✓	✓	✓	✓	✓
Windows x86	✓	✓	✓	✓	✓
Windows arm64	✓	✓	✓	✓	✓
macOS x64	✓	✓	✓	✓	✓
macOS aarch64	✓	✓	✓	✓	✓
Linux x64 gnu	✓	✓	✓	✓	✓
Linux x64 musl	✓	✓	✓	✓	✓
Linux aarch64 gnu	✓	✓	✓	✓	✓
Linux aarch64 musl	✓	✓	✓	✓	✓
Linux arm gnueabihf	✓	✓	✓	✓	✓
Linux arm muslebihf	✓	✓	✓	✓	✓
Linux powerpc64le gnu	✓	✓	✓	✓	✓
Linux s390x gnu	✓	✓	✓	✓	✓
Linux riscv64 gnu	N/A	N/A	✓	✓	✓
Linux aarch64 android	✓	✓	✓	✓	✓
Linux armv7 android	✓	✓	✓	✓	✓
FreeBSD x64	✓	✓	✓	✓	✓

This library depends on Node-API and requires [email protected] or later.

We already have some packages written by napi-rs: node-rs

One nice feature is that this crate allows you to build add-ons purely with the Rust/JavaScript toolchain and without involving node-gyp.

Taste

You can start from package-template to play with napi-rs

Define JavaScript functions

/// import the preludes
use napi::bindgen_prelude::*;
use napi_derive::napi;

/// module registration is done by the runtime, no need to explicitly do it now.
#[napi]
fn fibonacci(n: u32) -> u32 {
  match n {
    1 | 2 => 1,
    _ => fibonacci(n - 1) + fibonacci(n - 2),
  }
}

/// use `Fn`, `FnMut` or `FnOnce` traits to defined JavaScript callbacks
/// the return type of callbacks can only be `Result`.
#[napi]
fn get_cwd<T: Fn(String) -> Result<()>>(callback: T) {
  callback(env::current_dir().unwrap().to_string_lossy().to_string()).unwrap();
}

/// or, define the callback signature in where clause
#[napi]
fn test_callback<T>(callback: T)
where T: Fn(String) -> Result<()>
{}

/// async fn, require `async` feature enabled.
/// [dependencies]
/// napi = {version="2", features=["async"]}
#[napi]
async fn read_file_async(path: String) -> Result<Buffer> {
  tokio::fs::read(path)
    .map(|r| match r {
      Ok(content) => Ok(content.into()),
      Err(e) => Err(Error::new(
        Status::GenericFailure,
        format!("failed to read file, {}", e),
      )),
    })
    .await
}

more examples at examples

Building

This repository is a Cargo crate. Any napi-based add-on should contain Cargo.toml to make it a Cargo crate.

In your Cargo.toml you need to set the crate-type to "cdylib" so that cargo builds a C-style shared library that can be dynamically loaded by the Node executable. You'll also need to add this crate as a dependency.

[package]
name = "awesome"

[lib]
crate-type = ["cdylib"]

[dependencies]
napi = "3"
napi-derive = "3"

[build-dependencies]
napi-build = "1"

And create build.rs in your own project:

// build.rs
extern crate napi_build;

fn main() {
  napi_build::setup();
}

So far, the napi build script has only been tested on macOS Linux Windows x64 MSVC and FreeBSD.

Install the @napi-rs/cli to help you build your Rust codes and copy Dynamic lib file to .node file in case you can require it in your program.

{
  "package": "awesome-package",
  "devDependencies": {
    "@napi-rs/cli": "^1.0.0"
  },
  "napi": {
    "name": "jarvis" // <----------- Config the name of native addon, or the napi command will use the name of `Cargo.toml` for the binary file name.
  },
  "scripts": {
    "build": "napi build --release",
    "build:debug": "napi build"
  }
}

Then you can require your native binding:

require('./jarvis.node')

The module_name would be your package name in your Cargo.toml.

xxx => ./xxx.node

xxx-yyy => ./xxx_yyy.node

You can also copy Dynamic lib file to an appointed location:

napi build [--release] ./dll
napi build [--release] ./artifacts

There are documents which contains more details about the @napi-rs/cli usage.

Testing

Because libraries that depend on this crate must be loaded into a Node executable in order to resolve symbols, all tests are written in JavaScript in the test_module subdirectory.

To run tests:

yarn build:test
yarn test

Related projects

• neon
• node-bindgen

Features table

Rust Type	Node Type	NAPI Version	Minimal Node version	Enable by napi feature
u32	Number	1	v8.0.0
i32/i64	Number	1	v8.0.0
f64	Number	1	v8.0.0
bool	Boolean	1	v8.0.0
String/&'a str	String	1	v8.0.0
Latin1String	String	1	v8.0.0	latin1
UTF16String	String	1	v8.0.0
Object	Object	1	v8.0.0
serde_json::Map	Object	1	v8.0.0	serde-json
serde_json::Value	any	1	v8.0.0	serde-json
Array	Array	1	v8.0.0
Vec	Array	1	v8.0.0
Buffer	Buffer	1	v8.0.0
External	External	1	v8.0.0
Null	null	1	v8.0.0
Undefined/()	undefined	1	v8.0.0
Result<()>	Error	1	v8.0.0
T: Fn(...) -> Result	Function	1	v8.0.0
Async/Future	Promise	4	v10.6.0	async
AsyncTask	Promise	1	v8.5.0
JsGlobal	global	1	v8.0.0
JsSymbol	Symbol	1	v8.0.0
Int8Array/Uint8Array ...	TypedArray	1	v8.0.0
JsFunction	threadsafe function	4	v10.6.0	napi4
BigInt	BigInt	6	v10.7.0	napi6

napi-rs's Issues

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:

1. 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
2. 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?

`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.

Serde integrated

N-API TheadSafeFunction

Need this for running future with Libuv

Env::throw_error is unsafe if msg contains 0s

Env::throw_error is unsafe if msg contains 0s. We do no checks elsewhere to ensure that msg contains no 0s, so this is not safe.

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

Powerful CLI

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

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)

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

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.

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.

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)

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

Support BSD

Website

API documentation and real world examples

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.

Continuous Integration

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

Call overhead benchmark

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

Aarch64 support wanted

For example, in Termux, can use.
Thanks.

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>

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

Finish all N-API binding

API remains:

• Enum types
• napi_create_buffer_copy
• napi_create_date
• napi_create_typedarray
• napi_create_dataview
• napi_create_bigint_int64
• napi_create_bigint_uint64
• napi_create_bigint_words
• napi_create_string_latin1
• napi_get_prototype
• napi_get_typedarray_info
• napi_get_dataview_info
• napi_get_date_value
• napi_get_value_bigint_int64
• napi_get_value_bigint_uint64
• napi_get_value_bigint_words
• napi_get_value_string_latin1
• napi_get_global
• napi_instanceof
• napi_is_error
• napi_is_typedarray
• napi_is_dataview
• napi_strict_equals
• napi_detach_arraybuffer
• napi_is_detached_arraybuffer

Windows thread safe problem

Run future in libuv randomly cased 3221225477 exit code in Windows platform, but I can't reproduce locally. Need more investigating.

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?

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

declare_class macro, like declare_types in neon

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

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

Checksum after node.lib downloaded

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

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

Testing framework in JavaScript side

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.

Remove bindgen

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

/cc @adumbidiot

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?

`Env::from_raw` should be unsafe

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

Some functions leak cstrings

Opening this to track issues crated by #309. Some napi functions now leak cstrings.

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?

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 :)

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.

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.

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.

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.

Serde Value <=> JsValue

I'd like to have API like:

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

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

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.

Decouple sys module of new napi-rs into a crate

napi-rs/napi#4

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?

napi_create_external

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

Got wrong value from JS ArrayBuffer

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

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)

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