feat(stack): make the wasm-inline entry EQL v3 (#614)#639
Conversation
`@cipherstash/stack/wasm-inline` created a client pinned to the FFI's EQL v2 wire format, so v3 schemas failed every encrypt on the edge (Deno / Bun / Cloudflare Workers / Supabase Edge). Make the entry EQL v3: - construct the WASM client with `eqlVersion: 3` - re-export the v3 authoring surface (`types`, `encryptedTable`, the column classes, `buildEncryptConfig`, inference helpers) so an Edge Function authors and runs v3 from one import - accept only v3 tables; reject a v2 table with a clear error The v2 WASM path was never announced, documented, or used; EQL v2 remains fully supported on the native `@cipherstash/stack` entry. Closes #614
🦋 Changeset detectedLatest commit: a0f3b2c The changes in this PR will be included in the next version bump. This PR includes changesets to release 9 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Updates the @cipherstash/stack/wasm-inline entry point (edge/WASM runtimes) to consistently operate on EQL v3, aligning it with the rest of the SDK’s v3 surface and preventing edge runtime encryption failures against eql_v3_* domains.
Changes:
- Pin the WASM client construction to
eqlVersion: 3and reject non-v3 tables up-front with a clear runtime error. - Re-export the EQL v3 schema authoring surface (
types,encryptedTable, column classes, helpers) from/wasm-inline, and stop exporting the v2 builders from this entry. - Add/adjust unit + Deno E2E coverage to lock in v3 behavior (construction options, cast_as normalization, runtime guard, and export surface).
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| packages/stack/src/wasm-inline.ts | Switch /wasm-inline to EQL v3-only: re-export v3 DSL, enforce v3 schemas, and construct WASM client with eqlVersion: 3. |
| packages/stack/tests/wasm-inline-v3.test.ts | New tests asserting v3 pinning, cast normalization, v2-table rejection, and v3 surface re-exports. |
| packages/stack/tests/wasm-inline-new-client.test.ts | Update existing unit test fixtures to use v3 types.TextSearch authoring. |
| e2e/wasm/roundtrip.test.ts | Update Deno WASM smoke test to author a v3 schema and prove v3 round-trip behavior. |
| .changeset/eql-v3-wasm-inline.md | Changeset documenting the v3-only shift for /wasm-inline and the removal of v2 builders from that entry. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Targets the 1.0 candidate
feat/eql-v3-text-search-schema. (Built on the #636 branch, which merged into this base; the diff here is just the wasm-inline change.)Closes #614.
Problem
@cipherstash/stack/wasm-inline(the Deno / Bun / Cloudflare Workers / Supabase Edge entry) constructed its WASM client without aneqlVersion, so it stayed pinned to the FFI's EQL v2 wire format. A v3 schema (concreteeql_v3_*domains) then failed every encrypt on the edge — v3 was unusable there, even though every other entry point offers the v3 surface.The original issue framed this as "wasm-inline doesn't export the v3 schema surface" and asked for a decision on export shape (namespace / new subpath / renamed exports). That framing was a red herring: schema authoring (
types/encryptedTable) is runtime-agnostic and already edge-safe on@cipherstash/stack/eql/v3. The only real defect was the client being hard-wired to v2.Change
@cipherstash/stack/wasm-inlineis now EQL v3 — a single edge entry:Encryptionfactory constructs the WASM client witheqlVersion: 3.types,encryptedTable, the column classes,buildEncryptConfig, the inference helpers) — the same API as@cipherstash/stack/eql/v3— so an Edge Function authors and runs v3 from one import.schemasaccepts only v3 tables; a v2 table throws a clearEQL v3 onlyerror before any FFI crossing.The v2 schema builders (
encryptedColumn/encryptedField/ the v2encryptedTable) are no longer exported from this entry. The WASM path was never announced, documented, or used for v2 — EQL v2 remains fully supported on the native@cipherstash/stackentry, which stays dual (v2 + v3).Verification
dist/wasm-inline.jsbundles the v3 authoring surface directly (no external resolution needed on the edge).wasm-inline-v3.test.tspins: the factory constructs witheqlVersion: 3;cast_asis normalised (SDKstring→ EQLtext); a v2 table is rejected beforenewClient; the v3 surface is re-exported.@cipherstash/stacksuite passes (only the live-Postgres test is skipped/fails without a DB).e2e/wasm/roundtrip.test.ts) now round-trips atypes.TextSearchcolumn via/wasm-inline— the authoritative proof that the edge emits v3. It runs in CI withCS_*secrets and confirms no FFI permission is used (WASM-only).Changeset
@cipherstash/stack: minor. Removing the v2 builders is technically a breaking export change, but amajorchangeset on this 0.x package would force a1.0.0release; the WASM v2 surface was never public, sominorreflects the actual (zero) user impact. The changeset body is explicit that v2 builders are gone and a v2 table now throws.