Package Registry Overview

Pure provides an npm-compatible package registry at:

https://registry.pure.dev

The registry stores Pure-compiled packages as native .node add-ons and proxies any package not found locally to npmjs.org. From a client perspective it behaves exactly like the official npm registry — use it as a drop-in via .npmrc.

What it stores

Category	Description
Pure-compiled packages	TypeScript and JavaScript packages compiled to native .node modules — produced by pure build --target node-addon and published as installable npm tarballs.
Proxied npm packages	All other packages’ metadata is fetched from npmjs.org on demand and cached; tarball bytes are never stored or re-served by us — see Proxy behaviour below.

The registry does not store source code, and it does not store or re-serve tarball bytes for packages it doesn’t publish itself — only compiled artifacts we actually publish.

When to use it

• npm install from a Pure project — set registry=https://registry.pure.dev in your .npmrc so that Pure-compiled packages are resolved locally and other packages fall through to npmjs. See Configure npm.
• Publishing a package built with Pure — authenticate with a publish token and run npm publish. See Publishing.
• Private packages — the registry supports scoped packages. Packages published to Pure’s registry are private to your organization by default.

Proxy behaviour

When the registry receives a request for a package it does not have locally, it:

1. Fetches the packument (package metadata) from npmjs.org and caches it with a configurable TTL. If the client requests the abbreviated (“install-only”) metadata format npm CLI normally asks for, the response is trimmed to just the install-relevant fields (no readme, maintainers, or publisher history) — substantially smaller than the full document. Responses are gzip-compressed.
2. On tarball requests for a version not published to Pure, the registry does a HEAD-only existence check against npmjs.org (headers only, no body) and then redirects the client (302) straight to npmjs.org — it never downloads or re-serves the tarball bytes itself. Real npm/Bun/pnpm clients follow the redirect and pull the bytes directly from npmjs.org.

If npmjs.org is unreachable when checking a tarball’s existence, or a metadata fetch fails, the registry falls back to the most recently cached metadata (packuments only — tarballs are never cached) and returns a retryable 503 for tarballs rather than a false 404. A package that has never been cached and cannot be reached returns 404.

ETags are used for packument conditional re-validation so upstream metadata bandwidth is minimized. Tarball bytes for proxied (non-Pure) packages never cross Pure’s infrastructure at all.