La elección de un gestor de paquetes de JavaScript pesa sobre la vida de un proyecto mucho más de lo que parece: formato del archivo de bloqueo, velocidad de instalación en integración continua, compatibilidad con el registro npm, soporte de monorepos. En 2026, el panorama se movió en los cuatro frentes a la vez, con una reescritura mayor de pnpm y una consolidación del lugar de Bun y Deno en los usos profesionales.
npm, la referencia que se mantiene
Incluido por defecto con Node.js, npm sigue siendo el punto de entrada de la mayoría de los proyectos y el registro al que acceden todas las demás herramientas. Su resolución de dependencias, escrita en JavaScript, sigue siendo más lenta que la de sus competidores, algo especialmente notable en instalaciones en frío de un árbol de dependencias grande, pero su universalidad y la ausencia de instalación adicional lo convierten en una opción por defecto razonable para un proyecto sencillo o un equipo que no quiere sumar herramientas.
pnpm 12, una base reescrita en Rust
La versión 12 de pnpm marca una ruptura técnica: el núcleo de la herramienta se reescribió en Rust manteniendo la compatibilidad con los comandos, opciones y formatos de pnpm 11. La ganancia se nota sobre todo en las instalaciones repetidas, las que se benefician de la caché local y de un node_modules ya existente. Las versiones 12.x también extendieron los catalogs al protocolo workspace:, añadieron indicadores de seguridad de la cadena de suministro en remove y update, e introdujeron pnpm pipeline para orquestar las tareas de un monorepo como lo haría un job de integración continua.
Para un equipo ya organizado en monorepo con herramientas de línea de comandos estandarizadas, esta reescritura cambia poco los hábitos de trabajo diarios mientras reduce el tiempo de espera en las instalaciones dentro de un pipeline de despliegue.
Bun, la velocidad como argumento central
Bun aborda el problema de otra manera: en lugar de un gestor de paquetes montado sobre Node.js, es un ejecutable único escrito en Zig que integra runtime, empaquetador, ejecutor de pruebas y gestor de paquetes. Su instalador se apoya en muchas menos llamadas al sistema que npm y en un formato de bloqueo binario, lo que explica las diferencias de rendimiento observadas en varios bancos de pruebas publicados en 2026, tanto en instalaciones en frío como en proyectos de gran tamaño. La contrapartida sigue siendo la compatibilidad: Bun cubre la mayor parte de la API de Node.js, pero algunos paquetes nativos o scripts de instalación avanzados siguen siendo casos particulares que conviene probar antes de una migración completa.
Deno y el fin del aislamiento respecto a npm
Deno cultivó durante mucho tiempo un ecosistema separado de npm, antes de renunciar en gran parte a ello a partir de su rama 2.x. Los prefijos npm: permiten ahora usar paquetes del registro npm sin archivo package.json, conservando el modelo de permisos explícitos que le dio su reputación de seguridad por defecto. Deno sigue siendo minoritario en el entorno empresarial, pero su soporte de workspaces y su compatibilidad con npm lo convierten en una opción creíble para un proyecto nuevo que quiera limitar la confianza otorgada a los scripts de instalación.
El formato del archivo de bloqueo de dependencias no se convierte automáticamente de una herramienta a otra: cambiar de gestor de paquetes a mitad de proyecto es una migración, no un simple cambio de comando.
Comparativa sintética
| Herramienta | Enfoque | Formato de lockfile | Compatibilidad con npm | Caso de uso recomendado |
|---|---|---|---|---|
| npm | Resolución en JavaScript, incluido con Node.js | package-lock.json (JSON) | Nativa | Proyecto sencillo, equipo sin herramientas adicionales |
| pnpm 12 | Núcleo reescrito en Rust, almacén de dependencias compartido | pnpm-lock.yaml (YAML) | Total | Monorepo, equipo que busca estabilidad y velocidad con caché |
| Bun | Runtime y gestor nativos escritos en Zig | bun.lock (binario o JSONC) | Amplia, algunos casos particulares | Instalaciones frecuentes, alta sensibilidad a la velocidad |
| Deno 2.x | Runtime seguro por permisos, especificadores npm: | deno.lock (JSON) | Vía prefijo npm: | Proyecto nuevo, prioridad a la seguridad por defecto |
Instalar un proyecto con cada una de las cuatro herramientas
# npm (incluido con Node.js)
npm install
# pnpm (vía Corepack, recomendado para fijar la versión)
corepack enable
pnpm install
# Bun
curl -fsSL https://bun.sh/install | bash
bun install
# Deno, con compatibilidad npm
deno install
Seguridad de la cadena de suministro
Elegir un gestor de paquetes no es solo una cuestión de velocidad: también es una cuestión de confianza otorgada a scripts de instalación que se ejecutan automáticamente. npm ejecuta por defecto los scripts postinstall de cada paquete, lo que ha servido de vector para varios ataques a la cadena de suministro en los últimos años. pnpm bloquea estos scripts por defecto desde su versión 10 y exige una autorización explícita mediante pnpm approve-builds, una diferencia que pesa mucho en un proyecto que depende de cientos de paquetes de terceros. Deno lleva esta lógica más lejos con un modelo de permisos que se aplica al propio runtime, no solo a la instalación. Bun, por su parte, ha añadido indicadores de seguridad pero mantiene un comportamiento más cercano al de npm en la ejecución de scripts.
Para un equipo que gestiona varios repositorios de clientes, este criterio merece tanta atención como la velocidad de instalación: un incidente de seguridad ligado a una dependencia comprometida cuesta mucho más que los segundos ahorrados en un pipeline de despliegue.
Monorepos e integración con herramientas de build
La elección del gestor de paquetes suele ir acompañada de la elección de un orquestador de tareas para monorepos, como Turborepo o Nx. Las cuatro herramientas exponen workspaces compatibles con estos orquestadores, pero el nivel de integración varía: pnpm sigue siendo la referencia para monorepos voluminosos gracias a su almacén de dependencias compartido, que evita duplicar los paquetes comunes en disco. Bun avanza rápido en este terreno, pero algunos plugins de orquestadores todavía lo soportan de forma parcial. npm y Deno cubren los casos sencillos sin extender ese rendimiento a monorepos muy grandes.
Cómo elegir sin equivocarse
El criterio de velocidad de instalación nunca debería ser el único factor de decisión. Un equipo que despliega decenas de veces al día desde integración continua ganará más optimizando la caché de una herramienta ya implantada que migrando a un nuevo gestor de paquetes por unos segundos de ahorro. En cambio, un proyecto nuevo, sin deuda de herramientas, puede elegir pnpm o Bun sin asumir un coste de migración.
Para un desarrollador freelance que gestiona varios proyectos de clientes de distinto tamaño, la prioridad suele ser la estabilidad y la compatibilidad más amplia: pnpm sigue siendo la opción más segura. Para una startup que optimiza su tiempo de build en integración continua sobre un único producto, Bun puede justificar su adopción si las pruebas de compatibilidad son concluyentes. Para un equipo que construye un nuevo servicio aislado con requisitos de seguridad exigentes, Deno merece evaluarse antes de descartarlo por costumbre.
Lo que hay que recordar
npm sigue siendo una opción por defecto legítima para un proyecto sencillo. pnpm 12 ganó rendimiento sin perder nada de su estabilidad para monorepos. Bun sigue haciendo de la velocidad su principal argumento de venta, con una compatibilidad que mejora pero que merece probarse antes de un cambio completo. Deno, por último, hizo su compatibilidad con npm suficientemente sólida como para convertirse en una opción razonable más allá de su público histórico. La misma lógica de reducir la fricción diaria explica por qué los asistentes de IA avanzan también dentro de las herramientas de chat de equipo.
En los proyectos de clientes gestionados día a día, cambiar de gestor de paquetes rara vez aporta lo que se espera: el tiempo ganado en la instalación suele perderse ajustando scripts, pipelines y hábitos de equipo. La señal real a seguir en 2026 no es la carrera por la velocidad, sino la convergencia progresiva de todas estas herramientas hacia un mismo registro npm y una misma base de compatibilidad — Simon Janvier.
Para saber más: documentación oficial de pnpm, «What’s different in pnpm 12».
