chore(nightly): bump @aztec/* to v5.2.0-nightly.20260813

[AztecBot]

Nightly bump

Bumps @aztec/* from v5.2.0-nightly.20260806 → v5.2.0-nightly.20260813.

• Healthcheck / tag run: aztec-packages actions run 31667511812
• Generated by node scripts/update.js (package.json pins, Nargo.toml deps, .aztecrc, yarn.lock, recompiled contracts).

Local verification

Step	Result
yarn format:fix	clean, no changes to amend
yarn build	✅ 7/7 tasks
yarn test	✅ 10/10 tasks, e2e 7 passed (10.2m)

The bump itself is healthy — no migration fixes were required, and no source changes accompany it.

However, the test run above only passes with a local workaround applied outside this repo. See below.

⚠️ Blocker: snappy@7.4.0 breaks aztec start --local-network

Out of the box, yarn test fails in e2e globalSetup:

Error: local-network (cli) exited early with code 1
    at waitForRpc (packages/common/src/testing/local-network.ts:124:13)
    at setupLocalNetworkCli (packages/common/src/testing/local-network.ts:78:5)
    at globalSetup (e2e/fixtures/global-setup.ts:66:21)

The underlying CLI error:

ERROR: cli Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@napi-rs/snappy-wasm32-wasi'
  imported from ~/.aztec/versions/5.2.0-nightly.20260813/node_modules/snappy/index.js

Root cause (upstream packaging bug)

snappy@7.4.0 was published 2026-08-12T13:36Z. Its published index.js is the wasm build, which unconditionally does import * as s from "@napi-rs/snappy-wasm32-wasi" — but 7.4.0 dropped that package from its optionalDependencies, so it is never installed. Every require('snappy') throws.

@aztec/p2p and @aztec/blob-client depend on snappy: "^7.2.2", which floats to 7.4.0. aztec-up installs the CLI bundle without a lockfile, so a fresh install picks up the broken version. (This repo's own yarn.lock pins snappy@7.3.3 and is unaffected.)

The fix exists — but missed this nightly by one commit

aztec-packages#25195 ("fix: pin snappy to 7.2.2") is the correct fix: it pins snappy to an exact 7.2.2 in @aztec/p2p, @aztec/blob-client and @aztec/end-to-end. Pinning the published manifest range is the right lever, since aztec-up does an unlocked npm install.

It has landed on both next and v5-next. But it did not make it into today's v5 nightly:

• Tag v5.2.0-nightly.20260813 points at commit 51a8cd76.
• 51a8cd76 is the first parent of the current v5-next head cae5a73c (merge-train/spartan-v5, #25156), merged at 03:44Z — and that merge is what carried the pin onto v5-next.
• The tag was cut at 04:35Z, but against the pre-merge parent. So the nightly was cut ~51 minutes after the fix reached v5-next, yet from a commit before it.

Verified against the published artifacts, not just the source:

Ref / artifact	snappy range
next head	7.2.2 ✅
v5-next head (cae5a73c)	7.2.2 ✅
tagged commit 51a8cd76	^7.2.2 ❌
published @aztec/p2p@5.2.0-nightly.20260813 tarball	^7.2.2 ❌

So the published 20260813 packages still float to the broken snappy@7.4.0, and a fresh aztec-up install of this version is still broken.

Local workaround used to obtain the green run

Applied to the CLI bundle only — not committed:

# ~/.aztec/versions/5.2.0-nightly.20260813/node_modules/snappy/index.js
module.exports = require('@napi-rs/snappy-linux-x64-gnu')

The native binding loads and round-trips fine; only the wasm fallback path is broken. (Installing the missing @napi-rs/snappy-wasm32-wasi instead does not work — its wasm runtime then fails with this.bridge.setLastError is not a function.)

Recommendation

No change is needed in this repo. Since v5-next already carries the pin, the 20260814 nightly should publish snappy@7.2.2 and be green without any workaround. Suggest holding this PR as draft and letting tomorrow's bump supersede it, rather than merging a version whose CLI cannot start a local network.

---

Created by claudebox · group: aztec-kit-nightly · Slack thread