Summary
Update @byteslice/result from 0.2.0 to the latest (0.5.0 at time of writing). It's the Result-type primitive used pervasively across our SDKs — withResult(...) and the { data } | { failure } shape underpin every encryption/decryption/query operation — so this is a core, high-blast-radius dependency, not a leaf.
Current state
Pinned in three packages, inconsistently and not via a pnpm catalog:
| Package |
Pin |
packages/stack |
0.2.0 (exact) |
packages/protect |
^0.2.0 |
packages/protect-dynamodb |
^0.2.0 |
Lockfile resolves all to 0.2.0. ~44 source files across stack, protect (+ ffi/identify/stash), protect-dynamodb, migrate, and prisma-next/stack import it.
Why it's not trivial
0.2.0 → 0.5.0 crosses three pre-1.0 minors (0.3.0, 0.4.0, 0.5.0); pre-1.0, a minor bump can be breaking. The upgrade must verify our usage still holds:
withResult(fn, onError) signature and behaviour (sync + async).- The
Result<T, E> shape and the .data / .failure discriminants we read everywhere (e.g. if (result.failure) … / result.data).
- Any rename/removal of exported types or helpers.
Changelog / source: https://github.com/ByteSliceHQ/byteslice/tree/main/packages/result
Tasks
Notes
Low urgency (no known bug or CVE driving it) — this is dependency hygiene. Worth doing in its own PR given the cross-package reach, ideally bundled with the catalog migration above.
Summary
Update
@byteslice/resultfrom0.2.0to the latest (0.5.0at time of writing). It's the Result-type primitive used pervasively across our SDKs —withResult(...)and the{ data } | { failure }shape underpin every encryption/decryption/query operation — so this is a core, high-blast-radius dependency, not a leaf.Current state
Pinned in three packages, inconsistently and not via a pnpm catalog:
packages/stack0.2.0(exact)packages/protect^0.2.0packages/protect-dynamodb^0.2.0Lockfile resolves all to
0.2.0. ~44 source files acrossstack,protect(+ffi/identify/stash),protect-dynamodb,migrate, andprisma-next/stackimport it.Why it's not trivial
0.2.0 → 0.5.0crosses three pre-1.0 minors (0.3.0,0.4.0,0.5.0); pre-1.0, a minor bump can be breaking. The upgrade must verify our usage still holds:withResult(fn, onError)signature and behaviour (sync + async).Result<T, E>shape and the.data/.failurediscriminants we read everywhere (e.g.if (result.failure) …/result.data).Changelog / source: https://github.com/ByteSliceHQ/byteslice/tree/main/packages/result
Tasks
0.3→0.5changelog for breaking changes vs. our usage.^).@byteslice/resultto the pnpmrepocatalog so it's lockstep-managed like the other shared deps (avoids the current per-package drift).pnpm-lock.yaml; run typecheck + the full test suite (Node 22/24, Bun, WASM E2E).Notes
Low urgency (no known bug or CVE driving it) — this is dependency hygiene. Worth doing in its own PR given the cross-package reach, ideally bundled with the catalog migration above.