Actualizar Paquetes con Bun: Cómo Actualizar a la Última Versión

La forma más rápida de actualizar paquetes a la última versión con Bun es bun update. Desde Bun 1.2 también reescribe package.json y bun.lock por ti, que es la parte que la mayoría de guías sigue haciendo mal. Si recuerdas una cosa de este post, que sea esta: revisa git diff tras cada actualización, porque Bun tocará tu manifiesto.

Bun está en 1.4.x ahora (el proyecto se movió de bun.sh a bun.com), y su gestor de paquetes cubre todo el flujo de actualización sin herramientas extra. Puedes actualizar todo dentro del rango, elegir paquetes interactivamente con bun update -i, saltar majors con bun update --latest, o parchear una sola dependencia transitiva. Son los mismos paquetes Node.js que gestiona npm. Bun solo los instala y actualiza más rápido. Si aún necesitas un runtime Node junto a Bun, mira cómo instalar Node.js con NVM en macOS y Ubuntu.

El flujo de abajo es el que uso: actualiza el propio Bun, comprueba qué está desactualizado, actualiza, verifica, y haz rollback si el build se rompe. ¿Nuevo en Bun? Empieza con la guía del gestor de paquetes Bun vs NPM, Yarn y PNPM. ¿Moviendo un sitio Astro? Mira cómo migrar Astro a Bun en Cloudflare Pages.

Prerequisitos y flujo de actualización de un vistazo

Antes de tocar paquetes, asegúrate de tener lo básico en su sitio. Es una póliza de seguro de cinco minutos que te ahorra una tarde cuando una subida major rompe el build.

El flujo completo, en orden:

Usa esa tabla como hoja de ruta. Todo lo de abajo expande una fila con pasos de verificación y modos de fallo.

Actualiza primero el propio Bun a la última versión

Bun desactualizado, comportamiento desactualizado. Los flags de actualización y el formato del lockfile han cambiado a lo largo de 1.1, 1.2, 1.3 y 1.4, así que corre esto primero. Cómo actualizas depende de cómo se instaló Bun:

bun upgrade

brew upgrade bun

scoop update bun

Verifica: bun --version debería imprimir 1.4.x. Si el número no se movió, actualizaste una instalación distinta a la de tu PATH. Corre which bun (o where bun en Windows) y compáralo con dónde puso su copia tu gestor de paquetes.

Comprueba paquetes desactualizados con bun outdated

Corre esto antes de cada sesión de actualización. bun outdated (desde Bun 1.1.26) imprime una tabla con tres columnas de versión:

• Current - lo que está en tu lockfile ahora mismo
• Update - la versión más alta dentro de tu rango declarado
• Latest - la versión publicada más nueva, majors incluidas

La diferencia entre las dos últimas columnas te dice qué comando necesitas realmente. Si todo lo que te importa está en la columna Update, bun update a pelo basta. Si las versiones que quieres están en Latest, estás ante una corrida de --latest (o una elección interactiva).

bun outdated

La salida tiene esta forma (las versiones diferirán en tu proyecto):

Package          Current   Update   Latest
ms               2.1.0     2.1.3    2.1.3
zod              3.22.4    3.25.0   4.1.12
typescript       5.4.5     5.9.2    5.9.2

Filtros útiles:

bun outdated '@types/*'      # glob: just the @types scope
bun outdated '!@types/*'     # negation: everything except @types
bun outdated -r              # every workspace in a monorepo
bun outdated --filter web    # one workspace

Verifica: cuando todo está al día, bun outdated imprime solo la cabecera y sale con 0. Esa es tu señal de “nada que hacer”. No-cero o una tabla llena significa que hay trabajo. Referencia: docs de bun outdated, notas de la versión v1.1.26.

Actualiza todos los paquetes con bun update (dentro de rango)

bun update a pelo (alias: bun up) sube tus dependencias directas y transitivas dentro de los rangos ya declarados en package.json. Una dependencia ^2.1.0 puede aterrizar en 2.1.3 o 2.9.9, nunca en 3.0.0.

bun update

Previsualiza primero si quieres una vista en seco de lo que se movería:

bun update --dry-run

Concretamente, esto:

"dependencies": {
  "ms": "^2.1.0"
}

se convierte en esto después de que bun update recoja 2.1.3:

"dependencies": {
  "ms": "^2.1.3"
}

El operador se preserva: ^ sigue siendo ^, ~ sigue siendo ~. Los fijados exactos (2.1.0) y los dist-tags (latest) se dejan como están escritos. Las dependencias transitivas también se mueven, y el lockfile registra cada cambio.

Verifica:

git diff package.json bun.lock

Deberías ver solo las subidas que esperabas. Si package.json muestra un diff en una dependencia que creías fijada, ese fijado probablemente era un rango después de todo.

Cómo se ve “roto”: ninguna salida en absoluto significa que nada estaba fuera de rango (o nada está instalado aún - corre bun install primero). Un muro de churn en bun.lock sin cambio en package.json es normal tras movimientos de metadatos del registry. Los docs: bun update.

Actualiza paquetes a la última versión con bun update --latest

Este es el flag que la gente realmente quiere cuando dice “actualiza todo a lo más nuevo”. --latest (corto: -L) ignora tus rangos declarados para las dependencias directas, instala las versiones publicadas más nuevas incluyendo majors, y reescribe package.json para coincidir.

bun update --latest

Todo recibe el tratamiento cross-major:

bun update --latest
# zod 3.22.4  ->  4.1.12   (major)
# typescript 5.4.5 -> 5.9.2 (same major, but outside your ^5.4 range floor rewrite)

Cómo funciona la reescritura: tu "zod": "^3.22.4" se convierte en "zod": "^4.1.12" - mismo estilo de rango, nuevo suelo. Las dependencias transitivas siguen respetando los rangos de sus dependientes, y Bun nunca degrada una dependencia que ya está por delante de latest (instalaciones prerelease). Disponible desde Bun 1.2 (notas de versión).

--force vs --latest: por qué --force no actualiza a latest

Los dos comandos lado a lado:

bun update --force    # refresh registry metadata, reinstall what your ranges allow
bun update --latest   # cross majors, rewrite package.json to the newest versions

Actualiza solo dependencias de producción o de desarrollo

bun update --prod       # or -P: dependencies only
bun update --dev        # or -D: devDependencies only
bun update --no-optional

Combina libremente: bun update --dev --latest es el movimiento habitual de “lleva las herramientas de dev a los majors, deja las deps de runtime en paz”.

Patrones glob y exclusiones

bun update '@types/*' --latest     # all @types packages to their latest
bun update '!@babel/core' --latest # everything except @babel/core
bun update jquery@3                # move jquery within the 3.x line

Nota de ops: los majors rompen builds. Trata --latest como un evento de rama-más-CI, no un comando de viernes a las 17:00. Tras aterrizar los majors y tener CI en verde, redespliega y haz smoke-test en producción. Para sitios Astro, mira cómo desplegar un blog Astro en Cloudflare.

Elige paquetes interactivamente con bun update -i

Desde Bun 1.3, el selector interactivo está integrado. Esto reemplaza el workaround bunx npm-check-updates -ui que esta guía solía recomendar.

bun update -i

Obtienes una lista de dependencias directas desactualizadas agrupadas por dependencies, devDependencies, peer y optional, con columnas Current, Target y Latest. Target es la subida dentro de rango, Latest es la publicada más nueva. Código de color: rojo para major, amarillo para minor, verde para patch.

Teclas que vale la pena conocer:

La tecla l es la que la gente se pierde. Te permite llevar la mayoría de paquetes dentro de rango y empujar uno solo arriesgado hasta latest, en una pasada. (Notas de Bun 1.3.)

bunx npm-check-updates -t minor -u

Verifica: como siempre, git diff package.json bun.lock, luego tu build.

Actualizaciones dirigidas: paquetes únicos, globs y deps transitivas

Raramente necesitas “todo o nada”. Las actualizaciones por nombre manejan los casos quirúrgicos:

bun update zod           # zod everywhere it appears, including transitively
bun update caniuse-lite  # patch a nested/transitive dep
bun update '@types/*'    # glob

Dos detalles que cambiaron en Bun 1.4 e importan en proyectos reales (notas de versión):

1. bun update pkg ahora actualiza ese paquete en todos los sitios donde aparece, incluyendo ocurrencias transitivas, no solo la entrada de nivel superior. Eso es lo que quieres para una corrección de seguridad enterrada tres niveles abajo.
2. Las dependencias de catálogo (catalog: en workspaces) también se reescriben.

Una actualización dirigida de un paquete que no está en tu package.json - el caso caniuse-lite - arregla el lockfile sin añadir una dependencia a tu manifiesto. Esa es la herramienta correcta para “mi dep transitiva tiene un advisory y no puedo esperar a que suba el padre”.

Monorepos: --recursive y --filter

bun outdated -r                  # all workspaces
bun update -r                    # update every workspace
bun update --filter web          # just the web workspace
bun update -r --latest           # cross majors everywhere (careful)

Tras una gran pasada multi-workspace, limpia:

bun dedupe     # collapse duplicate versions in the lockfile
bun prune      # drop packages not in package.json (new in 1.4)

Actualiza paquetes globales con bun update -g

Las herramientas globales son una historia aparte de las dependencias del proyecto. Nada aquí toca el package.json de ningún proyecto.

bun update -g

bun update -g typescript

bun add -g typescript@latest

Las globales viven en ~/.bun/install/global. Un bun add -g pkg fresco a veces es más limpio que una actualización cuando una herramienta cambió su layout de bin entre majors.

Modos de fallo: “command not found” tras una actualización global normalmente significa que el directorio shim falta en tu PATH (~/.bun/bin). Y recuerda que el proyecto gana: si un proyecto tiene una instalación local de la misma herramienta, bun run usa la local aunque exista una global más nueva.

Cómo reescribe bun update package.json y bun.lock

Esta es la sección para la búsqueda “bun update package.json”. La mecánica es simple una vez vista:

• Actualización dentro de rango sube el suelo del rango y preserva el operador. ^1.1.0 se convierte en ^1.2.0, ~1.1.0 se convierte en ~1.1.5. Nada cruza un major.
• --latest reescribe cruzando majors a un rango del mismo estilo: ^1.1.0 se convierte en ^2.0.0 si 2.0.0 es lo más nuevo.
• Fijados exactos y dist-tags se quedan como están escritos salvo que pases --latest.
• --no-save actualiza solo node_modules. package.json y el lockfile no se mueven. Útil para un experimento local rápido que piensas revertir.

En el lado del lockfile: el bun.lock basado en texto reemplazó al binario bun.lockb en Bun 1.2, y Bun automigra el formato viejo. Desde 1.3 también migra yarn.lock y pnpm-lock.yaml al instalar, así que mover un proyecto a Bun no significa escribir un lockfile a mano.

Antes y después, todo el cambio puede verse así:

-    "ms": "^2.1.0"
+    "ms": "^2.1.3"

Si necesitas subidas por etapas - toma los minors ahora, los majors el próximo sprint - ese es el único caso de uso que queda para npm-check-updates:

bunx npm-check-updates -t minor -u

Actualizaciones por seguridad: bun audit y bun audit fix

Las actualizaciones de dependencias no son solo por funciones. bun audit lista advisories conocidos contra tu árbol:

bun audit

Desde Bun 1.4.0, puedes actuar sobre el informe directamente (notas de versión):

bun audit fix --dry-run   # preview first
bun audit fix             # upgrade vulnerable packages to safe versions
bun audit fix --latest    # allow major jumps when the fix requires one

Eso elimina el viejo bucle de “audit, abre el advisory, edita rangos a mano” para la mayoría de casos.

Dos notas de hardening sobre las que vale actuar:

1. Retén los paquetes recién publicados. Bun soporta una antigüedad mínima de release, así que una versión secuestrada o maliciosa recién publicada nunca se instala el día cero:

# bunfig.toml
[install]
minimumReleaseAge = 604800   # 7 days, in seconds

El equivalente CLI es --minimum-release-age. (Notas de Bun 1.3.)

2. Los paquetes parcheados son retenidos por bun update. Si usaste bun patch y tienes patchedDependencies, una actualización normal no moverá ese paquete - descartaría silenciosamente tu parche. --latest y bun audit fix sí lo moverán, lo que significa que necesitas recrear el parche después.

Cadencia de ops: nada de esto cuesta dinero. La herramienta es Bun más el registry público de npm. Lo que paga es el hábito: un bun outdated -r && bun update semanal, o Dependabot/Renovate en el repo con bun.lock en el commit. Actualizaciones pequeñas y frecuentes son un trabajo de un café. Las actualizaciones anuales son un incidente.

Verifica la actualización y haz rollback si hace falta

Una actualización que no has verificado es solo un lockfile modificado. Cuatro pasos, cada vez:

Si te importa el tiempo de build - y tras una subida de dependencias correrás builds más de lo normal - mira nuestro benchmark de builds de Astro 7. Una vez el build está en verde otra vez, la optimización de velocidad de build de Astro es el siguiente paso que paga en cada ciclo de actualización posterior.

Rollback

Como commiteaste primero:

git restore package.json bun.lock
bun install

Si estás a mitad de rama y quieres revertir una sola dependencia en vez de toda la pasada:

bun update zod@3.22.4     # pin back to the old version

¿Sin git? Guarda copias de package.json y bun.lock antes de empezar. Esa es toda la estrategia de backup; no hay estado oculto en ningún otro sitio.

Nota de coste/ops: las actualizaciones son gratis. Los despliegues rotos no. Corre esto en una rama, deja que CI lo buildee, luego mergea. Diez minutos de pipeline le ganan a un rollback en producción.

FAQ: actualizar paquetes con Bun

git diff package.json bun.lock   # always check after updating

bun update           # in-range
bun update --latest  # cross-major

bun upgrade && bun --version

bun update -g

bun update --latest   # the one you wanted

Conclusiones

El flujo 2026 es corto: bun upgrade, bun outdated, luego bun update / bun update -i / bun update --latest dependiendo de cuánto churn quieras. Verifica con git diff y bun install --frozen-lockfile, y haz rollback con git restore package.json bun.lock && bun install cuando el build se queje.

Dos correcciones a consejos antiguos que vale la pena mantener: bun update sí reescribe package.json, y --force no es el flag de “dame las últimas versiones” - lo es --latest. Con eso claro, las herramientas integradas de Bun cubren todo el trabajo de actualización sin npm-check-updates ni ningún otro wrapper.

Si estás empezando un proyecto desde cero, crea un blog Astro gratis en Cloudflare y corre este bucle de actualización en él desde el día uno.