Native Binding 👈🏻 Native Code 👈🏻 LLVM IR 👈🏻 SWC 👈🏻 FFI ➕ TypeScript ?

[LcJuves]

Native Binding 👈🏻 Native Code 👈🏻 LLVM IR 👈🏻 SWC 👈🏻 FFI ➕ TypeScript ?

Native Binding 👈🏻 Native Code 👈🏻 LLVM IR 👈🏻 SWC 👈🏻 FFI ➕ TypeScript ?

[proggeramlug]

Thanks for the sketch! Reading the arrows right-to-left it's essentially Perry's existing pipeline (TypeScript → SWC → AST → HIR → LLVM IR → native .o → link), so the interesting part is the "Native Binding" at the front.

That term collapses two pretty different ideas, and the implementation diverges completely depending on which you mean:

1. Export Perry-compiled TS as a native library with a stable C ABI (a .a/.so/.dylib that other native code can call). This is already partly real — the runtime is full of #[no_mangle] FFI, we link via cc, and out-of-tree perry-ext-* linking landed in Out-of-the-box (no workspace source) builds can't link perry-ext-* libs — node:http server fails to link #2532. The missing piece is a generated C/ABI header derived from your TS exports.

2. Import existing native libraries into TS by generating FFI glue from .d.ts declarations (the napi-rs / wasm-bindgen direction). Perry doesn't really do this today, and it's a separate binding-generator project rather than a codegen change.

Could you clarify which direction "Native Binding" points — exporting Perry code for native consumers, or importing native libs into TS? With that nailed down this becomes actionable; as written it's hard to turn into a concrete proposal since the rest of the chain already exists.

[LcJuves]

Native binding refers to the binding performed when an operating system platform application starts up.

[LcJuves]

Here, FFI refers to calling operating system and platform application APIs via implementations like NAPI or wasm-bindgen.

[LcJuves]

The runtime is full of #[no_mangle] FFI, I think it's good !!!