feat(deps): allow worker 0.8.x for the cf-workers runtime

[alukach]

What I'm changing

Downstream Cloudflare Workers services that depend on multistore couldn't upgrade to the current worker 0.8.5 — the workspace dependency was capped at worker = "0.7.5" (i.e. >=0.7.5, <0.8), so any consumer sharing multistore's dependency tree was held to 0.7.x. The exact-pin era's blocker (worker 0.7.5+ needs wasm-streams 0.5, which conflicted with the old reqwest 0.12) is gone since #114 moved the tree to object_store 0.14 / reqwest 0.13, so there's no longer a reason to cap the major.

How I did it

• Cargo.toml — bumped worker = "0.7.5" → worker = "0.8", letting consumers resolve up to the latest 0.8.x. Rewrote the adjacent comment: it no longer describes a constraint, just records why wasm-streams 0.5 is now satisfiable.
• Cargo.lock — cargo update -p worker resolved worker/worker-macros/worker-sys to 0.8.5 and pulled the matching wasm-bindgen/web-sys/js-sys/wasm-streams updates. No source changes were required in multistore-cf-workers or the example.

Test plan

• cargo check -p multistore-cf-workers --target wasm32-unknown-unknown
• cargo check -p multistore-cf-workers-example --target wasm32-unknown-unknown
• cargo check (native workspace)

🤖 Generated with Claude Code

[claude]

Claude finished @alukach's task in 2m 3s —— View job

---

Reviewing PR #124

• Gather context (PR diff, changed files)
• Review diff for correctness/security/best-practice issues
• Apply ponytail-review lens for over-engineering
• Post final review

---

❌ Changes requested — see findings below.

• examples/cf-workers/wrangler.deploy.toml:6-8 and examples/cf-workers/wrangler.integration.toml:9-11 still pin worker-build --version '^0.7' in their [build] command, but Cargo.toml now resolves worker to 0.8.5. Per the PR's own rationale (worker-build 0.7 can't build against worker 0.8+), this breaks:

  • The CI integration job (.github/workflows/ci.yml:138, npx wrangler dev --config wrangler.integration.toml) — wrangler dev re-runs the config's [build] command regardless of the separate "Build worker" step earlier in the job, reinstalling worker-build 0.7 over the 0.8 that step just installed.
  • Every deploy (preview.yml, staging.yml, production.yml → deploy.yml:72, npx wrangler deploy --config wrangler.deploy.toml), since wrangler deploy also executes the config's [build] command with no separate pre-build step to override it.

  Only examples/cf-workers/wrangler.toml (the local-dev config) was updated; these two configs were missed. Fix:

  [build]
  # worker-build ^0.8 to match worker 0.8.x in Cargo.toml.
  command = "cargo install worker-build --version '^0.8' && worker-build --release"

  applied to both files.

• docs/deployment/cloudflare-workers.md:29-30 has the same stale worker-build ^0.7 snippet — should be updated to ^0.8 alongside the config fix so the docs don't mislead anyone copying the deploy config.

Simplify (ponytail)

Nothing to flag — this is a mechanical dependency bump with no new abstractions or dependencies introduced by hand.

---

💰 Estimated review cost: $0.66 · 2m02s · 22 turns

[alukach]

Addressed the requested change: bumped worker-build ^0.7 → ^0.8 in .github/workflows/ci.yml and examples/cf-workers/wrangler.toml (commit b2f267e), fixing the Unsupported version worker@0.8.5 failure in the Build worker / Preview jobs. Also dropped the stale wasm-streams comment on the worker dep per the non-blocking note.

Retitled chore(deps): → feat(deps):: this widens the published compatibility contract and force-migrates consumers across a worker major (0.8.0 carries breaking #[event] validation + the worker-build out-dir change), so it warrants the 0.6.4 → 0.7.0 minor bump, matching the #114 precedent. A fix:/patch would understate the impact.

[alukach]

Root cause — worker 0.8 is blocked upstream (not just the worker-build pin)

Bumping worker-build to ^0.8 cleared the "Unsupported version" error, but the Build worker step now fails at the wasm link step:

rust-lld: error: duplicate symbol: intounderlyingbytesource_pull
rust-lld: error: duplicate symbol: intounderlyingsink_close
rust-lld: error: duplicate symbol: intounderlyingsource_cancel
... (all from wasm-streams's #[wasm_bindgen] exports)

Why: two wasm-streams majors end up in one wasm binary:

crate	pulls
worker 0.8.5	wasm-streams 0.6
reqwest 0.13.4 (latest, via object_store)	wasm-streams 0.5

Their wasm-bindgen exports (IntoUnderlyingSource/Sink/ByteSource) are not version-namespaced, so two copies collide at link time. On main, worker 0.7.5 and reqwest 0.13.4 both use wasm-streams 0.5, so there is a single copy and it links — the <0.8 bound was load-bearing, keeping worker on the same wasm-streams major as reqwest.

cargo check --target wasm32-unknown-unknown passes because it type-checks but never links — the collision only surfaces in the worker-build/wasm-ld step, which is why this slipped past the initial validation.

No local fix available: [patch] can't bridge the two — wasm-streams 0.6 doesn't satisfy reqwest's ^0.5, and reqwest 0.13.4 is the latest release. worker 0.8 becomes usable only once reqwest adopts wasm-streams 0.6 (then object_store picks it up) — the same wait-on-upstream pattern that #114 resolved for reqwest 0.13.

Recommendation: hold this PR (blocked) or close it until a reqwest release moves to wasm-streams 0.6. Keeping the worker = "0.7.5" bound on main is correct in the meantime.