resolveStoreDataDir

resolveStoreDataDir(storePath, backendOverride?, env?): string

Defined in: packages/client/src/store-path.ts:199

Resolve a plain storePath to the PGlite dataDir URL the store opens at — the ONE derivation point (ADR-0036 decision 2, amended by ADR-0049). A browser worker with a proven OPFS sync-access grant resolves to opfs://<storePath>; another browser context (indexedDB present) resolves to idb://<storePath>; Bun/Node resolves to file://<storePath> (relative paths use the working directory). The backendOverride is internal-only: "memory" selects a scheme-selected memory://<storePath> test/ephemeral store.

Rejects a scheme-bearing or empty/whitespace-only path with InvalidStorePathError — the storePath contract fails loudly at the boundary, never silently re-interpreted. The returned URL is internal plumbing; do not surface it to consumers as something to imitate.

CRITICAL (ADR-0036 decision 5, probed on PGlite 0.5.4): memory selection is ALWAYS the scheme-selected memory:// form, NEVER PGlite’s explicit fs: new MemoryFS() option — dumpDataDir from an explicit-fs instance silently omits relation files created after initdb, so a restored clone raises “relation does not exist”. Callers that need a memory store must route through this function, never construct MemoryFS.

ADR-0049 (D1) adds the opfs://<storePath> form: when the placement probe granted a sync-access handle in the executing scope (env.hasOpfsSyncAccess), the browser store lives on opfs-repacked. Precedence: memory override (test/ephemeral) → opfs:// (probe granted) → idb:// (browser, handle denied) → file:// (Bun/Node). opfs:// is TOOLKIT-INTERNAL plumbing — PGlite does NOT accept it as a dataDir; createClientPGlite (plan step 10) interprets it via the opfs-repacked factory + the OPFS namespace builders below. Like every URL resolved here, it never leaks to consumers.

Parameters

storePath

string

backendOverride?

"memory"

env?

StoreEnv = ...

Returns

string