Add Typescript support via N-API

[ShahanaFarooqui]

Rust → TypeScript Binding Options

Options to consider

1️⃣ Direct N-API with napi-rs

✅ Pros

• Mature and production-ready
• TypeScript definitions auto-generated
• Excellent performance (native execution)
• Actively maintained
• Seamless Node.js integration

❌ Cons

• Separate from UniFFI workflow (different binding system)
• Requires maintaining separate binding definitions

---

2️⃣ WASM with wasm-bindgen (Browser-Focused)

✅ Pros

• TypeScript definitions auto-generated
• Works in browsers and Node.js
• No native compilation required for end users

❌ Cons

• Different runtime constraints (no threads, limited I/O)
• Some gl-sdk dependencies are not WASM-compatible
• Performance is good, but not native-level

---

High-Level Comparison

---

Attempted UniFFI (WASM Approach)

# Option 1 (uniffi-bindgen-react-native):
cd ./libs/gl-sdk
npm install uniffi-bindgen-react-native --save-dev
mkdir -p test-bindings/ts
mkdir -p test-bindings/cpp
npx uniffi-bindgen-react-native generate wasm bindings   --library ../../target/release/libglsdk.so   --ts-dir test-bindings/ts   --cpp-dir test-bindings/cpp

# Option 2 (wasm-bindgen):
cd ./libs/gl-sdk
cargo install wasm-bindgen-cli
rustup target add wasm32-unknown-unknown
# Fails in this step
cargo build --target wasm32-unknown-unknown --no-default-features --features wasm
wasm-bindgen target/wasm32-unknown-unknown/debug/glsdk.wasm --out-dir pkg --target web

# Option 3 (wasm-pack):
cd ./libs/gl-sdk
cargo install wasm-pack
wasm-pack build --target web --no-default-features
wasm-pack build --target nodejs --no-default-features
wasm-pack build --target bundler --no-default-features

🚨 Critical Compatibility Issue

• Critical compatibility issue. The gl-sdk has dependencies that don't support WASM out of the box.
• The gl-sdk cannot currently be compiled to WASM.
• Lightning Network SDKs rely on cryptographic and system-level dependencies that require native code and are incompatible with the WASM sandbox.
• Problematic dependencies include:
  • secp256k1-sys -- Requires native C compilation (not WASM-compatible)
  • getrandom -- Requires "js" feature flag at minimum
  • tokio -- Async runtime has WASM limitations
  • Additional Bitcoin/Lightning dependencies likely include native code

Conclusion

• WASM is currently a showstopper for gl-sdk due to native cryptographic and system-level dependencies.
• For Node.js environments, napi-rs is the practical and production-ready solution.

Next Steps (if we decide to add N-API bindings)

• Generate N-API bindings for minimal targets (~99% coverage, no exotic architectures):
  • Linux (glibc): x86_64-unknown-linux-gnu, aarch64-unknown-linux-gnu
  • Linux (musl): x86_64-unknown-linux-musl
  • macOS: x86_64-apple-darwin, aarch64-apple-darwin
  • Windows: x86_64-pc-windows-msvc
• Add GitHub Actions release workflow (matrix build for above targets)
• Ensure all artifacts build successfully in CI
• Enable npm publishing (via tagged release)

[cdecker]

Great work @ShahanaFarooqui, I think you're right, going with n-api is likely the best possible integration, and we have JS/TS experts in the team, so this is perfectly fine ^^