@loradb/lora-wasm 0.14.0 → 0.15.0

package/README.md

@@ -10,11 +10,13 @@ the result.
 
 ## Build
 
+From the repository root:
+
 ```bash
-cd crates/bindings/lora-wasm
-npm install
-npm run build              # wasm-pack (node + bundler) + tsc
-npm test                   # vitest
+corepack enable
+yarn install --immutable
+yarn workspace @loradb/lora-wasm build   # wasm-pack (node + bundler + web) + tsc
+yarn workspace @loradb/lora-wasm test    # vitest
 ```
 
 Build artefacts:
@@ -26,15 +28,21 @@ Build artefacts:
 | `pkg-web/`        | `--target web`      | Browser Worker entry — self-fetches the `.wasm` binary          |
 | `dist/`           | TypeScript (`tsc`)  | Compiled wrapper (`Database`, worker, worker-client, types)     |
 
+The workspace-level `package.json` is the source of truth for the npm
+package name, version, exports, and publish settings. The `pkg-*`
+directories are generated by `wasm-pack`; if their nested manifests look
+stale after a version bump, rebuild with
+`yarn workspace @loradb/lora-wasm build` before testing or packing.
+
 To run the full validation suite (typecheck, vitest, Playwright browser
 test, npm pack dry-run), add:
 
 ```bash
-npm run typecheck
-npm test
-npm run test:browser:install   # one-time chromium download
-npm run test:browser
-npm run pack:dry
+yarn workspace @loradb/lora-wasm typecheck
+yarn workspace @loradb/lora-wasm test
+yarn workspace @loradb/lora-wasm test:browser:install   # one-time chromium download
+yarn workspace @loradb/lora-wasm test:browser
+yarn workspace @loradb/lora-wasm pack:dry
 ```
 
 ## Execution modes
@@ -126,7 +134,7 @@ Use this when you need to control the Worker URL, lifecycle, bundler entry, or
 pooling strategy.
 
 ```ts
-import { createWorkerDatabase } from "lora-wasm/worker-client";
+import { createWorkerDatabase } from "@loradb/lora-wasm/worker-client";
 
 const worker = new Worker(new URL("./worker.js", import.meta.url), {
   type: "module",
@@ -217,11 +225,19 @@ Common ones:
 - `LORA_PARSE` — Cypher syntax could not be parsed
 - `LORA_SEMANTIC` — analysis failure (unknown variable, label, type mismatch, …)
 - `LORA_INVALID_PARAMS` — a parameter value could not be coerced to a `LoraValue`
+- `LORA_READ_ONLY` — mutating statement issued in a read-only context
+- `LORA_NOT_FOUND` — a named entity does not exist
+- `LORA_CONSTRAINT`, `LORA_UNIQUE_CONSTRAINT`, `LORA_NOT_NULL_CONSTRAINT`,
+  `LORA_FOREIGN_KEY`, `LORA_TRANSACTION` — graph constraint or transaction failure
 - `LORA_INVALID_VECTOR` — vector value failed dimension / coordinate-type validation
 - `LORA_TIMEOUT` — query exceeded its cooperative deadline
-- `LORA_IO`, `LORA_SNAPSHOT_CODEC`, `LORA_SNAPSHOT_CRYPTO` — storage / snapshot failures
+- `LORA_DATABASE_NAME` — logical database name violates the portable-path rules
+- `LORA_CONFIG`, `LORA_VALIDATION` — configuration or validation failure
+- `LORA_IO`, `LORA_CONNECTION`, `LORA_WAL_CORRUPTION`, `LORA_WAL_POISONED` — storage failures
+- `LORA_SNAPSHOT_CODEC`, `LORA_SNAPSHOT_CRYPTO` — snapshot codec / crypto failures
 - `LORA_INTERNAL` — last-resort fallback when the engine cannot classify the failure
 - `WORKER_ERROR` — worker transport / lifecycle failure (worker client only)
+- `UNKNOWN` — catch-all for messages without a recognized code
 
 See `ts/types.ts` (`LoraErrorCode`) for the full list.
 
@@ -263,7 +279,7 @@ public surface — consumers can swap backends without rewriting types.
 - The non-blocking worker-backed path is end-to-end verified: a real
   Chromium instance spawns a module Worker, loads the `pkg-web` bundle,
   and runs a CREATE + MATCH round-trip — asserted by a Playwright test
-  behind `npm run test:browser`.
+  behind `yarn workspace @loradb/lora-wasm test:browser`.
 - `vitest` runs 18 in-process tests against the `nodejs` bundle,
   covering scalars, nested maps/lists, nodes, relationships, paths,
   points, all temporal kinds including `date()`/`datetime()` no-arg
@@ -275,15 +291,15 @@ public surface — consumers can swap backends without rewriting types.
   all three wasm bundles plus the compiled TS wrapper. No `file:` deps,
   no postinstall scripts.
 
-**What still blocks a real npm publish**
+**Pre-publish checks**
 
-- Package is marked `private: true` and the workspace is pre-1.0.
-  Publishing needs a final scope decision (e.g. `@lora/wasm`),
-  a LICENSE file, and a repository URL in `Cargo.toml`/`package.json`.
-- The three wasm bundles are each ~2.2 MB. A production publish should
-  either ship conditional exports that load only the bundle the
-  consumer imports, or switch to compressed `.wasm` + `fetch` with
-  `Content-Encoding: br`.
+- Run `yarn workspace @loradb/lora-wasm pack:dry` after every version
+  bump. It regenerates the `pkg-*` outputs, copies the root license, and
+  shows the exact files that would ship to npm.
+- Check the three wasm bundles before release. They are each about
+  2.2 MB today; the package uses conditional exports so consumers import
+  only the target they need, but CDN/browser deployments may still want
+  compressed `.wasm` served with `Content-Encoding: br` or `gzip`.
 - I64 precision is capped at `Number.MAX_SAFE_INTEGER`. For larger
   integer properties we need a `bigint`-aware serializer on the wasm
   boundary.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loradb/lora-wasm",
-  "version": "0.14.0",
+  "version": "0.15.0",
   "description": "WebAssembly bindings for the Lora in-memory graph database",
   "license": "BUSL-1.1",
   "packageManager": "yarn@4.5.1",