@paniolo/lasso

npm distribution of the native paniolo-lasso retrieval engine — the qmd-compatible CLI + MCP surface the Paniolo harness drives (search, query, update, embed, gpu, mcp).

The binary is not bundled in this package and is not downloaded at install time. Instead, each platform's binary ships as its own optional dependency (@paniolo/lasso-<platform>-<arch>), and npm installs only the one matching your os/cpu. This is the same model used by esbuild, swc, and Biome: no postinstall network call, works with --ignore-scripts, and is lockfile- and offline-cache friendly.

Usage

npx @paniolo/lasso search "sandbox governance for coding agents" -n 5
npx @paniolo/lasso query "how do agents discover skills" -n 5
npx @paniolo/lasso mcp        # MCP server exposing the `query` tool

The harness resolves this binary automatically via QMD_ENGINE=lasso (see the harness scripts/qmd/binary/resolveLasso.ts); npx usage above is for direct invocation.

Supported platforms

| Package | os | cpu | acceleration | | --- | --- | --- | --- | | @paniolo/lasso-linux-x64 | linux | x64 | CPU | | @paniolo/lasso-linux-arm64 | linux | arm64 | CPU | | @paniolo/lasso-win32-x64 | win32 | x64 | Vulkan GPU (CPU fallback) | | @paniolo/lasso-win32-arm64 | win32 | arm64 | CPU | | @paniolo/lasso-darwin-x64 | darwin | x64 | CPU | | @paniolo/lasso-darwin-arm64 | darwin | arm64 | CPU |

The Windows x64 binary is built with llama.cpp's Vulkan backend, which is vendor-neutral — it offloads to NVIDIA, AMD, and Intel GPUs alike. vulkan-1.dll is a Windows 10/11 system component, and the backend degrades to CPU when no device is found, so the GPU build is safe on GPU-less Windows too. CUDA/Metal lanes are deferred to a later phase.

Publishing (maintainers)

Binaries are produced separately (in CI, or locally — each target needs libclang

• CMake/Ninja + a C++ toolchain; the win32-x64 Vulkan build also needs the Vulkan SDK), then dropped into each platform package and published. The platform binaries are gitignored.

# 1. Bump the unified product version — this updates [workspace.package] version
#    in the repo-root Cargo.toml (every crate inherits it), all npm wrappers +
#    per-platform manifests + optionalDependency pins, and the harness deps:
node npm/scripts/bump-version.mjs --patch    # or --minor/--major/--version x.y.z
node npm/scripts/gen-packages.mjs --check    # verify nothing drifted, no writes
# 2. Build the per-target binaries into <repo>/dist (CPU: --no-default-features;
#    win32-x64: default features = Vulkan). See .github/workflows/release.yml.
# 3. Copy them into the platform packages:
node npm/scripts/stage-binaries.mjs --tool lasso
# 4. Verify host resolution end-to-end (packs + installs into a temp project):
node npm/scripts/pack-smoke.mjs --tool lasso
# 5. Publish each staged platform package, then the wrapper last:
node npm/scripts/publish.mjs --tool lasso    # or --all to publish every product

Always publish the platform packages before the wrapper so the wrapper's optional dependencies resolve on first install. scan, lasso, and wiki-io share one unified version: it lives in [workspace.package] version in the repo-root Cargo.toml, every crate inherits it via version.workspace = true, and gen-packages.mjs propagates it to the npm wrappers, platform packages, and optionalDependency pins. In CI, pushing a v<version> tag runs .github/workflows/release.yml, which builds and publishes all three products at once. The supported-platforms table and the launcher's platform set both derive from tools.mjs, so adding a platform is a one-line edit there plus a regenerate.