feat(wasm-split): port Symbolicator wasm-split

[d2anamaria]

Summary

Ports Symbolicator's wasm-split into the CLI as sentry wasm-split.

Same flags, same behaviour, same stdout (lowercase hex build id). Drop-in for the Rust binary. Nothing removed from Symbolicator.

Notes

Validation matches wasmbin, not a full wasm engine.

We validate the module envelope (header, section ids, and section order), but we do not read or validate the contents inside each section. Those bytes are passed through unchanged. This matches Symbolicator's Rust wasm-split.

We intentionally do not use WebAssembly.validate, since it performs deeper checks than wasmbin and would reject inputs the Rust tool accepts.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cli	Ready	Preview	Sep 16, 2026 2:35pm UTC

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Sep 16, 2026 2:35pm UTC

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4289633. Configure here.}

[loewenheim]

Seems solid apart from the manual UUID parsing stuff.

[loewenheim]

All the UUID stuff should probably be handled by the uuid7 library, which is already a dependency.

[BYK]

Strong yes

[loewenheim]

IMO this is the only worthwhile function left in this file, and it could go in binary.ts. The rest are just converting between UUIDs, bytes, and strings.

I think the UUID type should be used wherever possible, including in the output of this function, and only be converted to a string or bytes when it needs to be written somewhere.

[d2anamaria]

I'd keep the wrappers: each handles a different concern in one place, uuidToBytes turns parse failures into CLI errors, and UUID on the read path is wrong because build_id is arbitrary bytes. The other cmd i'm working on will reuse the same helpers when it reads and stamps ids.

[sentry]

Bug: The check if (buildId) incorrectly evaluates to true for an empty Uint8Array, causing the tool to accept an empty build ID instead of generating a new one.
_{Severity: MEDIUM}

Suggested Fix

Change the condition if (buildId) to if (buildId !== null) to correctly distinguish between a null value (no section found) and an empty Uint8Array (empty section found). This ensures that an empty but present build ID section will still trigger the generation of a new build ID.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: packages/cli/src/lib/wasm/build-id.ts#L74

Potential issue: In `buildIdFromSections`, the check `if (buildId)` is used to determine
if a build ID was found. However, if a WebAssembly module's `build_id` section contains
a zero-length vector, `decodeBuildId` returns an empty `Uint8Array`. In JavaScript, an
empty `Uint8Array` is an object and therefore truthy, causing the check to pass. This
prevents the subsequent logic in `splitWasm` from generating a new random build ID when
one is missing, as the empty array is not `null`. As a result, the tool outputs an empty
string for the build ID, which can break downstream processes like symbolication.