Publish gl-sdk on npm registry

[ShahanaFarooqui]

No description provided.

[ShahanaFarooqui]

The first two commits are a continuation of PR Add TypeScript support via N-API. In the initial implementation, I overlooked adding a bindings-typescript task and asynchronous handling to all I/O-bound NAPI bindings. Since gl-sdk exposes a synchronous Rust API, we use tokio::task::spawn_blocking rather than native async/await. This ensures that blocking operations are offloaded to a thread pool and do not block the Node.js event loop.

[ShahanaFarooqui]

Hi @cdecker,

The PR is ready for review but before the library can be published to npm, a few items need clarification:

1. npm Organization Access & Package Conventions
Do we currently have access to the Blockstream or Greenlight organization on the npm registry? We'll need to align the package scope (@organisation/library) and versioning with our standard conventions before proceeding.

2. NPM_TOKEN Repository Secret
Once npm org access is confirmed, NPM_TOKEN will need to be added as a repository secret. The Typescript Library / Publish to NPM workflow is currently failing due to this missing token.

To unblock testing against @blockstreamgl/gl-sdk, you can temporarily add the token npm_<shared-in-dm> as a secret. I have tested the publish flow multiple times from my fork using this token: https://github.com/ShahanaFarooqui/greenlight/actions/workflows/typescript.yml

3. Workflow Trigger
I have kept the trigger condition for .github/workflows/typescript.yml consistent with the existing workflows. Let me know if it needs to be adjusted.

4. Platform Support
The following targets are supported with this PR:

• x86_64-unknown-linux-gnu
• aarch64-unknown-linux-gnu
• x86_64-apple-darwin
• aarch64-apple-darwin
• x86_64-pc-windows-msvc

x86_64-unknown-linux-musl was part of the initial plan but is not included in this PR. The musl build is currently failing due to a missing cross-compilation toolchain (/usr/bin/ld: cannot find libgcc_s.so.1). For now, we can remove musl support since it's a niche target. If it is needed in the future, the recommended approach would be to build it inside a pre-configured container such as clux/muslrust or messense/rust-musl-cross with proper musl cross-compilation toolchain.

Happy to make any adjustments. Please let me know how you'd like to proceed.

[cdecker]

Looks like once again I forgot to submit my reviews 🤦

Thanks @ShahanaFarooqui for sharing the information, I think the @blockstream org on npmjs.org is completely unrelated to us, and so creating a new org is likely not the worst idea (any chance we can claim the global glsdk package name?). I'll see what I can do re policy for npm packages.

In the meantime I have also added the secret, so we should now be able to test the full roundtrip 👍

[cdecker]

Very nice overall, I am eager to merge this :-)

[ShahanaFarooqui]

I think the @blockstream org on npmjs.org is completely unrelated to us, and so creating a new org is likely not the worst idea (any chance we can claim the global glsdk package name?). I'll see what I can do re policy for npm packages.

Turns out glsdk is already taken too. For now, I’ve renamed the package to @greenlightcln/glsdk (which looked a bit more logical to me). That also meant updating the NPM_TOKEN secret, and surprisingly, I actually had the permissions to do it.

[ShahanaFarooqui]

Closing this PR in favour of #671, as CI is passing and the library is successfully being published to npm via GitHub Actions in that PR.

Published @greenlightcln/glsdk@0.0.1 with workflow 22158240201
Published @greenlightcln/glsdk@0.0.2 with workflow 22159407053