Sylvain Duchesne
e0d88b5076
Expose a clean scope-based surface so consumers work by scope (public/protected/ private) and never see a physical store id — the library resolves placement and performs the shared-wallet simulation internally. RegistrySession gains optional protected/public store ids, supplied at the single injection point (configureStoreRegistry). Zero domain knowledge. docs/simulation.md updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ng-eventually/client
Two entry points — the data-plane is SDK-identical, the polyfill bootstrap is separate:
| Import | Surface | At migration |
|---|---|---|
@ng-eventually/client |
Same signature as the SDK — ng, useShape, inbox (+ types). Drop-in for @ng-org/web / @ng-org/orm. |
Resolves to the real SDK (build alias removed) — no code change. |
@ng-eventually/client/polyfill |
The only non-SDK surface — configure, setCurrentUser, capability helpers (canRead/canWrite/defaultGrant/grantRead). |
Removed. |
// bootstrap (the only non-SDK call) — inject the REAL SDK
import { configure } from "@ng-eventually/client/polyfill";
configure({ ng: realNg, useShape: realUseShape, sharedWallet, currentUser });
// from here on, pure SDK surface:
import { ng, useShape, inbox } from "@ng-eventually/client";
await ng.doc_create(/* … */);
const set = useShape(MyShape, scope); // filtered to what the user may read
await inbox.post(targetInbox, ref); // deposit (anticipated SDK API)
What the polyfill adds on top of the real SDK (all removed/native at migration):
- Shared-wallet login (one wallet for everyone).
- Capability enforcement — read filter + write guard, on emulated grants attached to documents.
- Anticipated methods (inbox
post, capability ops) with their future-SDK shapes, emulated for now.
Generic: no application domain. The consumer injects shapes and performs the acts of granting access. The client must not contain the global-index curator (a separate package, deferred — see the repo README).