docmd-search@0.1.0 🚀 (First Test Release)

The first non-alpha release of docmd-search. Bumps from 0.1.0-alpha.1 to 0.1.0, lands on the latest dist-tag, and ships the default exports condition that was missing in the alpha.

🐛 Bug fixes

exports conditions incomplete — require.resolve failed with ERR_PACKAGE_PATH_NOT_EXPORTED

In 0.1.0-alpha.1, the package.json#exports for both . and ./client declared only the import and types conditions. Any tool that used Node's CommonJS resolver — including @docmd/plugin-search's auto-installer, pnpm's hoist layout, and any consumer that built with esbuild's platform: 'node' and format: 'cjs' — hit:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in
.../node_modules/docmd-search/package.json

The 0.1.0 fix adds a "default" condition to both subpaths, mirroring the pattern used by every other official package in the @docmd/* scope:

"exports": {
  ".": {
    "import": "./dist/index.js",
    "types": "./dist/index.d.ts",
    "default": "./dist/index.js"
  },
  "./client": {
    "import": "./dist/client/index.js",
    "types": "./dist/client/index.d.ts",
    "default": "./dist/client/index.js"
  }
}

This unblocks:

• @docmd/plugin-search auto-install when plugins.search.semantic = true (the search plugin's peerDependencies: { "docmd-search": ">=0.1.0" } now resolves cleanly).
• pnpm's strict-mode install, which uses CJS require.resolve under the hood for some pre-flight checks.
• Any CJS consumer that imports docmd-search via require('docmd-search').

Dist-tag no longer stuck on alpha

The 0.1.0-alpha.0 release was published with the default latest tag (npm's behaviour when no --tag is given). The follow-up 0.1.0-alpha.1 was tagged alpha, but latest stayed on the older alpha. The published-CI workflow now uses no --tag flag, so all future releases land on latest by default.

✨ New: docmd namespace in package.json

Carries the package's self-description as a docmd key, following the convention introduced in docmd@0.8.9 for @docmd/plugin-* and @docmd/template-* packages. This is metadata-only — it does not change runtime behaviour, but it lets the docmd monorepo's registry generator (scripts/build-plugin-registry.mjs) catalog this package if you ever wire it into the main build.

"docmd": {
  "key": "docmd-search",
  "kind": "search-engine",
  "displayName": "docmd-search",
  "tagline": "Offline semantic search engine for documentation. Local embeddings, browser-ready indexes."
}

Note: the kind is "search-engine", not "plugin" or "engine". The docmd auto-installer recognises the official scope (@docmd/*) but does not auto-install docmd-search — it has to be pulled in explicitly via the search plugin's peerDependencies because the ML stack (@huggingface/transformers, onnxruntime-node) is opt-in.

🔒 Security

No new attack surface. The export-field fix is a strict superset of the previous behaviour — the default condition is only used when neither import nor require matches, which never happens for ESM consumers. No CVE applies.

📦 Compatibility

Surface	Status
@docmd/plugin-search@>=0.8.5	✓ Works as peer dep (>=0.1.0)
@docmd/engine-js@>=0.8.5	✓ Optional peer, used for chunking/quantization
@docmd/engine-rust@>=0.8.5	✓ Optional peer, accelerated chunking/quantization when present
@huggingface/transformers@^4.2.0	✓ Optional peer, required for the embedding model
onnxruntime-node@^1.26.0	✓ Optional peer, required for the on-device inference backend
Node.js	>=18 (matches the rest of the @docmd/* family)
Browser (search client)	Modern browsers with WebAssembly, Atomics, SharedArrayBuffer (cross-origin isolated)

🧪 Verification

The failsafe.js test suite (12+ assertions across indexing, search, manifest round-trip) passes against the published bundle:

$ npm run verify
…
✓ 12 assertions passed across 4 files

Full Changelog: 0.1.0-alpha.1...0.1.0