@vortex-rdf/vortex-rdf-store 0.5.0 → 0.10.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Julian Rojas
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,29 +1,33 @@
 # Vortex-RDF for JavaScript
 [![npm](https://img.shields.io/npm/v/@vortex-rdf/vortex-rdf-store.svg)](https://www.npmjs.com/package/@vortex-rdf/vortex-rdf-store)
 
-JavaScript bindings of  [`vortex-rdf-core`](https://crates.io/crates/vortex-rdf-core) compiled via WebAssembly.
+JavaScript bindings for [Vortex-RDF](https://github.com/vortex-rdf/vortex-rdf), a columnar RDF store format built on Vortex: [`vortex-rdf-core`](https://crates.io/crates/vortex-rdf-core) compiled to WebAssembly, exposed through an RDF/JS-shaped API that builds stores from RDF text or quads, queries them with lazy zero-copy quads, mutates them in place, and round-trips them through `.vortex` bytes.
 
-## Installation
+## Install
 
 ```bash
 npm install @vortex-rdf/vortex-rdf-store
 ```
 
-The package is ESM-only (no CommonJS `require`) and works identically in Node.js and browsers — the same `import` statement resolves to a Node-specific entry point or a browser one depending on where it runs, so there's no environment-specific code to write:
-
-```javascript
-import { VortexRdfStore } from '@vortex-rdf/vortex-rdf-store';
-
-const store = await VortexRdfStore.fromString(ttlData, 'turtle');
-```
-
-Under the hood, a single `wasm-pack --target web` build backs both: the Node entry point reads the `.wasm` file straight off disk (`node:fs`), and the browser entry point uses the standard `fetch`-based loading that bundlers and browsers already understand via `import.meta.url`. Both call the WASM module's async initialization for you, so there's no `init()` to await yourself.
+The package is ESM-only (no CommonJS `require`) and works identically in Node.js and browsers: the same `import` resolves to a Node entry point (reads the `.wasm` file off disk with `node:fs`) or a browser one (`fetch` via `import.meta.url`), and both await the wasm module's initialization.
 
 > **Bundler note:** both entry points use top-level `await`. Vite and Rollup
 > support this by default; webpack 5 needs
 > `experiments: { topLevelAwait: true }` enabled in its config.
 
-## Usage
+## Quick start
+
+```javascript
+import { VortexRdfStore, serializeRdf } from '@vortex-rdf/vortex-rdf-store';
+
+const bytes = await serializeRdf('<http://ex/s> <http://ex/p> "o" .', 'turtle');
+const store = await VortexRdfStore.fromBytes(bytes);
+for await (const quad of store.match(null, 'http://ex/p', null, null)) {
+  console.log(quad.subject.value, quad.object.value);
+}
+```
+
+## Reading quads
 
 ### Loading data
 
@@ -32,30 +36,30 @@ import { VortexRdfStore } from '@vortex-rdf/vortex-rdf-store';
 import { Readable } from 'node:stream';
 import type { Quad, Stream } from '@rdfjs/types';
 
-// From a Turtle/N-Quads/... string
-// Supported formats: `ntriples`, `nquads`, `turtle`, `trig`, `n3`, `rdfxml`, `jsonld` 
+// From RDF text. Formats: `ntriples`, `nquads`, `turtle`, `trig`, `n3`, `rdfxml`, `jsonld`
 // (plus the short aliases `nt`, `nq`, `ttl`, `rdf`, `xml`).
 const store = await VortexRdfStore.fromString(ttlData, 'turtle');
 
-// From RDF-JS quads — an array
+// From RDF/JS quads: an array ...
 const quads: Quad[] = [...];
 const store = await VortexRdfStore.fromQuads(quads);
 
-// Or from any RDF/JS Stream<Quad>
+// ... or any RDF/JS Stream<Quad>
 const quadStream: Stream<Quad> = Readable.from(quads, { objectMode: true });
 const store = await VortexRdfStore.fromQuads(quadStream);
 
-// From Vortex binary data (e.g, fetched from a remote server)
+// From Vortex bytes (e.g., fetched from a server)
 const store = await VortexRdfStore.fromBytes(vortexBytes);
 
-// Or create a new empty store
+// Or start empty
 const store = VortexRdfStore.empty();
 ```
 
+`layout()` and `indexes()` report what a store was built with, as the same kebab-case names `BuildOptions` takes (`store.layout()` is `'dictionary'`; `store.indexes()` is an array such as `['secondary-by-reference']`).
+
 ### Querying
 
-`match` implements the RDF/JS [`Source.match`](https://rdf.js.org/stream-spec/#source-interface) contract. It takes a `(subject, predicate, object, graph)` pattern — pass
-`null`/`undefined` for a variable position — and returns **synchronously** an RDF/JS `Stream<Quad>`:
+`match` implements the RDF/JS [`Source.match`](https://rdf.js.org/stream-spec/#source-interface) contract. It takes a `(subject, predicate, object, graph)` pattern — `null`/`undefined` or an RDF/JS `Variable` for a wildcard position, a bare string for a NamedNode IRI — and returns **synchronously** an RDF/JS `Stream<Quad>`:
 
 ```javascript
 store.match(null, myPredicate, null, null)
@@ -63,7 +67,7 @@ store.match(null, myPredicate, null, null)
   .on('end', () => console.log('done'));
 ```
 
-The returned stream also implements `Symbol.asyncIterator` as a convenience, so it can be consumed with `for await` (in TypeScript, cast to `AsyncIterable<Quad>` since the declared type is `Stream<Quad>`):
+The returned stream also implements `Symbol.asyncIterator`, so it can be consumed with `for await` (in TypeScript, cast to `AsyncIterable<Quad>` since the declared type is `Stream<Quad>`):
 
 ```javascript
 for await (const quad of store.match(null, myPredicate, null, null)) {
@@ -71,26 +75,28 @@ for await (const quad of store.match(null, myPredicate, null, null)) {
 }
 ```
 
-When you just want the matches as an array, `getQuads` is the array-returning counterpart (`async`, because resolving the match crosses the WebAssembly boundary):
+`getQuads` is the array-returning counterpart (synchronous — no read path performs I/O, so there is nothing to await), and `countQuads` answers from the match's row selection without materializing a quad:
 
 ```javascript
-const quads = await store.getQuads(null, myPredicate, null, null);
-console.log(`Found ${quads.length} results`);
+const quads = store.getQuads(null, myPredicate, null, null);
+const n = store.countQuads(null, myPredicate, null, null);
 ```
 
-**Quads are lazy and zero-copy.** `match`/`getQuads` don't build eager term objects — they hand back quads backed by the store's columnar data. A term's string is decoded only when you read `.value`/`.termType`, and then interned, so iterating, counting, filtering, and `.equals` never materialize strings you don't use. Under the default `Dictionary` layout, `.equals` between terms of the same store is an **integer code compare** (no decoding at all). 
+**Quads are lazy and zero-copy.** `match`/`getQuads` hand back quads backed by the store's columnar data. A term's string is decoded only when you read `.value`/`.termType`, and then interned, so iterating, counting, filtering, and `.equals` never materialize strings you don't use. Under the default `dictionary` layout, `.equals` between terms of the same store is an integer code compare (no decoding at all).
 
-The quads implement the RDF/JS `Quad`/`Term` interface (`.subject.value`, `.equals`, …) and interoperate with foreign RDF/JS terms via `.equals` in both directions. (They're lazy views into the producing store, so — unlike a plain data object — don't `structuredClone`
-them or rely on enumerating own properties.)
+The quads implement the RDF/JS `Quad`/`Term` interface (`.subject.value`, `.equals`, …) and interoperate with foreign RDF/JS terms via `.equals` in both directions. They are lazy views into the producing store, so — unlike a plain data object — don't `structuredClone` them or rely on enumerating own properties.
 
-Test membership of a single quad with `has` (an exact four-component lookup):
+Test membership of a single quad with `has` (an exact four-component lookup) and read the quad count with `size`; both return promises:
 
 ```javascript
 if (await store.has(myQuad)) {
   console.log('present');
 }
+console.log(await store.size());
 ```
 
+An invalid pattern term or a malformed quad object throws (or rejects) with an `Error`.
+
 ### Mutation
 
 ```javascript
@@ -99,157 +105,115 @@ await store.addQuads([quadA, quadB]);
 await store.deleteQuad(existingQuad);
 ```
 
-Mutations follow RDF/JS dataset semantics: adding a quad already present is a no-op, and deleting never rewrites the columnar data (rows are tombstoned). 
+Mutations follow RDF/JS dataset semantics: adding a quad already present is a no-op, and deleting never rewrites the columnar data (rows are tombstoned).
 
-Added quads accumulate in a small in-memory tail beside the immutable base, so the store's indexes keep working across edits; when the tail outgrows the base (a tenth of its rows, or 100K rows) the store compacts itself back into one sorted, indexed array. 
+Added quads accumulate in an in-memory tail beside the immutable base, so the store's indexes keep working across edits. When the tail reaches a tenth of the base's rows (never fewer than 4,096) or 100,000 rows, the store compacts itself back into one sorted, indexed array.
 
 Prefer `addQuads` over a loop of `addQuad` calls; for bulk loading, build once with `fromString`/`fromQuads`.
 
-### Serializing
+### RDF text out
 
 ```javascript
-// Back to RDF text, in any supported format
-const turtle = await store.toRdf('turtle');
-
-// To Vortex binary data; read back with VortexRdfStore.fromBytes
-const bytes = await store.toBytes();
+const turtle = await store.toRdf('turtle');   // any supported format name
 ```
 
-### Build options
+## Term codes (low-level)
 
-Ingestion accepts an optional `BuildOptions` object that trades build cost against query speed and size. All fields are optional.
+Under the default `dictionary` layout, terms are stored as `u32` codes into a sorted term dictionary. `termDict()` is the one door to code↔term translation: it returns an immutable `TermDict` handle, or `undefined` when the store's rows aren't code-addressable (a non-dictionary layout, or added quads pending in the in-memory tail):
 
 ```javascript
-const store = await VortexRdfStore.fromString(data, 'nquads', {
-  builder: 'Sorted',                  // 'Unsorted' (default) | 'Sorted'
-  layout: 'Dictionary',               // 'Dictionary' (default) | 'Default' | 'TypedObject'
-  indexes: ['SecondaryByReference'],  // default: []
-});
+const dict = store.termDict();   // TermDict | undefined
+if (dict) {
+  const code = dict.encode('<http://schema.org/name>');  // number | undefined
+  console.log(dict.decode(code));                        // '<http://schema.org/name>'
+}
 ```
 
-**`builder`** — how quads are ordered while building:
-
-| Value | Build cost | Effect on queries |
-| --- | --- | --- |
-| `'Unsorted'` (default) | Cheapest; natural insertion order | Every `match` is a full column scan |
-| `'Sorted'` | Global in-memory sort by subject → predicate → object → graph | Subject lookups use a binary search |
+`decode`/`encode` speak N-Triples term strings — `<iri>`, `_:blank`, `"lit"@lang`, `"lit"^^<dt>`, and `''` for the default graph. The handle is a snapshot: it keeps decoding correctly after the store is mutated, because it retains the dictionary its codes address. It is a wasm-side handle — call `free()` when done (also wired to `Symbol.dispose`, so `using` disposes it automatically).
 
-**`layout`** — how terms are encoded into columns:
+`matchCodes` is its pattern-matching counterpart: it resolves a pattern to the matched rows' raw term codes — four columnar `Uint32Array`s `{ s, p, o, g }` plus a `length` — without materializing any term strings, and returns `null` under the same conditions `termDict()` returns `undefined`:
 
-| Value | Notes |
-| --- | --- |
-| `'Dictionary'` (default) | Terms replaced by codes into a sorted term dictionary. Most compact and fastest to query; backs the integer `.equals` fast path on lazy quads; added quads live in an in-memory string tail until serialized |
-| `'Default'` | All four terms as N-Triples strings |
-| `'TypedObject'` | Object split into kind/value/datatype/language columns |
+```javascript
+const cols = store.matchCodes(null, myPredicate, null, null);
+if (cols) {
+  console.log(cols.length, dict.decode(cols.o[0]));
+}
+```
 
-**`indexes`** 
+`match`/`getQuads` are the supported way to read quads; `matchCodes` is the low-level path for callers that join, count and de-duplicate in code space and decode each distinct term once.
 
-- `'SecondaryByReference'` adds sorted predicate/object columns plus row-id back-references, so predicate-only and object-only patterns use a binary search instead of a full scan. 
-- `'SecondaryByCopy'` embeds two complete extra copies of the quad columns — one sorted by `(p, o, s, g)`, one by `(o, s, p, g)` — giving predicate- and object-bound patterns (including combined predicate+object lookups, resolved in one prefix search) the same sorted access path subjects have, at roughly 2× the storage. Both cost extra space and are only effective alongside `builder: 'Sorted'`.
+## Build options
 
-A good query-optimized configuration is 
+`fromString`, `fromQuads` and `serializeRdf` accept an optional `BuildOptions` object; every field is optional. Quads are always sorted by subject → predicate → object → graph while the columnar array is built — that global order is what gives subject lookups their binary search and what every secondary index routes against. The wasm build sorts in memory (WebAssembly has no filesystem for an out-of-core builder) and takes no builder option.
 
 ```javascript
-{ 
-    builder: 'Sorted', 
-    layout: 'Dictionary', 
-    indexes: ['SecondaryByReference'] 
-};
+const store = await VortexRdfStore.fromString(data, 'nquads', {
+  layout: 'dictionary',                   // 'dictionary' (default) | 'default' | 'typed-object'
+  indexes: ['secondary-by-reference'],    // default: []
+});
 ```
 
+**`layout`** — how terms are encoded into columns. `'dictionary'` is the default in every vortex-rdf frontend (JS, Python and the CLI):
 
-The default `{ builder: 'Unsorted', layout: 'Dictionary' }` already gives compact, code-based lazy reads and is cheap to build.
+| Value | Notes |
+| --- | --- |
+| `'dictionary'` (default) | Terms replaced by codes into a sorted term dictionary. Most compact and fastest to query; backs the integer `.equals` fast path on lazy quads; added quads live in an in-memory string tail until serialized or compacted |
+| `'default'` | All four terms as N-Triples strings |
+| `'typed-object'` | Object split into kind/value/datatype/language columns |
 
-### Helper functions
+**`indexes`** — secondary access paths, each costing extra space:
 
-For one-shot conversions without holding a store:
+| Value | Notes |
+| --- | --- |
+| `'secondary-by-reference'` | Sorted predicate/object columns plus row-id back-references, so predicate-only and object-only patterns use a binary search instead of a full scan |
+| `'secondary-by-copy'` | Two complete extra copies of the quad columns — one sorted by `(p, o, s, g)`, one by `(o, s, p, g)` — giving predicate- and object-bound patterns (including predicate+object prefix lookups) the same sorted access path subjects have |
+
+## Bytes & files
 
 ```javascript
-import { rdf_to_vortex, vortex_to_rdf } from '@vortex-rdf/vortex-rdf-store';
+import { VortexRdfStore, serializeRdf, deserializeRdf } from '@vortex-rdf/vortex-rdf-store';
 
-const bytes = await rdf_to_vortex(turtleText, 'turtle', { builder: 'Sorted' });
-const text  = await vortex_to_rdf(bytes, 'nquads');
+// Store <-> native-container bytes (the `.vortex` file format)
+const bytes = await store.toBytes();
+const again = await VortexRdfStore.fromBytes(bytes);
 
-// N-Quads is just another format
-const bytes2 = await rdf_to_vortex(nquadsText, 'nquads');
-const text2  = await vortex_to_rdf(bytes2, 'nquads');
+// One-shot conversions, without holding a store
+const vortex = await serializeRdf(turtleText, 'turtle', { layout: 'dictionary' });
+const nquads = await deserializeRdf(vortex, 'nquads');
 ```
 
-### TypeScript support
+`toBytes` writes the same exchange format the CLI and the Python bindings read, so a buffer can be written to disk as a `.vortex` file or handed across bindings.
 
-The package ships typings generated from the Rust bindings, using RDF-JS types.
+A `VortexRdfStore` is a wasm-side handle: call `free()` when you are done with it, or declare it with `using` (`free` is wired to `Symbol.dispose`); an unfreed store is reclaimed only when its JS wrapper is garbage-collected.
+
+## TypeScript
+
+The package ships a hand-written `src/api.d.ts` typed against `@rdfjs/types`, embedded into the wasm-pack output; it is the public surface, checked by `npm run typecheck`.
 
 ```typescript
 import { VortexRdfStore, type BuildOptions } from '@vortex-rdf/vortex-rdf-store';
 import { DataFactory } from 'rdf-data-factory';
 
 const df = new DataFactory();
-
-const options: BuildOptions = { builder: 'Sorted', layout: 'Dictionary' };
+const options: BuildOptions = { layout: 'dictionary' };
 const store = await VortexRdfStore.fromString(data, 'nquads', options);
 
-console.log(store.layout()); // 'Dictionary'
-
-const quads = await store.getQuads(null, df.namedNode('http://schema.org/name'), null, null);
-for (const quad of quads) {
+for (const quad of store.getQuads(null, df.namedNode('http://schema.org/name'), null, null)) {
   console.log(quad.subject.value);
 }
 ```
 
-## Building
+## Development
 
-This package is built using [wasm-pack](https://rustwasm.github.io/wasm-pack/), targeting `web` — the same wasm build is shared by both environments:
+The package is built with [wasm-pack](https://rustwasm.github.io/wasm-pack/) targeting `web`; one build (`pkg/web/`) backs both environments. `entry/node.js` and `entry/browser.js` are small hand-written wrappers that differ only in how they supply the `.wasm` bytes to the generated `init()`, and `package.json`'s `exports` map picks one per environment.
 
 ```bash
-# Build the wasm module (writes to pkg/web/)
-npm run build
-
-# Run the test suite (requires a build first)
-npm test
+npm run build       # wasm-pack build into pkg/web/ (build:fast skips wasm-opt)
+npm test            # vitest suite (requires a build)
+npm run typecheck   # tsc over the tests and benchmarks, against the published API
 ```
 
-`entry/node.js` and `entry/browser.js` are small, hand-written wrappers around that single build — they differ only in how they supply the `.wasm` bytes to the generated `init()` (a direct file read vs. the default `fetch`-based path), and `package.json`'s `exports` map picks the right one per environment.
-
-There's no separate Node-targeted wasm build to maintain.
-
-Types are checked separately from the build, since `wasm-pack` doesn't run `tsc`:
-
-```bash
-npm run typecheck   # tests and benchmarks, both against the published API
-```
-
-## Benchmarks
-
-Three surfaces, kept separate because they answer different questions and are trustworthy in different ways. All require `npm run build` first.
-
-| Command | Question | Output |
-| --- | --- | --- |
-| `npm run bench` | How do we compare to other JS RDF stores? | `bench/results.json`, rendered to the dashboard |
-| `npm run bench:codspeed` | Did this PR regress anything? | uploaded to CodSpeed |
-| `npm run bench:dict-memory` | Where is wasm memory actually going? | printed; `bench/dict-memory.json` |
-
-**`npm run bench`** runs each store — the Vortex build variants, [rdf-stores.js](https://github.com/rubensworks/rdf-stores.js), and [oxigraph](https://github.com/oxigraph/oxigraph) — through the same query, mutation, and serialization workload, one adapter per child process so peak RSS is attributable and no store's garbage taints another's timings. It is wall-clock, so it is only as stable as the machine it runs on; it is deliberately **not** uploaded to CodSpeed. `scripts/render_bench_dashboard.py` turns its `results.json` plus a `cargo bench --bench benchmark` run into `public/index.html`.
-
-The dataset is generated by `genDataset` in [bench/shared.ts](bench/shared.ts), with term cardinality as an explicit knob — real RDF has terms scaling with rows, and a generator that draws millions of quads from a handful of IRIs makes every store's term handling invisible. Tunable by env var:
-
-| Var | Default | Meaning |
-| --- | --- | --- |
-| `BENCH_DIM` | 128 | triples dataset is `D³` rows |
-| `BENCH_DIM_QUADS` | 32 | quads dataset is `Dq⁴` rows |
-| `BENCH_SUBJ_RATIO` | 0.1 | distinct subjects / rows — the reciprocal of triples per subject |
-| `BENCH_OBJ_RATIO` | 0.5 | distinct objects / rows |
-| `BENCH_PREDICATES` | 32 | distinct predicates (a closed vocabulary) |
-| `BENCH_GRAPHS` | 1 | distinct named graphs; 1 means default graph only |
-| `BENCH_LITERAL_FRAC` | 0.4 | fraction of objects that are literals |
-| `MUT_BATCH` | 10000 | quads per add/delete batch |
-
-The two ratios decide how much of the dataset is *terms*: the dictionary holds `subjectRatio + objectRatio` of them per quad. At the defaults that is 2,097,152 triples over ~1.26M distinct terms, ten triples describing each subject, and probes spanning five orders of magnitude of selectivity (1 row for a fully-bound pattern, ~10 for a subject, ~3% for a predicate).
-
-`BENCH_SUBJ_RATIO=1.0` gives every row its own subject, which puts more distinct terms in the dictionary than there are rows. That is a useful dictionary-stress configuration — it is what `bench:dict-memory` asks for — but a poor default for the comparison: it makes five of the seven probes match two rows or fewer, so the timings become almost entirely query setup with the decode path barely exercised.
-
-Each adapter process peaks at 3–6 GB — check available memory before running, because a swapping run produces numbers that look like regressions.
-
-**`npm run bench:dict-memory`** is the only instrument that can attribute wasm memory; `peakRssMb` in the comparative run is the right cross-library number but cannot say *what* holds the memory. Wasm linear memory never shrinks, so it works by differentials — several stores held live at once, memory read after each, slope against store count — and every config runs in its own process. It defaults to a single config as a regression check against the figures recorded when FSST landed; passing several `DICT_MEM_RATIOS` sweeps term cardinality instead and fits the per-term cost. The header of [bench/dict-memory.bench.ts](bench/dict-memory.bench.ts) documents the method and the invocations.
+Benchmarks live in [bench/](bench/README.md).
 
 ## License
 

package/entry/browser.js

@@ -9,7 +9,8 @@ await init();
 init_panic_hook();
 
 export {
+    TermDict,
     VortexRdfStore,
-    rdf_to_vortex,
-    vortex_to_rdf,
+    serializeRdf,
+    deserializeRdf,
 } from '../pkg/web/vortex_rdf.js';

package/entry/node.js

@@ -11,7 +11,8 @@ await init({ module_or_path: await readFile(wasmPath) });
 init_panic_hook();
 
 export {
+    TermDict,
     VortexRdfStore,
-    rdf_to_vortex,
-    vortex_to_rdf,
+    serializeRdf,
+    deserializeRdf,
 } from '../pkg/web/vortex_rdf.js';

package/entry/types.d.ts

@@ -0,0 +1,16 @@
+// Types shared by the Node and browser entry points: both expose the same
+// public surface as the generated wasm bindings, minus the low-level
+// `init`/`initSync` (each entry calls init for the caller). Kept in sync with
+// the re-exports in entry/node.js and entry/browser.js.
+export {
+    TermDict,
+    VortexRdfStore,
+    serializeRdf,
+    deserializeRdf,
+} from '../pkg/web/vortex_rdf.js';
+export type {
+    BuildOptions,
+    LayoutStrategy,
+    IndexType,
+    RdfFormatName,
+} from '../pkg/web/vortex_rdf.js';

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@vortex-rdf/vortex-rdf-store",
-    "version": "0.5.0",
+    "version": "0.10.0",
     "description": "High-performance, zero-copy columnar RDF serialization format",
     "type": "module",
     "repository": {
@@ -12,20 +12,27 @@
         "access": "public"
     },
     "main": "./entry/browser.js",
-    "types": "./pkg/web/vortex_rdf.d.ts",
+    "types": "./entry/types.d.ts",
     "exports": {
         ".": {
-            "types": "./pkg/web/vortex_rdf.d.ts",
-            "node": "./entry/node.js",
-            "browser": "./entry/browser.js",
-            "default": "./entry/browser.js"
+            "node": {
+                "types": "./entry/types.d.ts",
+                "default": "./entry/node.js"
+            },
+            "browser": {
+                "types": "./entry/types.d.ts",
+                "default": "./entry/browser.js"
+            },
+            "default": {
+                "types": "./entry/types.d.ts",
+                "default": "./entry/browser.js"
+            }
         }
     },
     "files": [
         "entry/node.js",
-        "entry/node.d.ts",
         "entry/browser.js",
-        "entry/browser.d.ts",
+        "entry/types.d.ts",
         "pkg/web/vortex_rdf.js",
         "pkg/web/vortex_rdf.d.ts",
         "pkg/web/vortex_rdf_bg.wasm",
@@ -35,15 +42,18 @@
     "scripts": {
         "build:wasm": "wasm-pack build --target web --out-dir pkg/web --no-pack",
         "build:wasm:fast": "wasm-pack build --target web --out-dir pkg/web --no-pack --no-opt",
-        "build:clean-manifest": "node -e \"require('fs').rmSync('pkg/web/package.json',{force:true})\"",
-        "build": "npm run build:wasm && npm run build:clean-manifest",
-        "build:fast": "npm run build:wasm:fast && npm run build:clean-manifest",
+        "build:hdt-wasm": "RUSTFLAGS='-C target-feature=+simd128' wasm-pack build bench/hdt-wasm --target web --out-dir ../hdt-pkg --no-pack && npm run build:hdt-clean-generated",
+        "build:hdt-clean-generated": "node -e \"require('fs').rmSync('bench/hdt-pkg/.gitignore',{force:true})\"",
+        "build:reset": "node -e \"require('fs').rmSync('pkg/web',{recursive:true,force:true})\"",
+        "build:clean-generated": "node -e \"const fs=require('fs');for (const f of ['pkg/web/package.json','pkg/web/.gitignore']) fs.rmSync(f,{force:true})\"",
+        "build": "npm run build:reset && npm run build:wasm && npm run build:clean-generated",
+        "build:fast": "npm run build:reset && npm run build:wasm:fast && npm run build:clean-generated",
         "prepublishOnly": "npm run build",
         "test": "vitest run",
-        "typecheck": "tsc -p tsconfig.json --noEmit && tsc -p tsconfig.bench.json",
+        "typecheck": "tsc -p tsconfig.json && tsc -p bench/tsconfig.json",
         "bench": "tsx --expose-gc --max-old-space-size=8192 bench/compare.bench.ts",
         "bench:build": "npm run build && npm run bench",
-        "bench:codspeed": "tsx --expose-gc bench/codspeed.bench.ts",
+        "bench:codspeed": "node --import tsx --expose-gc --no-liftoff bench/codspeed.bench.ts",
         "bench:dict-memory": "tsx --expose-gc bench/dict-memory.bench.ts"
     },
     "keywords": [
@@ -58,12 +68,12 @@
     "license": "MIT",
     "devDependencies": {
         "@codspeed/tinybench-plugin": "^5.7.1",
-        "@types/node": "^26.1.1",
+        "@types/node": "^26.1.2",
         "oxigraph": "^0.5.9",
         "rdf-data-factory": "^2.0.2",
         "rdf-stores": "^2.2.0",
         "tinybench": "^6.1.2",
-        "tsx": "^4.23.1",
+        "tsx": "^4.23.4",
         "typescript": "^7.0.2",
         "vitest": "^4.1.10",
         "wasm-pack": "^0.15.0"