Follow-up from the portable-encryptedSupabase design (#708). Blocked on the clientKey question — see #804. Do not start this one until that is answered "yes, clientKey is browser-safe".
Why the condition was cut
browser was in the design's proposed export map and was deliberately removed before shipping. It sorts first, so it wins over import/require for anyone whose tooling sets it — and two very ordinary Node setups do:
jest-environment-jsdom sets customExportConditions: ['browser']- Vite client builds set it
So a working Node customer who happens to run a jsdom test suite would silently start resolving the WASM build. That is a regression bought for a target that is both unclaimed and, per the clientKey finding, unreachable.
The typeof document !== 'undefined' refusal of config.accessKey in makeClient was dropped with it. The guard is not unsound — typeof document is the right probe for Workers/Deno/SSR — it simply had no legitimate firing site left once browser was gone. It comes back with the condition, not before it.
Checklist when it lands
- Add a
"browser" branch to the export map, ahead of workerd.
- Add
browser to NON_NODE_RUNTIMES in package-exports.test.ts.
- Reinstate the
typeof document !== 'undefined' / config.accessKey refusal in makeClient — and give it a remedy that is not "pass a native client", because fromWasmEncryptionClient cannot adapt one.
- Add browser to the runtime lists in the skill, README,
AGENTS.md and the changeset.
- Replace the "Browser is not supported" paragraphs with the OIDC-federation instruction, and narrow the design spec's warning to name only
accessKey.
- Add the live browser smoke test — a headless-browser harness that loads the bundle and proves the import graph resolves and the WASM blob instantiates. The series already proves the import graph four ways under Node/Deno; this adds the browser engine to CI to prove the fifth.
This is a breaking change
Reintroducing browser is what makes the export-map change breaking for jsdom and Vite-client consumers — so this PR takes the feat(stack-supabase)!: marker and a major changeset that the current, browser-less map correctly does not need.
Guard that must not regress
The series ships a grep asserting no positive browser claim exists in any shipping artifact. It will fail — correctly — when this work lands. Update it rather than deleting it.
Follow-up from the portable-
encryptedSupabasedesign (#708). Blocked on theclientKeyquestion — see #804. Do not start this one until that is answered "yes,clientKeyis browser-safe".Why the condition was cut
browserwas in the design's proposed export map and was deliberately removed before shipping. It sorts first, so it wins overimport/requirefor anyone whose tooling sets it — and two very ordinary Node setups do:jest-environment-jsdomsetscustomExportConditions: ['browser']So a working Node customer who happens to run a jsdom test suite would silently start resolving the WASM build. That is a regression bought for a target that is both unclaimed and, per the
clientKeyfinding, unreachable.The
typeof document !== 'undefined'refusal ofconfig.accessKeyinmakeClientwas dropped with it. The guard is not unsound —typeof documentis the right probe for Workers/Deno/SSR — it simply had no legitimate firing site left oncebrowserwas gone. It comes back with the condition, not before it.Checklist when it lands
"browser"branch to the export map, ahead ofworkerd.browsertoNON_NODE_RUNTIMESinpackage-exports.test.ts.typeof document !== 'undefined'/config.accessKeyrefusal inmakeClient— and give it a remedy that is not "pass a native client", becausefromWasmEncryptionClientcannot adapt one.AGENTS.mdand the changeset.accessKey.This is a breaking change
Reintroducing
browseris what makes the export-map change breaking for jsdom and Vite-client consumers — so this PR takes thefeat(stack-supabase)!:marker and a major changeset that the current,browser-less map correctly does not need.Guard that must not regress
The series ships a grep asserting no positive browser claim exists in any shipping artifact. It will fail — correctly — when this work lands. Update it rather than deleting it.