---
title: "Gestor de Paquetes Bun: Guía Completa vs NPM, Yarn y PNPM"
description: "El gestor de paquetes Bun es hasta 30 veces más rápido que npm. Esta guía 2026 cubre la instalación de Bun, la migración desde npm/yarn/pnpm, y el uso de bun.lock, bun outdated y más."
date: 2024-02-07
categories: ["tools"]
tags: ["bun","npm","yarn"]
---

import { Picture } from "astro:assets";
import YouTubeEmbed from "@components/widgets/YouTubeEmbed.astro";
import Notice from "@components/widgets/Notice.astro";
import ListCheck from "@components/widgets/ListCheck.astro";
import Accordion from "@components/widgets/Accordion.astro";
import Tabs from "@components/widgets/Tabs.astro";
import Tab from "@components/widgets/Tab.astro";
import img1 from "@assets/images/24/02/bun-speed.webp";

Bun es un runtime de JavaScript y gestor de paquetes construido desde cero con Zig y JavaScriptCore. Su objetivo es ser un reemplazo directo de NPM, Yarn y PNPM, con tiempos de instalación significativamente más rápidos y una toolchain más simple. Desde que este artículo se publicó por primera vez en febrero de 2024, Bun ha ganado soporte completo para Windows, un nuevo lockfile basado en texto, y fue adquirido por Anthropic en diciembre de 2025.

<Notice type="info" title="Actualización julio 2026">
- **Soporte nativo de Windows**: Bun 1.1 (abril de 2024) añadió soporte completo para Windows pasando el 98 % de la suite de tests. Sin necesidad de WSL.
- **Lockfile basado en texto**: Bun 1.2 (enero de 2025) convirtió `bun.lock` (JSONC legible por humanos) en el predeterminado, reemplazando el binario `bun.lockb`.
- **Anthropic adquirió Bun** (diciembre de 2025): Bun ahora impulsa Claude Code y el Claude Agent SDK. Las dudas sobre la viabilidad a largo plazo del artículo original quedan en gran parte resueltas.
- **Nuevos comandos**: `bun outdated`, `bun why`, `bun audit`, `bun update --interactive`, `bun publish` y `bun patch` están todos listos para producción.
</Notice>

## Por qué cambiar a Bun: comparativa de bun vs npm, yarn y pnpm

El argumento principal para cambiar es la velocidad. Bun instala paquetes en paralelo usando múltiples hilos, cachea los resultados globalmente y puede ser **hasta 30 veces más rápido** que npm en instalaciones en frío. En instalaciones en caliente (con la caché poblada y el lockfile presente), la diferencia es aún mayor.

Pero la velocidad no es la única razón. Esto es lo que obtienes:

<ListCheck>
<ul>
<li>Instalaciones hasta 30 veces más rápidas (en frío) e instalaciones en caliente casi instantáneas</li>
<li>Soporte nativo de Windows, macOS y Linux, sin necesidad de WSL</li>
<li>`bun.lock` basado en texto que genera diffs limpios en los PR de git</li>
<li>Migración automática desde `package-lock.json`, `yarn.lock` y `pnpm-lock.yaml`</li>
<li>Test runner, bundler y publicador de paquetes integrados</li>
<li>Respaldado por Anthropic, impulsa Claude Code y el Claude Agent SDK</li>
</ul>
</ListCheck>

### Comparativa de velocidad: npm vs pnpm vs Bun

Los propios benchmarks de Bun afirman instalaciones "hasta 30 veces más rápidas" que npm. Ese número viene de su marketing, no de una fuente independiente. En la práctica, la diferencia depende del tamaño de tu proyecto, la red y el estado de la caché.

La página [pnpm.io/benchmarks](https://pnpm.io/benchmarks) (actualizada a diario) compara npm, pnpm, Yarn Classic y Yarn PnP, pero no incluye Bun. Para npm vs pnpm, el benchmark muestra que pnpm es aproximadamente 2-3 veces más rápido que npm en instalaciones limpias. La ventaja real de Bun sobre npm suele ser de 5-15 veces, dependiendo del escenario.

Tus resultados variarán. Prueba en tu propio proyecto. Mira el benchmark real de más abajo como un punto de datos.

Cuando este artículo se publicó por primera vez, algunos desarrolladores cuestionaban la viabilidad a largo plazo de Bun, trazando paralelismos con el auge y caída de Yarn. La adquisición por Anthropic en diciembre de 2025 ha zanjado en gran parte ese debate. Bun ya no es un proyecto secundario. Es el runtime detrás de Claude Code.

Puedes consultar [cómo migrar Astro a Bun en Cloudflare](/es/migrar-astro-bun/) para ver un recorrido de migración real.

## Cómo instalar Bun en macOS, Linux y Windows

Bun se instala en todas las plataformas principales. Abajo están los métodos recomendados actualmente.

<Tabs>
<Tab name="macOS">
```sh
brew install oven-sh/bun/bun
```
El viejo método en dos pasos `brew tap oven-sh/bun` + `brew install bun` sigue funcionando, pero el comando único de arriba es el preferido.
</Tab>
<Tab name="Linux">
```sh
curl -fsSL https://bun.sh/install | bash
```

<Notice type="info" title="Prerequisitos de Linux">
Se requiere el paquete `unzip`. Instálalo con `sudo apt install unzip` (Debian/Ubuntu) o el equivalente de tu distro. Se recomienda kernel 5.6+; el mínimo es 5.1. Bun degrada con elegancia en kernels tan antiguos como 3.10 (RHEL 7), pero con rendimiento reducido. Comprueba tu kernel con `uname -r`.
</Notice>
</Tab>
<Tab name="Windows">
```powershell
powershell -c "irm bun.sh/install.ps1 | iex"
```
Requiere Windows 10 versión 1809 o posterior. Soporte nativo completo, sin necesidad de WSL. Bun en Windows pasa el 98 % de su propia suite de tests.
</Tab>
<Tab name="npm (multiplataforma)">
```sh
npm install -g bun
```
Opción rápida si ya tienes Node.js y npm instalados. Funciona en todas las plataformas.
</Tab>
</Tabs>

### Verificar la instalación

```sh
bun --version
# Debería mostrar algo como: 1.3.14

bun --revision
# Muestra la revisión del build (útil para reportar bugs)
```

Para autoactualizar Bun:

```sh
bun upgrade
```

<Notice type="warning" title="Compatibilidad de CPU">
Los builds estándar de Bun requieren instrucciones AVX2 (Intel de la era Haswell, AMD de la era Excavator o más recientes). En CPUs más antiguas obtendrás un error "Illegal Instruction". Si eso ocurre, instala el build baseline: `curl -fsSL https://bun.sh/install | bash -s -- --baseline`.
</Notice>

Si `bun` no se encuentra tras la instalación, asegúrate de que `~/.bun/bin` está en tu PATH. Añade esto a la configuración de tu shell:

```sh
# bash/zsh, añade a ~/.bashrc o ~/.zshrc
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"
```

Para Fish shell, mira [los mejores plugins y herramientas de Fish shell](/es/mejores-plugins-fish-shell/) como guía para configurar el PATH.

Si necesitas Node.js instalado junto a Bun, mira [cómo instalar Node.js usando NVM](/es/instalar-nodejs-nvm-macos-ubuntu/).

## El lockfile de Bun: bun.lock vs bun.lockb

Antes de Bun 1.2 (enero de 2025), el lockfile predeterminado era el binario `bun.lockb`. Funcionaba, pero no podías hacerle diff en git, no podías revisar los cambios del lockfile en los PR, y los conflictos de merge eran imposibles de resolver a mano.

**Bun 1.2 convirtió `bun.lock` en el predeterminado.** Es un archivo JSONC basado en texto que genera diffs y merges como cualquier otro archivo fuente.

<Notice type="info" title="Migrando desde bun.lockb">
```sh
bun install --save-text-lockfile --frozen-lockfile --lockfile-only
# Luego elimina el viejo lockfile binario
rm bun.lockb
```
Tras esto, `bun install` mantendrá `bun.lock` de ahora en adelante. El binario `bun.lockb` sigue soportado por compatibilidad hacia atrás, pero no hay razón para conservarlo.
</Notice>

**Verifica:** `ls bun.lock` debería existir. Ejecuta `git diff bun.lock`. Deberías ver una salida JSONC legible.

Si `bun install` sigue generando `bun.lockb` en lugar de `bun.lock`, revisa `bunfig.toml` en busca de `saveTextLockfile = false` o actualiza tu versión de Bun.

## Cómo migrar de NPM, Yarn o PNPM a Bun

Desde Bun 1.1, `bun install` puede migrar automáticamente desde lockfiles existentes. Pero el enfoque más limpio sigue siendo eliminar primero el lockfile viejo y luego dejar que Bun genere un `bun.lock` nuevo.

<Tabs>
<Tab name="Desde npm">
```sh
rm package-lock.json
bun install
```
</Tab>
<Tab name="Desde yarn">
```sh
rm yarn.lock
bun install
```
</Tab>
<Tab name="Desde pnpm">
```sh
rm pnpm-lock.yaml
bun install
```
</Tab>
</Tabs>

**Verifica:** `ls bun.lock` debería existir, `ls node_modules` debería mostrar los paquetes instalados, y `bun run build` (o el comando de build de tu proyecto) debería completarse con éxito.

Si tienes problemas con addons nativos, revisa `bun pm untrusted`. Bun bloquea los scripts de ciclo de vida (postinstall, etc.) por defecto desde Bun 1.1. Mira la sección de solución de problemas de abajo para saber cómo confiar en paquetes.

Para un recorrido completo de migración de Astro, mira [migrar Astro a Bun en Cloudflare](/es/migrar-astro-bun/).

## Referencia de comandos de Bun: comandos esenciales y equivalentes de npm

### Comandos principales

| Comando Bun | Equivalente npm | Propósito |
|---|---|---|
| `bun install` | `npm install` | Instalar todas las dependencias de package.json |
| `bun add <pkg>` | `npm install <pkg>` | Añadir un paquete nuevo |
| `bun add <pkg> --dev` | `npm install <pkg> --save-dev` | Añadir una dependencia de desarrollo |
| `bun remove <pkg>` | `npm uninstall <pkg>` | Eliminar un paquete |
| `bun run <script>` | `npm run <script>` | Ejecutar un script de package.json |
| `bun outdated` | `npm outdated` | Mostrar paquetes desactualizados |
| `bun update <pkg>` | `npm update <pkg>` | Actualizar dentro del rango semver |
| `bun update <pkg> --latest` | `npm install <pkg>@latest` | Actualizar a la última versión |
| `bun update --interactive` | *(sin equivalente integrado)* | Selector interactivo (Bun 1.3+) |
| `bun why <pkg>` | `npm explain <pkg>` | Explicar por qué un paquete está instalado |
| `bun audit` | `npm audit` | Buscar vulnerabilidades de seguridad |
| `bun publish` | `npm publish` | Publicar un paquete en npm |
| `bun patch <pkg>` | `npx patch-package` | Parchear una dependencia |
| `bun pm pack` | `npm pack` | Crear un tarball para publicación |

### Comprobar paquetes desactualizados

```sh
bun outdated
# Muestra todos los paquetes desactualizados con versión actual y última

bun outdated --filter '@myorg/*'
# Filtrar a un scope específico
```

### Actualizar paquetes

```sh
bun update <package>            # Actualizar dentro del rango semver
bun update <package> --latest   # Actualizar a la última, ignorando semver
bun update                      # Actualizar todas las deps dentro del rango semver
bun update --interactive        # Elegir qué deps actualizar interactivamente
```

Para profundizar en la actualización de paquetes con Bun, mira [cómo actualizar paquetes Node con Bun](/es/actualizar-paquetes-bun/) y [cómo actualizar todas las dependencias de Node.js](/es/actualizar-dependencias-nodejs/).

### Seguridad y confianza

<Notice type="warning" title="Los scripts de ciclo de vida están bloqueados por defecto">
Desde Bun 1.1, los scripts postinstall y otros scripts de ciclo de vida de los paquetes están bloqueados por defecto por seguridad. Esto es bueno (previene ataques a la cadena de suministro), pero significa que algunos paquetes (como los addons nativos) no se compilarán hasta que confíes en ellos.
</Notice>

```sh
bun pm untrusted          # Listar paquetes con scripts de ciclo de vida bloqueados
bun pm trust <package>    # Confiar en un paquete específico
bun pm trust --all        # Confiar en todos los paquetes (usar con precaución)
```

## Benchmark real: prueba de velocidad de bun install

Ejecuté esta prueba en el blog de Astro de bitdoze.com. El proyecto tiene una mezcla típica de dependencias. Aquí están los números en bruto:

**NPM:**

```sh
➜  bitdoze-astro-bkw git:(main) time npm install

npm install  13.22s user 3.82s system 23% cpu 1:13.89 total

npm run build  55.96s user 3.41s system 126% cpu 46.776 total
```

**Bun:**

```sh
➜  bitdoze-astro-bkw git:(main) time bun install

bun install  10.83s user 2.14s system 121% cpu 10.694 total

bun run build  55.30s user 3.34s system 126% cpu 46.181 total
```

<Picture formats={["webp"]} fallbackFormat="webp" src={img1} alt="Benchmark de velocidad de bun install: 11 segundos vs los 73 segundos de npm, instalación de paquetes 7 veces más rápida" />

**Resultados:** bun install tardó ~11 segundos. npm install tardó 73 segundos. Eso es **7 veces más rápido** para este proyecto. El proceso de build fue idéntico. El mismo build de Astro corre a la misma velocidad sin importar qué gestor de paquetes instaló las dependencias.

Esto se probó en febrero de 2024 y se reverificó en julio de 2026. Bun 1.2+ es aproximadamente un 30 % más rápido que la versión probada originalmente, así que la diferencia probablemente se ha ampliado en instalaciones nuevas. Para ver cómo Astro 7 mejoró las velocidades de build, mira [benchmark de Astro 7: tiempos de compilación reducidos a la mitad](/es/astro-7-compilaciones-mas-rapidas/). También puedes [optimizar aún más las velocidades de build de Astro](/es/astro-ssg-optimizacion-build/) con ajustes específicos de SSG.

Tus resultados variarán según el tamaño del proyecto, el número de dependencias, el hardware y las condiciones de red.

## Bun en Docker y CI/CD: mejores prácticas de producción

### Ejemplo de Dockerfile

Bun ofrece imágenes Docker oficiales. Usa `oven/bun:alpine` para la etapa de build (más pequeña, basada en musl) y `oven/bun:distroless` para el runtime (superficie de ataque mínima):

```dockerfile
FROM oven/bun:alpine AS builder
WORKDIR /app
COPY package.json bun.lock ./
RUN bun install --frozen-lockfile

FROM oven/bun:distroless AS runtime
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
CMD ["bun", "run", "start"]
```

Para omitir las devDependencies en producción:

```sh
bun install --frozen-lockfile --production
```

### CI/CD con GitHub Actions

<Notice type="info" title="Usa siempre --frozen-lockfile en CI">
`bun install --frozen-lockfile` falla si `bun.lock` está desactualizado. Esto detecta la deriva del lockfile antes de que llegue a producción. Ejecuta `bun install` localmente y commitea el lockfile actualizado si CI falla en este paso.
</Notice>

```yaml
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
        with:
          bun-version: latest
      - run: bun install --frozen-lockfile
      - run: bun run build
      - run: bun test
```

Fallo común: si `--frozen-lockfile` falla, significa que tu `bun.lock` no coincide con `package.json`. Ejecuta `bun install` localmente, commitea el lockfile y haz push.

Para más comandos y patrones de Docker, mira [los comandos de Docker que debes conocer](/es/comandos-docker/).

## Ejemplos de uso de Bun

### Añadir y eliminar paquetes

```sh
# Añadir paquetes
bun add tailwindcss autoprefixer postcss

# Añadir una dependencia de desarrollo
bun add prettier --dev

# Eliminar un paquete
bun remove tailwindcss
```

### Ejecutar scripts

```sh
bun run dev      # Ejecutar el script "dev" de package.json
bun run build    # Ejecutar el script "build"
bun run test     # Ejecutar el script "test"
```

Para monorepos con workspaces, ejecuta scripts en paquetes específicos:

```sh
bun run --filter @myorg/web build
```

### Comprobar y actualizar dependencias

```sh
# Ver qué está desactualizado
bun outdated

# Actualizar interactivamente (Bun 1.3+)
bun update --interactive

# Actualizar un paquete específico a la última versión
bun update tailwindcss --latest
```

### Auditar vulnerabilidades

```sh
bun audit
# Busca vulnerabilidades de seguridad conocidas en las dependencias
```

## Solución de problemas comunes de Bun

<Accordion label="Error &quot;Illegal Instruction&quot; al iniciar" group="troubleshooting">
Tu CPU carece de soporte AVX2 (Intel anteriores a Haswell, AMD anteriores a Excavator). Los builds estándar de Bun requieren AVX2.

**Solución:** Instala el build baseline que funciona en CPUs más antiguas:
```sh
curl -fsSL https://bun.sh/install | bash -s -- --baseline
```
O en Windows:
```powershell
powershell -c "irm bun.sh/install.ps1 -- --baseline | iex"
```
</Accordion>

<Accordion label="bun: command not found" group="troubleshooting">
`~/.bun/bin` no está en tu PATH.

**Solución:** Añade a la configuración de tu shell:
```sh
# bash (~/.bashrc) o zsh (~/.zshrc)
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"
```
Luego recarga: `source ~/.bashrc` (o `source ~/.zshrc`).

Para Fish shell, añade a `~/.config/fish/config.fish`:
```fish
set --export BUN_INSTALL "$HOME/.bun"
set --export PATH "$BUN_INSTALL/bin" $PATH
```
</Accordion>

<Accordion label="Scripts de ciclo de vida bloqueados (postinstall fallando)" group="troubleshooting">
Bun bloquea los scripts de ciclo de vida (postinstall, preinstall, etc.) por defecto desde Bun 1.1. Es una medida de seguridad contra ataques a la cadena de suministro.

**Solución:**
```sh
bun pm untrusted          # Ver qué paquetes están bloqueados
bun pm trust <package>    # Confiar en un paquete específico
bun pm trust --all        # Confiar en todos (usar con precaución)
```
Alternativamente, añade a `package.json`:
```json
{
  "trustedDependencies": ["package-name"]
}
```
</Accordion>

<Accordion label="Kernel demasiado antiguo en Linux" group="troubleshooting">
Bun requiere kernel 5.1 como mínimo, recomendándose 5.6+. Intentará correr en kernels tan antiguos como 3.10 (RHEL 7) con funcionalidad reducida.

**Comprueba tu kernel:**
```sh
uname -r
```
Si estás en un kernel más antiguo, considera actualizar o usar una distro más nueva. En hosting compartido o VPS gestionado puede que no controles el kernel; consulta con tu proveedor.
</Accordion>

<Accordion label="El registro privado no funciona" group="troubleshooting">
Desde Bun 1.2, Bun lee los archivos `.npmrc` (`$HOME/.npmrc` y el `.npmrc` a nivel de proyecto). También puedes configurar registros en `bunfig.toml`:

```toml
[install.scopes]
"@myorg" = { url = "https://registry.myorg.com", token = "npm_..." }
```

O usa `.npmrc`:
```
//registry.myorg.com/:_authToken=npm_...
@myorg:registry=https://registry.myorg.com
```
</Accordion>

<Accordion label="Cómo volver a npm" group="troubleshooting">
Si Bun te está causando problemas y necesitas revertir:

```sh
rm -rf node_modules bun.lock
npm install
```

Esto restaura tu configuración de npm. Si conservaste `package-lock.json` como backup, recuperarás tu árbol de dependencias anterior exacto. Si no, npm generará uno nuevo desde `package.json`.
</Accordion>

## Preguntas frecuentes

<Accordion label="¿Está Bun listo para producción?" group="faq">
Para gestión de paquetes, sí. `bun install` es estable, rápido y se usa en pipelines de CI/CD en producción. Para el runtime de Bun (reemplazar Node.js), la madurez varía según el caso de uso. La mayoría de equipos empieza usando Bun solo como gestor de paquetes, corriendo su app en Node.js.

La adquisición por Anthropic (diciembre de 2025) es una señal fuerte. Bun impulsa Claude Code y el Claude Agent SDK, lo que significa que Anthropic tiene un interés comercial directo en la fiabilidad de Bun.
</Accordion>

<Accordion label="¿Funciona Bun con registros privados?" group="faq">
Sí. Desde Bun 1.2, Bun lee los archivos `.npmrc` para tokens de autenticación y configuración de registros con scope. También soporta `bunfig.toml` para configuración específica de Bun. Tanto `$HOME/.npmrc` (global) como el `.npmrc` a nivel de proyecto están soportados.
</Accordion>

<Accordion label="¿Puedo usar Bun en monorepos?" group="faq">
Sí. Bun soporta workspaces compatibles con npm. Bun 1.3 añadió `--linker=isolated` para resolución estricta de dependencias al estilo pnpm y catálogos para gestión centralizada de versiones entre paquetes.

Para monorepos simples (unos pocos paquetes), Bun funciona bien. Para monorepos complejos con árboles de dependencias profundos y requisitos estrictos de hoisting, la madura toolchain de pnpm puede seguir siendo más segura.
</Accordion>

<Accordion label="¿Cómo gestiona Bun el uso de disco?" group="faq">
Bun usa una caché global en `~/.bun/install/cache` pero crea copias completas de `node_modules` en cada proyecto. Esto significa que pnpm (que usa hard links) ahorra más espacio en disco cuando tienes muchos proyectos en la misma máquina.

Si el espacio en disco escasea y tienes docenas de proyectos, pnpm es la mejor opción en eficiencia de disco. Para un puñado de proyectos, la diferencia es despreciable.
</Accordion>

<Accordion label="¿Debería usar bun.lockb o bun.lock?" group="faq">
Usa `bun.lock`. Es el predeterminado desde Bun 1.2, es legible por humanos y genera diffs correctos en git. `bun.lockb` solo es relevante si estás en Bun 1.1 o anterior, o si configuraste explícitamente `saveTextLockfile = false` en `bunfig.toml`. No hay razón para elegir el formato binario en una versión moderna de Bun.
</Accordion>

## Conclusión

Bun como gestor de paquetes está listo para producción y es significativamente más rápido que npm, yarn o pnpm en tiempos de instalación. El `bun.lock` basado en texto, el soporte completo de Windows y el respaldo de Anthropic han resuelto las principales preocupaciones de cuando este artículo se publicó por primera vez.

Mi recomendación: prueba Bun como gestor de paquetes en tu próximo proyecto. Elimina el lockfile viejo, ejecuta `bun install` y mira qué tal se siente. Siempre puedes [volver atrás](#solución-de-problemas-comunes-de-bun) si algo se rompe.

El lado del runtime (reemplazar Node.js) es una decisión aparte con más matices. ¿Pero para `bun install` vs `npm install`? No hay competencia.

<YouTubeEmbed
  url="https://www.youtube.com/embed/BsnCpESUEqM"
  label="Presentación en vídeo de Bun"
/>