sst
Support Node/Deno (NAPI instead of bun:ffi)
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
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 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.
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?
It currently only runs on bun exclusively. There are no plans to support other runtimes, though I am open to it.
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? 😃
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.zigc abi to build.nodemodules, using the static libs from then next step- expose a
RenderLibcompatible interface - in
resolveRenderLiband for the eager loading if !bun return the napi lib - Note: the module level ffi native path resolution at the top of
zig.tsneeds to be conditional and for non-bun dynamically import theRenderLibcompatible.nodemodule instead of the native ffi lib
- expose a
- extend the
build.zigto also build static versions - in
core/scripts/build.ts- also build the
.nodemodules as a step - add the
.nodemodules to the respective binary npm packages - add the
.nodemodules 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
- also build the
- 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.
It would be easier to wait for Node.js to add something like Bun ffi into core: https://github.com/nodejs/node/pull/57761
Probably, would have to check how compatible the interfaces are, as ffi != ffi, so it likely still needs a compat layer for different runtimes.
Maybe support for deno first, node later when the playing field is a bit more level?
Out of curiosity, Why does this project need access to the gpu? Wouldn't it make more sense to leave that up to user to install gpu accelerated terminals if that is what they want?
It seems a bit outside the scope of what a tui framework should care about. But 🤷 I don't have a leg to stand on here.
It doesn't need it for anything non-3D, the threejs stuff is completely optional for the core, just a fun gimmick currently. It doesn't load the 3D module if it's Not explicitly imported, so it could be made a separate package. I was just mentioning it for completeness.