It cost more than it saved. Two problems, the second only visible once quantus/common tried to consume this package: Its index re-exports packageDetect, whose only job is a side effect registering with @polkadot/util — a peer dependency inherited for nothing. Deep imports (/base64, /fflate) avoided that. But it is a workspace package, so a symlinked consumer resolves its dependencies through *this* repo's node_modules, where @polkadot/wasm-util points at the package source rather than its build and carries no exports map. Node follows symlinks to their realpath, so `@polkadot/wasm-util/base64` failed to resolve from quantus/common no matter which yarn protocol was used — portal: and link: behave the same once the realpath is taken. So: fflate directly for zlib inflate, and fifteen lines for base64 rather than a dependency at all. Deliberately not atob or Buffer.from — the first is browser-only, the second node-only, and this runs in an MV3 service worker, a Worker, node tests and a bundled extension page. The package is now self-contained apart from fflate, which resolves normally from any checkout. Size is unchanged at 234,292 raw / 109,649 zlib / 146,200 base64. Refs quantus/wasm#1, quantus/common#2 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012uDUodEcRbBwNRi3UCmw8f
@polkadot/wasm
Various WASM wrappers around Rust crates
overview
It is split up into a number of internal packages, namely utilities -
- wasm-crypto Various hashing functions, sr25519 & ed25519 crypto
These are split from the polkadot-js/util repo where it is heavily used as part of @polkadot/util-crypto. (There JS fallbacks are available for some interfaces, e.g. hashing, but for sr25519 WASM is the only interface). Since these don't undergo massive changes on a daily basis and has a build overhead (WASM compilation & optimisation), it is better managed as a seperate repo with a specific CI configuration.
development
Contributions are welcome!
To start off, this repo (along with others in the @polkadot family) uses yarn workspaces to organise the code. As such, after cloning, its dependencies should be installed via yarn, not via npm; the latter will result in broken dependencies.