motely-wasm 6.1.0 → 7.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (6) hide show
  1. package/README.md +6 -71
  2. package/index.mjs +64 -16
  3. package/jaml.schema.json +1 -1
  4. package/package.json +2 -2
  5. package/test.mjs +23 -0
  6. package/types/bindings.g.d.ts +321 -6
package/README.md CHANGED
@@ -1,76 +1,11 @@
1
- # Motely browser WASM (`motely-wasm` / `motely-wasm-compat`)
1
+ # motely-wasm (NativeAOT-LLVM + Bootsharp)
2
2
 
3
- ## What Bootsharp actually does
3
+ This project compiles Motely to **browser WASM** with **Bootsharp** interop. The embeddable API is **`MotelyWasmHost`** (not a CLI): JavaScript imports it, calls `getVersion()`, `loadJaml`, `startSequentialSearch`, `startSequentialSearchBySearchIndex`, etc., and receives progress/results via **`SearchEvents`**.
4
4
 
5
- **`dotnet publish Motely.BrowserWasm`** is the **entire** build. [Bootsharp](https://github.com/korif/Bootsharp) emits the **complete** npm package: `index.mjs`, WASM, TypeScript typings, and the JS interop glue. You are **not** hand-assembling an npm package.
5
+ The **`Program`** class here is only the **runtime bootstrap** (`Main` → `RunBootsharp()`). Do not confuse it with `Motely.CLI`.
6
6
 
7
- After publish, you get **two** npm-ready folders: `Motely.BrowserWasm/motely-wasm/` (canonical name) and `Motely.BrowserWasm/motely-wasm-compat/` (same WASM bits and `exports`; alternate package name for consumers). Both are **real** packages you can `npm pack`, depend on with `"file:…"`, or publish to the registry.
7
+ After `dotnet publish` on this project, the npm package is emitted under `motely-wasm/` (and `motely-wasm-compat/` is built by the csproj target).
8
8
 
9
- The only extra step in this repo is **MSBuild**: it copies `Motely/package.json`, `jaml.schema.json`, README metadata, and Monaco assets **on top of** Bootsharp’s output so `name`, `description`, `exports`, and shipped files match what you want on npm. **Version** comes from `$(MotelyVersion)` in `Directory.Packages.props` via the project `Version` property — not from editing `package.json` by hand for every release.
9
+ **Breaking change (vs older builds):** the exported host type was renamed from `MotelyProgram` to `MotelyWasmHost`.
10
10
 
11
- ### JavaScript: default export = boot API, flat named exports for the generated API
12
-
13
- The browser-first package is emitted as a real npm module and can be consumed from browsers, workers, Node, Bun, or Deno. Use it like this:
14
-
15
- ```js
16
- import bootsharp, {
17
- MotelyProgram,
18
- SearchEvents,
19
- MotelyDeck,
20
- MotelyStake,
21
- } from "motely-wasm";
22
-
23
- await bootsharp.boot();
24
-
25
- const ver = MotelyProgram.getVersion();
26
- ```
27
-
28
- Types are under `motely-wasm/types/`; the generated API is exported directly as named exports such as `MotelyProgram`, `SearchEvents`, `MotelyDeck`, and `MotelyStake`.
29
-
30
- ---
31
-
32
- ## Commands (from repo root `MotelyJAML`)
33
-
34
- ### Default package
35
-
36
- ```powershell
37
- dotnet publish Motely.BrowserWasm -c Release
38
- ```
39
-
40
- Output: **`Motely.BrowserWasm/motely-wasm/`**. With embedded binaries enabled, this is the low-friction package shape for browser and bundler consumers.
41
-
42
- ### Parallelism: Web Workers (not pthread WASM)
43
-
44
- This project does **not** ship or promise a pthread / multi-threaded Emscripten WASM build. Combining **.NET WASM + NativeAOT-LLVM + pthreads** is a separate, poorly documented matrix; there is no reproducible “proof script” checked in here that threaded AOT-LLVM WASM is a supported combination—so we do not bet the browser story on it.
45
-
46
- **What we actually use:** scale in the browser by spawning **Web Workers**, importing `motely-wasm` in each worker, and calling `bootsharp.boot()` once per worker. Workers are a normal, well-defined browser API; each worker is its own isolate—no `motely-wasm-mt` package, no COOP/COEP requirement for that pattern.
47
-
48
- **Proof:** after `dotnet publish`, run **`Motely.TestWebsite`** (or your app) locally and confirm behavior. Treat any WASM path as “works on my machine / CI” until you’ve verified it for your SDK and host.
49
-
50
- ### Optional: `npm pack` / `npm publish`
51
-
52
- Tarball verification or registry publish still use the **npm CLI** on the publishing machine or in CI:
53
-
54
- ```powershell
55
- cd Motely.BrowserWasm/motely-wasm
56
- npm pack --dry-run
57
- cd ../motely-wasm-compat
58
- npm pack --dry-run
59
- ```
60
-
61
- From repo root, **`Build-Release.ps1`** does the full pipeline (solution build, schema, jaml-language, `dotnet publish`, optional npm). **`publish.ps1`** is a shortcut for `Build-Release.ps1 -Npm Publish` (use `-DryRun` on `publish.ps1` for `npm pack --dry-run`).
62
-
63
- ---
64
-
65
- ## Test website (`Motely.TestWebsite`)
66
-
67
- Vite harness that loads **`motely-wasm`** on `/` and **`motely-wasm-compat`** on `/compat.html` (separate pages so each bundle calls `bootsharp.boot()` once).
68
-
69
- ```powershell
70
- dotnet publish Motely.BrowserWasm -c Release
71
- cd Motely.TestWebsite
72
- npm install
73
- npm run dev
74
- ```
75
-
76
- Production static output: `npm run build` → `dist/`. Deploy with any static host; ensure `*.wasm` is served with `application/wasm` (Vite preview/dev handles this for local QA).
11
+ **Sequential batch size:** `batchCharCount` applies only to **sequential** search (`startSequentialSearch*`, and `startConfiguredSearch` when the JAML has **no** `aesthetics`). Keyword/random/aesthetic/seed-list modes are **provider** searches and do **not** take `batchCharCount` (the engine uses fixed vector-width batches).