Español

jpm

Un gestor de paquetes para JavaScript rápido, pequeño y seguro por defecto

curl -fsSL https://getjpm.sh | sh

EmpezarGitHub

Cada línea escrita por Claude Code. Dirigido por un solo ingeniero. Verificado con las pruebas de todos los demás.

  • ~2 MBun binario, sin runtime que instalar
  • 1.22 sinstalación en frío de nuxt en GitHub CI
  • 34 MBde memoria para instalar nuxt en GitHub CI

Velocidad

Rápido donde tu CI pasa el tiempo

Tres proyectos reales, cuatro fases de instalación, ocho gestores de paquetes, contra el registro de npm en vivo. En GitHub CI, jpm es el más rápido en 9 de 12 casos; los otros tres se muestran tal como se midieron.

Máquina
Fase
Proyecto

Sin caché, sin lockfile, sin node_modules.

Tiempo real de instalación; más corto es más rápidoGitHub CI, Linux · nuxt · 591 paquetes
GitHub CI, Linux, fría, nuxt · 591 paquetes
Gestor de paquetesTiempo real
jpm1.22 s
bun 1.4.21.28 s
pnpm 12.8.11.72 s
aube 2.6.03.00 s
upm 1.3.13.52 s
deno 2.9.67.64 s
yarn 4.18.19.63 s
npm 12.1.018.54 s

jpm es el más rápido aquí, 15× más rápido que npm.

Tiempo real, medianas: ubuntu-latest con 4 núcleos (5 ejecuciones) y Windows 11 con Defender activado (3 ejecuciones), 2026-09-30. Tablas completas, con tiempo de CPU, en docs/benchmarks.md.

Empezar

Cámbiate con un solo comando

Ejecuta jpm install en tu proyecto. jpm importa tu lockfile actual a su propio jpm.lock, con las mismas versiones.

  • package-lock.json y npm-shrinkwrap.json (npm 7+), pnpm-lock.yaml (pnpm 9+) y bun.lock se trasladan tal cual: las mismas versiones y el mismo árbol, sin consultar el registro.
  • yarn.lock, de yarn 1 o de yarn 2 en adelante, conserva todas las versiones que eligió yarn. jpm solo consulta al registro lo que yarn.lock no guarda: peers, plataformas y bins.
  • Tu lockfile anterior queda intacto. Bórralo cuando estés listo.
  • CI sigue funcionando durante el cambio: jpm ci y jpm install --frozen-lockfile instalan desde el lockfile anterior tal cual hasta que se haga commit de jpm.lock.
  • También lee workspaces, pnpm-workspace.yaml, catálogos, overrides y resolutions, y parches.

Formatos antiguos, lockfiles desactualizados y lo demás: docs/migrating.md.

$ cd your-project
$ jpm install   # lee package-lock.json / pnpm-lock.yaml / yarn.lock / bun.lock → escribe jpm.lock

Ligero

Tan pequeño que olvidarás que está ahí

Un binario sin nada detrás, una instalación que ocupa poca memoria y un almacén que guarda cada archivo una sola vez.

No todas las cifras favorecen a jpm: npm y yarn guardan tarballs comprimidos, así que sus cachés son más pequeñas. jpm guarda sus archivos descomprimidos, listos para enlazar.

GitHub CI, Linux, 2026-09-30. Los tamaños de los binarios son las cifras redondeadas del README.

Tamaño del binario, aproximado
Tamaño del binario, aproximado
jpm~2 MB
pnpm~60 MB
bun~80 MB
aube~150 MB
Memoria máxima, instalación ci de nuxt
Memoria máxima, instalación ci de nuxt
jpm34 MB
bun89 MB
pnpm184 MB
npm387 MB
Disco tras una instalación en frío de nuxt, node_modules y almacén
Disco tras una instalación en frío de nuxt, node_modules y almacén
jpm244 MB
bun261 MB
pnpm290 MB
npm443 MB
Caché de CI tras una instalación en frío de next
Caché de CI tras una instalación en frío de next
npm194 MB
yarn328 MB
jpm347 MB
pnpm433 MB
bun466 MB

Almacenamiento

Cada archivo se guarda una vez. Cada paquete se construye una vez.

jpm mantiene un almacén por máquina y construye el directorio de cada paquete una sola vez, para todos los proyectos que lo usan. Volver a instalar consiste sobre todo en crear enlaces.

  1. Un almacén direccionado por contenido

    Cada tarball se verifica contra su integridad y se descomprime una sola vez en ~/.jpm/store. Cada archivo se guarda una vez, por su hash, en solo lectura.

  2. Un almacén virtual global

    Cada paquete se construye una vez como una entrada: name@version, más un breve resumen de su grafo de dependencias cuando las tiene. Sus archivos son enlaces duros desde el almacén y sus dependencias se enlazan a su lado, así que solo puede importar lo que declaró.

  3. Tu node_modules

    El node_modules de un proyecto enlaza a esas entradas. Una instalación en caliente solo crea esos pocos enlaces: 4 ms para nitro en GitHub CI.

  4. Todos los demás proyectos

    El siguiente proyecto de la máquina enlaza a las mismas entradas. Si nada ha cambiado, una instalación repetida comprueba unos pocos enlaces y termina en 1–2 ms.

~/.jpm/storearchivos, por hash3fa19c07e4b271d80b5ec6a3enlaces duros~/.jpm/store/v1/linksentradas, construidas una vez[email protected]node_modules/debugnode_modules/ms[email protected]node_modules/msapp-one/app-two/node_modules/debugnode_modules/debugenlaces

Next.js y Nuxt: dentro del proyecto

Turbopack de Next no compila nada fuera del proyecto, y Nuxt importa paquetes que no declara. Para un proyecto que depende de next o nuxt, jpm construye las entradas en node_modules/.jpm, igualmente con enlaces duros desde el almacén.

node_modules/next -> .jpm/[email protected]…/node_modules/next
node_modules/.jpm/[email protected]…/node_modules/next/
node_modules/.jpm/[email protected]/node_modules/react/

La explicación completa: docs/how-it-works.md.

Seguridad

Seguro por defecto

La opción segura es la que obtienes sin pedirla. Relajar alguna es decisión tuya, tomada en tu propia configuración, no en la de un paquete ni en la de un repositorio clonado.

  • Los scripts de instalación te esperan

    Los scripts de instalación de una dependencia, la vía por la que se ejecuta la mayoría del malware de npm, no se ejecutan hasta que apruebas ese paquete y esa versión con jpm approve. Una versión nueva vuelve a esperar aprobación.

  • Las versiones nuevas esperan un día

    Una versión publicada en el último día no se elige (min-release-age), aunque un paquete en lo más profundo del árbol la fije con exactitud, así que una versión secuestrada no puede colarse a través de una versión fijada.

  • Sin orígenes inesperados

    Un paquete publicado no puede traer dependencias de git o de tarballs, ni rutas fuera de sí mismo. Solo tu proyecto y sus workspaces deciden de dónde viene el código.

  • Verificado antes de ser visible

    Cada paquete se verifica contra la integridad de su lockfile antes de que cualquiera de sus archivos sea visible para tu proyecto.

  • Sin secretos en el lockfile

    Las credenciales nunca acaban en jpm.lock: los tokens se quedan en tu .npmrc, y se rechaza cualquier URL de git que lleve una contraseña.

  • Un repo clonado no puede bajar el listón

    El .npmrc propio de un proyecto no puede desactivar las comprobaciones de TLS, cambiar la CA o el proxy, ni relajar la antigüedad mínima de las versiones. jpm ignora esas opciones ahí y las indica en un aviso.

  • Su propio TLS, sin OpenSSL

    jpm habla TLS con su propio código, probado con Project Wycheproof y los vectores de los RFC, y verifica los certificados con las raíces de Mozilla y las de tu sistema.

  • Runtimes verificados por firma

    Un runtime de Node.js que pide un paquete se verifica contra el SHASUMS256.txt de la versión, y solo se confía en él cuando su firma coincide con las claves de publicación de Node.

  • Menos que atacar

    Un único binario de ~2 MB, sin runtime ni árbol de dependencias propio que instalar: menos código entre tú y el registro.

Seguro por defecto no es un sandbox: un script que apruebas se ejecuta con tus permisos. Los detalles: docs/install-scripts.md y docs/configuration.md.

La historia

Escrito por Claude Code. Verificado con las pruebas de todos los demás.

Todo empezó con un episodio del podcast Syntax que presentaba upm como más rápido y más pequeño que el resto. Pequeño, porque se ejecuta sobre Node.js. Entonces: ¿y si se portara a Rust y fuera pequeño de verdad? ¿Y qué haría falta para convertir el primer intento de una IA en algo en lo que confiarías en CI?

Claude Code, con Claude Opus 5.5, escribió cada línea, incluidos su propio TLS y su criptografía. JT Turner, ingeniero con 27 años de experiencia, tomó las decisiones. Cuando Claude se resistió a escribir nuestro propio TLS, la condición fue: probarlo como si no confiáramos en él. Así que cada "funciona" se verifica con las pruebas de otros: Wycheproof, los RFC y las suites de npm, pnpm, yarn y bun.

Los números deciden. Se construyó un cliente HTTP/2, se midió en los runners de GitHub y en un equipo de escritorio, resultó más lento y más voraz de CPU, y se eliminó.

¿Es jpm perfecto? No. Lo perfecto no existe. Existe lo suficientemente bueno, existe lo excelente, y existe lo bastante probado como para saber cuál de los dos tienes.

JT Turner

Lee la historia completa

Prueba jpm en tu CI. Y luego ponte a construir eso para lo que creías no tener tiempo.

Instalar jpm