Bun: runtime, gestor de paquetes, pruebas y bundler de JavaScript en una sola herramienta

Bun es una toolchain open source todo en uno para JavaScript / TypeScript creada por oven-sh.

No quiere ser solo un reemplazo más rápido de Node.js. Reúne runtime, gestor de paquetes, runner de scripts, test runner y bundler bajo el mismo comando bun. Para desarrolladores frontend y Node.js, su atractivo es claro: menos herramientas, menos espera en instalación y build, y muchas tareas comunes con un solo comando.

Proyecto: https://github.com/oven-sh/bun

Conclusión rápida

Bun encaja mejor con quienes quieren simplificar la toolchain JavaScript.

Puede:

Ejecutar JavaScript, TypeScript, JSX y TSX.
Funcionar como runtime compatible con Node.js.
Reemplazar npm / yarn / pnpm para gestionar paquetes.
Ejecutar scripts de package.json.
Ejecutar pruebas.
Empaquetar código frontend o backend.
Usar bunx para ejecutar comandos de paquetes npm.
Ofrecer API integradas como Bun.serve, bun:sqlite, Bun.sql, Bun.redis y Bun.s3.

Su valor más visible es la experiencia de desarrollo: instalaciones rápidas, arranque rápido, comandos unificados y TypeScript / JSX listos para usar.

Pero Bun no es algo que todos los proyectos deban adoptar de inmediato. Aplicaciones Node.js grandes, proyectos con muchas extensiones nativas y servicios de producción con requisitos altos de estabilidad necesitan validar compatibilidad, build, pruebas y despliegue.

Qué es Bun

Según el README oficial, Bun es un toolkit todo en uno para aplicaciones JavaScript y TypeScript. Se distribuye como un único ejecutable llamado bun.

Su núcleo es Bun runtime: un runtime JavaScript rápido que busca actuar como drop-in replacement de Node.js. Bun está escrito en Zig, se basa en JavaScriptCore y optimiza arranque y uso de memoria.

Puedes ejecutar directamente:

1

bun run index.tsx

TypeScript y JSX funcionan sin configuración adicional.

El mismo comando bun incluye test runner, script runner, gestor de paquetes compatible con Node.js, bundler y package runner.

Comandos frecuentes:

1
2
3
4


bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

Un proyecto típico puede acabar con node, npm, pnpm, tsx, jest, vitest, webpack, esbuild y ts-node. Bun intenta absorber muchas rutas frecuentes en una sola herramienta.

Instalación

Bun soporta Linux, macOS y Windows en x64 y arm64.

Script oficial:

1

curl -fsSL https://bun.com/install | bash

Windows:

1

powershell -c "irm bun.sh/install.ps1 | iex"

También se puede instalar con npm:

1

npm install -g bun

macOS Homebrew:

1
2


brew tap oven-sh/bun
brew install bun

Docker:

1
2


docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

En Linux hay que mirar la versión del kernel. El README recomienda Linux kernel 5.6 o superior, con 5.1 como mínimo.

Actualizar:

1

bun upgrade

Actualizar a canary:

1

bun upgrade --canary

Canary no suele ser buena opción para producción salvo que estés validando una función nueva o investigando un bug concreto.

Por qué Bun es rápido

La velocidad de Bun viene de varias capas.

Primero, el arranque del runtime es rápido. Muchas herramientas CLI y scripts de desarrollo no están limitados por CPU sostenida, sino por arranque de proceso, carga de módulos, transpilación TypeScript y resolución de dependencias. Bun optimiza esas rutas.

Segundo, la gestión de paquetes es rápida. bun install busca reemplazar los flujos de instalación de npm / yarn / pnpm. Usa caché global y su propio lockfile, lo que puede reducir mucho la espera con muchas dependencias.

Tercero, TypeScript / JSX funcionan sin configuración. Muchos proyectos solo quieren ejecutar un .ts o .tsx; con Node.js tradicional se añaden tsx, ts-node, Babel o un build. Bun puede ejecutarlos directamente.

Cuarto, las herramientas integradas reducen cambios de proceso y configuración. Pruebas, scripts, bundling y ejecución viven en la misma herramienta.

Aun así, “Bun es rápido” no significa que todo proyecto vaya a ser más rápido. Depende de dependencias, lógica de scripts, framework de pruebas, build, uso de API Node.js y caché de CI.

Gestión de paquetes: reemplazar npm / yarn / pnpm

Bun instala dependencias directamente:

1

bun install

Añadir dependencia:

1

bun add react

Añadir dependencia de desarrollo:

1

bun add -d typescript

Eliminar dependencia:

1

bun remove react

Ver por qué existe una dependencia:

1

bun why react

Auditoría de seguridad:

1

bun audit

Si migras desde npm o pnpm, revisa si bun.lock entra en control de versiones, si CI usa bun install --frozen-lockfile, si private registries y .npmrc son compatibles, si workspace se comporta como esperas, si lifecycle scripts introducen riesgo y si un monorepo dependiente de pnpm puede migrar sin fricción.

Los proyectos pequeños pueden probarlo directamente. En monorepos grandes, empieza por un package o un job de CI no bloqueante.

Ejecutar scripts y TypeScript

Bun ejecuta scripts de package.json:

1

bun run start

También ejecuta archivos directamente:

1
2


bun run index.ts
bun run index.tsx

Es útil para scripts como:

scripts/build.ts
scripts/seed.ts
scripts/migrate.ts
scripts/check.ts

Con Node.js, muchas veces hay que resolver loader TypeScript o precompilación. Bun reduce ese pegamento.

Si un script depende de detalles de Node.js, como loaders, frontera ESM/CJS, módulos nativos, child process, file watching o API de borde, sigue necesitando pruebas.

Test runner

Bun incluye test runner:

1

bun test

Encaja en proyectos pequeños que quieren menos configuración Jest / Vitest, y también para mover algunas pruebas unitarias, de herramientas o de librerías a un runner más ligero.

Al migrar pruebas, mira diferencias en expect, mock API, snapshots, entorno DOM, reglas de descubrimiento, cobertura y reportes de CI.

Si el proyecto depende profundamente de Jest, con matchers propios, mocks complejos, jsdom, babel-jest o ts-jest, no conviene migrar deprisa. Puedes usar bun test en módulos nuevos y conservar el framework anterior para lo existente.

Bundling y build

Bun ofrece bundler:

1

bun build ./src/index.ts --outdir ./dist

Puede usarse para bundles frontend, scripts backend, CLI y librerías. La documentación cubre loaders, plugins, macros, CSS, HTML, HMR, minifier y single-file executable.

Buenos candidatos iniciales:

Herramientas frontend pequeñas.
CLI Node.js.
Scripts internos.
Servicios de un solo archivo.
Proyectos sin loaders webpack complejos.

Ten cuidado con cadenas webpack complejas, muchos plugins Vite, transformaciones Babel profundas, pipelines CSS / assets especiales, micro-frontends, module federation y proyectos con requisitos finos de hash, chunks y compatibilidad.

El bundler de Bun es atractivo, pero migrar build suele ser más arriesgado que cambiar el gestor de paquetes. Valídalo por separado.

Ejecutar servicios HTTP

Bun ofrece Bun.serve:

1
2
3
4
5
6


Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

Es práctico para API pequeñas, servicios internos, webhook receivers y servicios con estilo edge. Bun también incluye WebSockets, Workers, Streams, SQLite, PostgreSQL, Redis, S3 y TCP/UDP sockets.

Si ya usas Express, Fastify, NestJS, Next.js, Hono, Elysia u otro framework, revisa primero su compatibilidad con Bun. No hace falta reescribir un servicio solo para usar Bun.

Una ruta realista es usar Bun primero para scripts y paquetes, después para pruebas, y al final evaluar si el runtime de producción debe cambiar. La migración del runtime exige más cuidado porque afecta directamente el comportamiento en producción.

Relación con Node.js

Uno de los objetivos de Bun es ser un drop-in replacement de Node.js, pero compatibilidad no significa equivalencia completa.

El ecosistema Node.js acumula muchos detalles: interoperabilidad CJS / ESM, módulos internos, extensiones nativas, lifecycle scripts de npm, comportamiento de filesystem, stream y Buffer, worker / child_process, debugging y profiling.

Bun mejora rápido, pero la migración a producción debe juzgarse por pruebas.

Preguntas prácticas:

¿Tus pruebas pasan con Bun?
¿Las dependencias clave soportan Bun?
¿Los artefactos de build son equivalentes?
¿CI y local se comportan igual?
¿Hay monitorización y rollback en producción?
¿Docker y despliegue son estables?

Cambiar solo el gestor de paquetes tiene menos riesgo. Cambiar el runtime de producción tiene mucho más.

Proyectos adecuados

Bun encaja bien con proyectos pequeños nuevos en JavaScript / TypeScript, herramientas internas, CLI, CI que necesita instalaciones rápidas, frontend que quiere reducir complejidad, scripts o servicios sensibles al arranque y desarrolladores que quieren TypeScript listo para ejecutar.

Conviene ir con más cautela en monorepos enormes, proyectos atados a pnpm workspace, servicios con muchas extensiones nativas Node.js, builds frontend muy personalizados, backends con exigencias fuertes de consistencia en runtime y suites de pruebas muy dependientes de Jest.

Una estrategia conservadora y útil es usar Bun primero como herramienta de desarrollo, no como sustituto inmediato de todos los runtimes de producción.

Consejos de migración

Para probar Bun en un proyecto existente:

Instala Bun localmente.
Ejecuta bun install y revisa el resultado.
Conserva o commitea bun.lock para evitar confusión con lockfiles.
Prueba bun run <script> con scripts comunes.
Migra pocas pruebas con bun test.
Añade un job Bun no bloqueante en CI.
Si no hay problemas, evalúa cambiar el flujo principal de instalación.
Evalúa la migración del runtime de producción al final.

En equipos, conserva una ruta de rollback. Mantén el flujo npm / pnpm / yarn durante la migración, ejecuta ambos en CI un tiempo, no cambies runtime, gestor, framework de pruebas y bundler en la misma modificación, y divide el proceso en pasos pequeños verificables.

Comandos frecuentes

Instalar:

1

curl -fsSL https://bun.com/install | bash

Actualizar:

1

bun upgrade

Instalar dependencias:

1

bun install

Añadir dependencia:

1

bun add lodash

Ejecutar script:

1

bun run dev

Ejecutar TypeScript directamente:

1

bun run scripts/build.ts

Pruebas:

1

bun test

Bundle:

1

bun build ./src/index.ts --outdir ./dist

Ejecutar comando de paquete:

1

bunx cowsay 'Hello, world!'

Resumen

El valor de Bun no es solo ser “más rápido que Node.js”. Lo importante es que reúne muchas herramientas dispersas del desarrollo JavaScript / TypeScript en un solo comando bun: runtime, gestor de paquetes, runner de scripts, test runner y bundler.

Para proyectos nuevos y herramientas internas, la experiencia integrada puede ser cómoda: instalaciones rápidas, arranque rápido, menos configuración y TypeScript / JSX directos. En proyectos grandes ya existentes, es mejor introducir Bun primero en áreas de bajo riesgo, como instalación, scripts y algunas pruebas, antes de validar build y runtime.

Si la velocidad de instalación, los fragmentos de configuración y el arranque lento de pruebas de la toolchain Node.js te molestan a menudo, Bun merece una prueba seria. Pero la migración de producción vuelve a lo básico: pruebas, compatibilidad, CI estable y rollback.

Referencias: