Support Node/Deno (NAPI instead of bun:ffi)

[remorses]

Have you thought about using NAPI to make the project run both in Bun and Node?

There is this package to create automatic NAPI bindings from Zig code https://github.com/cztomsik/napigen

[kommander]

I am open to it. FFI was just really convenient and is faster than NAPI, but yes I gave it some thought already. Might happen at some point, just not priority for now on my side. A lot to be figured out for the actual API and then probably some stabilization needed.

[jlucaso1]

wasm (free standing or wasi) can be considered too?

[kommander]

@jlucaso1 I considered it in the beginning, but it being a lib for terminal UIs it's not a blocker to load native libs and wasm has some overhead with its vm.

[esatterwhite]

I've only just stumbled onto this project and rather excited by its goals. But, I am confused as to the target run time. Does this only run on bun?

[esatterwhite]

Deno also has an FFI interface as well for what its worth.

[kommander]

It currently only runs on bun exclusively. There are no plans to support other runtimes, though I am open to it.

[esatterwhite]

It currently only runs on bun exclusively. There are no plans to support other runtimes, though I am open to it.

Can we make plans? 😃

[kommander]

Sure, the zig.ts exports a RenderLib interface and a resolveRenderLib function, both is used throughout the codebase. It also eagerly loads the native lib to reduce startup time.

So to provide a NAPI module one Just™ would have to solve this incomplete list:

• wrap the native lib.zig c abi to build .node modules, using the static libs from then next step
  • expose a RenderLib compatible interface
  • in resolveRenderLib and for the eager loading if !bun return the napi lib
  • Note: the module level ffi native path resolution at the top of zig.ts needs to be conditional and for non-bun dynamically import the RenderLibcompatible .node module instead of the native ffi lib
• extend the build.zig to also build static versions
• in core/scripts/build.ts
  • also build the .node modules as a step
  • add the .node modules to the respective binary npm packages
  • add the .node modules to artifacts
  • add tha t to the pipeline build.yml
  • in release.yml
    • bundle the static libs from artifacts in the zips with the dynamic ones
• extend the "build & test" workflows to run a matrix, also running the tests on napi supported runtimes

And the napi needs to be maintained to stay in sync with the native interface, which is far from stable and changes almost daily, so something generated would work best if possible, so it can be regenerated when the native interface changes.

Note: this does not consider the whole 3D part which currently also uses an FFI lib, which needs to be switched out to some napi webgpu module as well. Deno has its own webgpu bindings. All of the webgpu interfaces should be mostly compatible though.

[remorses]

It would be easier to wait for Node.js to add something like Bun ffi into core: nodejs/node#57761

[kommander]

Probably, would have to check how compatible the interfaces are, as ffi != ffi, so it likely still needs a compat layer for different runtimes.