browser-sqlite 1.0.0-rc.4 → 1.0.0-rc.5

package/dist/worker/probes.d.ts

@@ -0,0 +1,26 @@
+/**
+ * Platform features a worker can probe for itself, synchronously, before it
+ * loads anything. Pure, and tested in Node for the reason `cloneable.ts` is.
+ *
+ * `readwrite-unsafe` cannot be probed from the page: `FileSystemSyncAccessHandle`
+ * is exposed to dedicated workers only, which is why `capabilities.ts` lists
+ * it as unprobeable. A worker can, and without opening a file: the engines that
+ * implement the mode also ship the handle's `mode` ATTRIBUTE. That is not the
+ * trap `capabilities.ts` warns about — WebIDL ignores an unknown DICTIONARY
+ * member, so passing the option proves nothing, but an attribute an engine does
+ * not implement is simply absent from the prototype. Measured 2026-09-13 in a
+ * dedicated worker: Chromium true, Firefox false, Safari false
+ * (spec 2026-09-13, §3.1).
+ */
+import type { PlatformFeature } from '../types';
+/** The globals a probe reads; `globalThis` in a worker, a stub in tests. */
+export type ProbeScope = {
+    FileSystemSyncAccessHandle?: unknown;
+};
+export declare const WORKER_PROBES: Partial<Record<PlatformFeature, (scope: ProbeScope) => boolean>>;
+/**
+ * The first feature of `features` this worker lacks, or null. A feature with
+ * no probe here is never reported missing: declining on something unprobeable
+ * would shrink every pool on every engine.
+ */
+export declare const firstMissing: (features: readonly PlatformFeature[], scope?: ProbeScope) => PlatformFeature | null;

package/dist/worker/sqlite-code.d.ts

@@ -0,0 +1,9 @@
+import type { SQLiteResultCode } from '../sqlite-codes';
+/**
+ * SQLite's result code on a thrown value, or undefined when SQLite did not
+ * raise it (spec 2026-09-14, final review). wa-sqlite raises its own
+ * `SQLiteError(message, code)` for every result code. Anything else carrying a
+ * numeric `code` — a DOMException's legacy code, 18 for SecurityError — is
+ * not SQLite's and must not be published as `sqliteCode`.
+ */
+export declare const sqliteCodeOf: (e: unknown) => SQLiteResultCode | undefined;

package/dist/worker/statement-cache.d.ts

@@ -9,14 +9,28 @@
  */
 /** A `sqlite3_stmt` pointer. Opaque here: the cache only files it. */
 export type StatementHandle = number;
+/**
+ * The two bounds, both active. `maxEntries` answers the churn that generated
+ * SQL produces; `maxBytes` answers the footprint of a `bulkWrite` template,
+ * which is three orders of magnitude heavier than an ordinary statement
+ * (`mem:measurements`).
+ */
+export type StatementCacheBounds = {
+    maxEntries: number;
+    maxBytes: number;
+};
 export type StatementCache = {
     get: (sql: string) => StatementHandle | 'uncacheable' | undefined;
-    /** Returns the handles evicted by this insertion; the caller finalises them. */
-    set: (sql: string, handle: StatementHandle) => StatementHandle[];
+    /**
+     * Returns the handles evicted by this insertion; the caller finalises them.
+     * `weight` is `SQLITE_STMTSTATUS_MEMUSED` and is required on purpose: an
+     * optional one would silently account a statement as free.
+     */
+    set: (sql: string, handle: StatementHandle, weight: number) => StatementHandle[];
     /** Returns the handles evicted by this marking; the caller finalises them. */
     markUncacheable: (sql: string) => StatementHandle[];
     delete: (sql: string) => StatementHandle | undefined;
     /** Empties the cache and returns every live handle, for close. */
     drain: () => StatementHandle[];
 };
-export declare const createStatementCache: (capacity: number) => StatementCache;
+export declare const createStatementCache: ({ maxEntries, maxBytes, }: StatementCacheBounds) => StatementCache;