nordisk/holger

holger-znippy-npm-repository — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: znippy-archive-backed npm registry — the subset of the npm HTTP registry API needed to install.
• Does: NpmRepoZnippy implements RepositoryBackendTrait serving GET /{repo}/{pkg} (packument JSON: versions + tarball URLs) and GET /{repo}/{pkg}/-/{file}.tgz (tarball). Backed by a concrete ZnippyArchive it uses the typed npm view (as_npm) so the package name — including the @scope/ prefix the tarball filename drops — and version come from index columns, letting scoped packages resolve by authoritative name. Tarball URLs are built from a configurable ron_base_url (empty → host-relative) so pulls work behind any host/reverse proxy. with_reader fallback for generic readers.
• Key deps: traits, znippy-common, anyhow.
• Shape: lib, single lib.rs. Shared znippy-backend pattern.
• Observed role in the workspace: Registered in server-lib as repository-znippy-npm. Per CLAUDE.md npm is "real protocol", production-adjacent.

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: