¿Qué es Aube, el Gestor de Paquetes Node.js Más Rápido en 2026?

Las instalaciones de Node han sido lentas durante años. Ejecutas npm install, vas a la máquina de café, vuelves y CI todavía está resolviendo @types/node. Aube cambia esa ecuación. Termina una instalación cálida en CI de un proyecto real de 1.400 paquetes en 139 milisegundos, lo que es aproximadamente 7.3 veces más rápido que pnpm y 3 veces más rápido que Bun en el mismo escenario. La parte realmente interesante: lee y escribe tu archivo de bloqueo existente, por lo que puedes probarlo el lunes sin pedirle a nadie que migre.

Esta guía cubre qué es Aube, cómo alcanza esos números, cómo instalarlo, cómo se compara con pnpm, npm, yarn y Bun, y dónde encaja si construyes APIs con herramientas como Apidog todos los días.

¿Qué es Aube?

Aube es un gestor de paquetes de Node.js rápido construido por en.dev y lanzado bajo la licencia MIT. El nombre significa “amanecer” en francés y se pronuncia “ōb”. El proyecto está en beta (v1.0.0-beta.10 en el momento de escribir esto) y tiene como objetivo la compatibilidad con pnpm v11 como su estrella polar.

La propuesta es sencilla. Aube utiliza el mismo modelo en disco que pnpm, un almacén global direccionable por contenido más un diseño de enlaces simbólicos aislado, pero el pipeline de instalación está escrito en un lenguaje con hilos nativos en lugar de JavaScript. El mismo diseño, un motor más rápido. Esa única elección de diseño es lo que le permite estar por encima de Bun en varios escenarios de benchmark mientras sigue escribiendo pnpm-lock.yaml en su lugar.

Si ya has migrado entre gestores de paquetes una vez, sabes que el coste real no es la herramienta; es el coste social de hacer que todos en tu equipo cambien la forma en que ejecutan install. Aube elude eso leyendo directamente pnpm-lock.yaml, package-lock.json, npm-shrinkwrap.json, yarn.lock y bun.lock. Puedes ejecutarlo localmente mientras tu CI sigue usando pnpm, y nada cambia para tus compañeros de equipo.

Benchmarks de Aube: ¿qué tan rápido es "más rápido"?

El escenario de benchmark es un proyecto real de ~1.400 paquetes medido con hyperfine. Cada escenario asume un archivo de bloqueo comprometido. El eje que varía es la calidez de la caché: warm (cálido) borra node_modules pero mantiene el almacén global y la caché de paquetes, cold (frío) borra todo.

Números de los benchmarks oficiales (aube 1.0.0-beta.3, bun 1.3.12, pnpm 10.33.0, npm 11.12.1, yarn 1.22.22, node 24.15.0):

Varias cosas destacan. La instalación cálida de CI es el número principal porque refleja el caso más común en pipelines reales, donde el ejecutor restaura una caché y tu almacén global todavía tiene todos los tarballes hasheados. En ese escenario, Aube es aproximadamente 7.3 veces más rápido que pnpm y 3 veces más rápido que Bun.

El escenario install && run test mide el ciclo diario del desarrollador. Cada herramienta debe decidir "¿necesito instalar primero y luego ejecutar el script?". Aube puede omitir completamente el trabajo de instalación cuando su archivo de estado de instalación está fresco, por lo que todo el ciclo install && test regresa en 21ms. Otras herramientas aún revalidan el archivo de bloqueo antes de enviar el script, de ahí proviene la sobrecarga de 400ms-600ms.

En una caché fría, Bun supera a Aube (935ms vs 1.12s) porque la ruta de obtención de tarballs de Bun está extremadamente bien ajustada y las instalaciones frías están dominadas por la E/S. La instalación cálida es el escenario que se ejecuta miles de veces al día en un equipo de desarrollo típico; la fría se ejecuta una vez al mes cuando eliminas un ejecutor.

En todo el conjunto de escenarios, la documentación menciona picos de hasta 22 veces más rápido que pnpm y hasta 3 veces más rápido que Bun, dependiendo del escenario. Puedes reproducir todo esto localmente con mise run bench desde el repositorio de Aube.

Por qué Aube es más rápido que pnpm y Bun

Tres decisiones de diseño son las responsables principales.

Pipeline de instalación nativo y con hilos. npm, pnpm y yarn ejecutan el motor de instalación en Node.js. Eso significa que cada hash, cada extracción de tarball, cada llamada a symlink paga el impuesto de envío de JavaScript. Aube mueve la ruta caliente fuera de V8 y la lleva a un tiempo de ejecución compilado y con hilos nativos. Bun hace algo similar pero envía un tiempo de ejecución completo de JavaScript junto con su gestor de paquetes; Aube está diseñado específicamente para la ruta de instalación, lo que explica en parte por qué supera a Bun en instalaciones cálidas.

El almacén virtual global es el predeterminado. pnpm v11 añadió enableGlobalVirtualStore, pero no es el predeterminado para las instalaciones de proyectos. Aube por defecto utiliza un almacén virtual global, por lo que los proyectos repetidos con dependencias superpuestas en su mayoría enlazan a árboles de paquetes que ya existen en disco. Si tienes tres servicios que utilizan React, Vite, TypeScript y Playwright, los archivos pesados residen en un solo lugar y cada proyecto los enlaza simbólicamente. La documentación estima un ~90% menos de espacio en disco que npm en configuraciones típicas de monorepos.

Atajo de instalación con un archivo de estado fresco. aube run test primero comprueba un archivo compacto de estado de instalación. Si tu package.json y el hash del archivo de bloqueo coinciden con el archivo de estado, la fase de instalación es una única llamada stat y la prueba se ejecuta inmediatamente. Esto es lo que reduce el número de install && test a 21 ms.

Nada de esto es magia. Es lo que obtienes cuando tomas el diseño de pnpm, eliminas el arranque de JavaScript y diseñas la CLI asumiendo que el 99 por ciento de las instalaciones son "en realidad, nada cambió".

Cómo instalar Aube

La ruta recomendada es mise, el gestor de herramientas políglota:

mise use -g aube

Comprueba que se añadió a tu PATH:

aube --version

Si prefieres npm:

npm install -g @endevco/aube

En macOS o Linux con Homebrew, el tap de Endev lo tiene:

brew install endevco/tap/aube

Dentro de un proyecto, puedes fijar la versión de Aube localmente:

mise use aube

Eso escribe aube como una herramienta en tu mise.toml, lo que significa que cada shell que entra en la carpeta del proyecto obtiene la misma versión. Se acabó lo de "funciona en mi máquina porque instalé pnpm 10 el año pasado". La documentación de instalación también cubre las opciones de tarball y por sistema operativo.

Comandos diarios que realmente usarás

La superficie de comandos se asemeja mucho a pnpm, por lo que la memoria muscular se transfiere:

aube install              # instalar dependencias
aube add react            # añadir una dependencia
aube add -D vitest        # añadir una dependencia de desarrollo
aube remove react         # eliminar una dependencia
aube update               # actualizar dentro de los rangos de package.json
aube run build            # ejecutar un script de package.json
aube test                 # ejecutar script de prueba, instalando primero si está obsoleto
aube exec vitest          # ejecutar un binario local
aube dlx cowsay hi        # ejecutar un paquete en un entorno desechable
aube ci                   # instalación limpia y congelada para CI

Puedes acortar la mayoría de esos. Si el script existe en package.json, aube dev es lo mismo que aube run dev. También se envían dos shims de llamadas múltiples en el mismo binario:

aubr build       # aube run build
aubx cowsay hi   # aube dlx cowsay hi

Utiliza aube ci en los pipelines. Elimina node_modules, confirma que el archivo de bloqueo está fresco para el package.json actual y luego instala. Si el archivo de bloqueo se desvía, falla ruidosamente, que es lo que deseas en CI.

Compatibilidad con archivos de bloqueo

Esta es la característica que hace que la adopción de Aube sea de bajo riesgo. No tienes que comprometerte a cambiar a todo el equipo.

El patrón práctico se ve así. Tu equipo usa pnpm. CI sigue ejecutando pnpm install --frozen-lockfile. Tú ejecutas aube install localmente en tu máquina. Lee pnpm-lock.yaml, produce el mismo diseño de node_modules y escribe cualquier actualización de resolución de nuevo en el mismo pnpm-lock.yaml. Un compañero de equipo descarga tu rama, ejecuta pnpm install, y nada está mal. Con el tiempo, si Aube demuestra su valía, migras CI. Si no, lo eliminas y nadie más lo sabe.

Dos advertencias. Los archivos de bloqueo antiguos de pnpm v5 o v6 deben actualizarse primero con pnpm. Y los proyectos yarn PnP (el estilo .pnp.cjs) deben volver a un vinculador node_modules porque Aube escribe node_modules, no artefactos PnP.

Los valores predeterminados seguros importan más de lo que crees

Si has estado cerca de una base de código JavaScript en los últimos 18 meses, habrás visto acumularse incidentes en la cadena de suministro. La guía de seguridad de la cadena de suministro de npm cubre el patrón; el compromiso de Axios npm fue uno de los casos reales más claros de cómo una dependencia popular puede enviar un RAT multiplataforma a miles de máquinas de desarrolladores.

Aube adopta tres valores predeterminados con opinión que tratan las instalaciones como un límite de seguridad, no como una conveniencia:

1. Edad mínima de lanzamiento. Los nuevos lanzamientos esperan una edad mínima configurable antes de que Aube los instale. Un paquete recién comprometido que es retirado en dos horas nunca toca tus node_modules.
2. Bloqueo de dependencias exóticas. Aube bloquea las dependencias transitivas cuyas formas parecen sospechosas (URL inusuales, entradas tipo parche, referencias Git en lugares que normalmente llevan semver). Si explícitamente quieres una, la apruebas.
3. Aprobación de scripts de ciclo de vida. Los scripts postinstall de las dependencias se omiten por defecto. Ejecutas aube approve-builds para permitir paquetes específicos (esbuild, node-sass, lo que sea que realmente necesites construir localmente). Los paquetes cuyos scripts se omitieron aparecen en aube ignored-builds.

Esos tres comportamientos no te hacen invulnerable, pero convierten "No sabía que ese paquete incluso ejecutaba código" en "Elegí permitir que ese paquete ejecutara código". Esa es la postura de seguridad que deseas antes de tu próximo incidente de producción.

Diseño de módulos de Node

Aube utiliza un diseño aislado de node_modules. La carpeta node_modules/ de nivel superior contiene las dependencias declaradas en tu package.json. Las dependencias transitivas residen detrás de node_modules/.aube/. Los archivos de paquete se almacenan exactamente una vez en $XDG_DATA_HOME/aube/store/, que por defecto es ~/.local/share/aube/store/.

Tres consecuencias:

• Varios proyectos con dependencias superpuestas comparten archivos de paquete en disco. Se acabaron las "Tengo 12 copias de lodash en mi monorepo y proyectos secundarios".
• Las dependencias fantasma son más difíciles. Si un paquete no está en tu package.json, no puedes hacer require desde el nivel superior, porque no está en node_modules/. Esta es la misma garantía que te ofrece pnpm.
• Las instalaciones repetidas reutilizan archivos que ya están en disco. El único trabajo que queda es enlazar desde el almacén a la nueva carpeta node_modules/.aube/.

Si anteriormente utilizabas un diseño plano de node_modules (npm clásico o yarn v1), espera encontrar uno o dos paquetes rotos que dependían de importaciones fantasma. La solución siempre es "añádelo a tu package.json".

Workspaces y monorepos

Aube soporta workspaces y el protocolo workspace::

aube install -r
aube run test -r
aube add zod --filter @acme/api

Si tu repositorio ya tiene pnpm-workspace.yaml, Aube lo lee y lo escribe. Los nuevos workspaces "Aube-first" usan aube-workspace.yaml. Las banderas -r (recursivo) y --filter se mapean a la misma semántica que esperas de pnpm, por lo que las configuraciones de turborepo y nx siguen funcionando sin cambios.

Para monorepos de API, el número de CI con caché cálida es lo que más importa. Si tu pipeline hace install, build, test, publish contract en cada fusión, reducir el tiempo de install de 1 segundo de pnpm a 139 milisegundos de Aube en diez paquetes se acumula en minutos reales por día.

Dónde encaja Aube en un flujo de trabajo de desarrollo de API

Si construyes y pruebas APIs, las instalaciones se encuentran en la ruta crítica de cada refactorización. Tocas un esquema de solicitud, regeneras el cliente TypeScript, reinstalas, ejecutas pruebas de contrato contra tu servidor simulado, repites. Una instalación rápida no es una métrica de vanidad; es el intervalo entre "cambié esto" y "sé si se rompió".

Un ciclo práctico que funciona bien:

1. Diseña y simula la API en Apidog. El enfoque "schema-first" es mejor que el "code-first" para cualquier cosa que se comunique con otro equipo.
2. Genera un cliente tipado (o ejecuta pruebas de contrato contra el mock de Apidog) dentro de tu proyecto Node.
3. Utiliza Aube localmente para mantener las instalaciones en el rango de milisegundos mientras iteras en el cliente.
4. Conecta la misma suite de pruebas a CI con aube ci.

El cambio de herramientas de Postman durante el último año es parte de un patrón más grande: los desarrolladores quieren herramientas rápidas, "local-first" y seguras por defecto. Aube es la misma historia aplicada al paso de instalación. Si ya ejecutas Apidog dentro de VS Code, agregar Aube junto a él te cuesta una línea de mise use y te ahorra segundos en cada recarga en caliente.

Migración desde cada gestor de paquetes

Desde npm. Ejecuta aube install en el proyecto. Aube lee package-lock.json y lo vuelve a escribir. Obtendrás node_modules aislados en lugar de planos, así que ten cuidado con las importaciones fantasma. Si una se rompe, añade el paquete que falta a package.json y sigue adelante. Flujo de trabajo completo en la guía para usuarios de npm.

Desde pnpm. Esta es la migración con menos fricción porque el diseño en disco es el mismo. Aube lee pnpm-lock.yaml v9 directamente. El protocolo workspace: funciona. Los filtros funcionan. La página de pnpm-users enumera el puñado de banderas que se comportan de manera diferente.

Desde yarn. Aube lee tanto los archivos de bloqueo de yarn v1 classic como los de v2+ berry. Los usuarios de Yarn PnP necesitan cambiar de nuevo al modo nodeLinker: node-modules antes de probar Aube, porque Aube escribe node_modules y no .pnp.cjs.

Desde Bun. Aube lee bun.lock. La principal diferencia es que el gestor de paquetes de Bun está estrechamente acoplado con el tiempo de ejecución de JS de Bun; Aube es una herramienta de instalación independiente que funciona con cualquier versión de Node.js. Si ya usas mise para la gestión de versiones de Node, Aube encaja de la misma manera.

Consideraciones del mundo real

Estado Beta. A partir de abril de 2026, Aube es v1.0.0-beta.10. La documentación es explícita: apunta a la compatibilidad con pnpm v11, pero aún no ha sido probado en muchos proyectos. Trátalo como cualquier herramienta pre-1.0. Ejecútalo localmente primero, mantén tu archivo de bloqueo existente, no apuestes tu pipeline de lanzamiento de producción en él hasta que veas que funciona durante un mes.

Lo que está fuera del alcance. Aube intencionalmente no duplica lo que mise ya hace. La gestión del tiempo de ejecución (env, runtime, setup, self-update) pertenece allí. Algunos ayudantes de cuentas de registro (whoami, token, owner, search, pkg, set-script) son stubs de compatibilidad que te dirigen al comando npm. Si tu script de CI llama a alguno de ellos, mantén npm como respaldo.

Soporte de plataforma. El instalador recomendado es mise, que es compatible con macOS, Linux y Windows a través de WSL. El soporte nativo de Windows a través del tarball existe, pero está en una etapa anterior; consulta la página de instalación para conocer la matriz actual.

Comunidad. El proyecto tiene un Discord (enlazado desde la página de inicio) y 325 estrellas en GitHub en el momento de escribir esto. Pequeño pero activo. Buildkite proporciona CI para el proyecto, que se puede ver en la raíz del repositorio.

Preguntas frecuentes

¿Qué significa “aube”? Amanecer, en francés. Se pronuncia “ōb”. El lema del proyecto es “un nuevo amanecer para las instalaciones de Node”.

¿Es Aube un reemplazo directo para pnpm?Cercano. Apunta a la compatibilidad con pnpm v11 y lee el formato de archivo de bloqueo de pnpm. La mayoría de los flujos de trabajo con sabor a pnpm se transfieren sin cambios. Algunos comandos de pnpm (gestión del tiempo de ejecución, algunos ayudantes de registro) están intencionalmente fuera de su alcance porque pertenecen a otras herramientas.

¿Puedo usar Aube en CI mientras mantengo pnpm localmente?Sí, cualquiera de las dos direcciones funciona. Aube lee y escribe pnpm-lock.yaml en su lugar, por lo que las dos herramientas pueden compartir un archivo de bloqueo. Los equipos comúnmente comienzan al revés: Aube localmente, pnpm en CI, hasta que todos se sientan cómodos.

¿Cómo se compara Aube con Bun?En instalaciones cálidas, Aube es aproximadamente 3 veces más rápido que Bun porque Bun revalida más estados antes de instalar. En instalaciones frías, Bun está ligeramente por delante porque su ruta de búsqueda es extremadamente ajustada. Bun también incluye un tiempo de ejecución de JS; Aube es solo para instalación. Si ya usas Node, no necesitas el tiempo de ejecución de Bun para usar Aube. La comparación de diseño aislado al estilo pnpm proporciona contexto sobre por qué las elecciones de diseño son importantes.

¿Aube funciona en Windows?A través de WSL, sí. El soporte nativo de Windows funciona, pero está en una etapa temprana. Mise es la forma más fácil de instalar y actualizar en los tres sistemas operativos.

¿Es Aube de código abierto?Sí, bajo licencia MIT, el código fuente está en GitHub.

¿Qué le sucede a mi archivo pnpm-lock.yaml existente?Aube lo lee, realiza la instalación y vuelve a escribir el mismo archivo con cualquier cambio de resolución. Tus compañeros de equipo que ejecutan pnpm verán una diferencia normal en el archivo de bloqueo.

Conclusión

Para la mayoría de los proyectos de Node en 2026, el paso de instalación es más lento de lo necesario. Aube es el gestor de paquetes de Node.js más rápido en las rutas de instalación en caliente y de comandos repetidos que dominan los flujos de trabajo reales de los desarrolladores: 139 ms para una instalación de CI de 1.400 paquetes, 21 ms para install && test cuando nada cambió, 90% menos espacio en disco en una máquina con varios proyectos. Lee tu archivo de bloqueo existente, se toma en serio la seguridad por defecto y cuesta una línea de mise use aube probarlo.

Si ya pruebas APIs con un cliente rápido y "local-first" como Apidog, Aube es la pieza que encaja en el lado de la instalación. Descarga Apidog si aún no lo has hecho, combínalo con Aube para tu próximo servicio Node, y verás cuán más ajustado se vuelve el ciclo de retroalimentación.