Registro npm — Descripción general

En resumen

Pier incluye un registro completo compatible con npm como parte del mismo binario de Rust que ejecuta tus contenedores. Sin contenedor de Verdaccio, sin base de datos adicional — abre https://your-pier-host/registry/npm/, genera un token desde el panel, escribe tres líneas en .npmrc y tendrás un registro privado + proxy que todo el equipo puede usar.

Habla el protocolo HTTP del registro npm de extremo a extremo, así que npm, yarn (1 y 2/3/4), pnpm y bun funcionan todos contra él sin código de cliente a medida.

Qué hace

Publicación privada. npm publish (con y sin scope), npm dist-tag, npm deprecate, npm unpublish. El conjunto completo de mutaciones estándar.
Modo proxy upstream. Replica registry.npmjs.org (o cualquier upstream compatible) — los packuments se almacenan en caché para siempre, los tarballs se descargan de forma diferida en la primera instalación, y el GC con LRU mantiene la caché en disco por debajo de un límite configurable.
Flujo de inicio de sesión web. npm login --auth-type=web abre el navegador, autentica contra el panel de Pier (con 2FA) y deja un token pier_npm_… de larga duración en .npmrc — sin copiar y pegar manualmente.
Descargas en streaming. Los tarballs se sirven mediante axum::Body::from_stream — Pier no almacena en memoria un tarball de 200 MiB.
Limitación de tasa por ruta. Las lecturas públicas, las mutaciones de administrador y npm publish tienen cada una su propio presupuesto por IP.

Para quién es

El registro de Pier encaja si:

Quieres una alternativa autohospedada a Verdaccio sin el contenedor y la base de datos adicionales.
Tienes un equipo pequeño que quiere una sola URL de .npmrc tanto para paquetes privados como para dependencias públicas.
Necesitas que las instalaciones sigan funcionando cuando npmjs.org esté caído.
Quieres visibilidad de auditoría — ver qué paquetes públicos usa realmente tu equipo.
Ya ejecutas Pier para contenedores y no quieres operar un segundo demonio.

Qué no está en la v1

npm search — aún no hay endpoint /-/v1/search. El descubrimiento se hace a través de la interfaz de Pier.
npm owner / RBAC — modelo de propietario único por ahora: quien publica una versión controla deprecate / unpublish para esa versión, con anulación por parte del administrador. La propiedad con múltiples mantenedores llegará más adelante.
npm audit — la forma natural de implementarlo es después del trabajo de proxy upstream, para que las cargas de auditoría puedan pasarse a npmjs.org. Ambos están en la hoja de ruta.
npm star/unstar — explícitamente no planeado. La interfaz expone un conmutador de “fijar” para la pestaña Réplica (Mirror), que resuelve el mismo problema mejor.

Todo lo demás del CLI estándar de npm funciona contra Pier hoy.

Arquitectura de un vistazo

npm install left-pad ─┬─► GET /registry/npm/left-pad
                       │      (packument, ETag-cached)
                       │
                       └─► GET /registry/npm/left-pad/-/left-pad-1.3.0.tgz
                              ↓ first time: upstream fetch + cache
                              ↓ next time: stream from local FS

Los metadatos del packument viven en SQLite (npm_packages para el blob JSON crudo, npm_versions para las versiones descargadas).
Los tarballs viven en el sistema de archivos local en data/registry/{package}/{file}.tgz. Opcionalmente replicados a cualquier nivel de almacenamiento en frío compatible con S3 (Packages → S3 configure).
Revalidación de ETag mediante If-None-Match → cortocircuito 304. La actualización basada en TTL refresca automáticamente las entradas obsoletas.

Próximos pasos

Habilita el registro y configura tu primer cliente — 5 minutos.
Activa el modo proxy upstream para que el equipo replique npmjs.org.
Elige tu guía de cliente: npm · yarn 1.x · yarn 2/3/4 · pnpm · bun.

Relacionado

Página de la funcionalidad: Registro npm autohospedado — para el resumen ejecutivo.
Publicar paquetes privados — con scope vs. sin scope, integridad, errores comunes.
Integración con CI — fragmentos para GitHub Actions, GitLab CI.