Node.js Environment
Current status, known limitations, and workarounds for using the Lumera SDK in Node.js.
Known Issue: The Lumera JS SDK currently has compatibility issues in Node.js environments. The browser environment is the recommended target for production applications. This page documents the current state and available workarounds.
The Problem
The SDK relies on several WASM modules that behave differently in Node.js vs browser environments:
| Module | Browser | Node.js |
|---|---|---|
rq-library-wasm (RaptorQ) | Works via ESM WASM import | Fails — createRequire + WASM file path resolution issues |
@bokuweb/zstd-wasm (Zstd) | Works via WASM loader | Works via @mongodb-js/zstd native binding |
blake3 | Works via blake3/browser-async | Works via native binding |
The primary failure point is the RaptorQ WASM proxy (raptorq-proxy.node.ts), which uses createRequire to load the WASM binary from disk. In some environments (bundlers, ESM-only projects, certain Node.js configurations), this fails to locate or instantiate the WASM file.
Additionally, the RaptorQ WASM module expects a window global, which the SDK polyfills:
This polyfill can cause side effects with other libraries that check for window to detect browser environments.
What Works in Node.js
Despite the RaptorQ issue, several SDK operations work in Node.js:
- Client creation:
createLumeraClient()connects to RPC and LCD endpoints - Blockchain queries:
client.Blockchain.getAction(),getActionParams(), etc. - Downloads:
client.Cascade.downloader.download()— downloading does not require RaptorQ encoding - Signing:
DirectSecp256k1HdWalletworks for all signing operations
What Does Not Work
- Uploads: The full upload pipeline requires RaptorQ layout generation, which depends on the WASM module
- Specifically,
client.Cascade.uploader.uploadFile()andclient.Cascade.uploader.registerAction()fail at the layout generation step
Workarounds
1. Browser-First Architecture (Recommended)
Build your application as a browser SPA or SSR app where Cascade operations run client-side:
Your Node.js backend handles business logic, databases, and authentication. The browser frontend handles all Cascade interactions directly.
2. Source Code Patching
If you need Node.js uploads (e.g., for a CLI tool or backend service), you can fork @lumera-protocol/sdk-js and patch the WASM loading:
The key file to modify is src/wasm/raptorq-proxy.node.ts. The issue is typically in how the WASM binary path is resolved. Potential fixes:
- Inline the WASM as base64: Convert the
.wasmfile to a base64 string and load it viaWebAssembly.instantiate - Use an absolute path: Replace the
createRequireapproach with a known absolute path to the WASM file - Use the browser WASM loader in Node.js: Force the browser import path which uses standard ESM WASM imports
After patching, build the SDK locally:
3. Use the Go or Rust SDK
For server-side applications, the Go and Rust SDKs have full Node/server compatibility without WASM issues:
Go SDK:
Rust SDK:
4. Download-Only Node.js Service
If your Node.js service only needs to read files from Cascade (not upload), the SDK works without issues:
Current Status
The Lumera team is actively working on improving Node.js compatibility. Track progress at LumeraProtocol/sdk-js.
If you encounter issues or find workarounds, please contribute to the SDK repository or report them on the Lumera Discord.