Bun 1.4: Funciones integradas que pueden reemplazar a sharp, Puppeteer, node-pty y más
Un recorrido práctico por las funciones integradas de Bun 1.4 para imágenes, navegador, Markdown, cron, terminal, scripts en paralelo y pruebas, además de cómo probarlas de forma segura en proyectos reales.
Un proyecto típico de JavaScript acumula una dependencia para cada funcionalidad que necesita: sharp para imágenes, un analizador de Markdown, Playwright o Puppeteer para la automatización del navegador, una biblioteca de cron, node-pty para pseudo-terminales, concurrently o npm-run-all para scripts en paralelo, y una serie de configuraciones de CI para acelerar las pruebas. Bun 1.4 adopta un enfoque diferente: muchas de estas tareas pueden realizarse directamente dentro del entorno de ejecución. Esta guía explica los nuevos componentes integrados con los fragmentos de código necesarios para probar cada uno, y sugiere una forma de bajo riesgo para evaluarlos.
Según el anuncio de lanzamiento, Bun 1.4 se distribuyó el 20 de agosto de 2026, incorporando más de 1,500 pruebas de compatibilidad con Node.js, resolviendo más de 2,900 problemas y reduciendo el uso inactivo de CPU y memoria. Las APIs de esta nueva versión aún pueden cambiar, por lo que considere los detalles a continuación como una instantánea y confírmelos consultando el anuncio oficial de Bun 1.4 y la documentación actual. El enfoque de este lanzamiento no es tanto la velocidad bruta como reducir el conjunto de herramientas necesario.
Instalación o actualización
Bun puede instalarse mediante un script de shell, npm, Homebrew, PowerShell en Windows o como imagen Docker. Cada línea etiquetada a continuación representa una alternativa; elija la que se adapte a su entorno:
--curl
curl -fsSL https://bun.sh/install | bash
--npm
npm install -g bun
--brew
brew install oven-sh/bun/bun
--powershell
powershell -c "irm bun.sh/install.ps1 | iex"
--docker
docker pull oven/bun
Si Bun ya está instalado en su máquina, un único comando lo llevará a la última versión disponible:
bun upgrade
Procesamiento de imágenes con Bun.Image
Bun.Image integra en el tiempo de ejecución la decodificación, el redimensionado, la rotación y la codificación de formatos comunes, por lo que ya no se necesita una dependencia de imágenes nativas. La cadena a continuación lee un JPEG, lo ajusta dentro de un cuadro de 1024 por 1024 manteniendo la relación de aspecto, lo rota, lo codifica como WebP con una calidad del 85 y escribe el resultado:
await Bun.file("photo.jpg")
.image()
.resize(1024, 1024, { fit: "inside" })
.rotate(90)
.webp({ quality: 85 })
.write("thumb.webp");
Dado que cada paso devuelve el mismo constructor, la cadena de procesamiento se sigue de arriba hacia abajo como una receta. Los usos típicos incluyen la creación de miniaturas para subidas, el redimensionado de avatares, la conversión de JPEG a WebP, las APIs de imágenes y la optimización de recursos antes de que lleguen al almacenamiento.
Bun indica que su implementación supera a sharp en varios de sus propios tests de rendimiento, incluyendo el redimensionado y la codificación de un PNG en 1080p. La ventaja adicional es la eliminación de un módulo nativo que a menudo complica las compilaciones con Docker y los cachés de CI. Si depende de funciones avanzadas de sharp, verifique que las operaciones que utiliza estén disponibles antes de hacer el cambio.
Automatización de navegadores sin interfaz con Bun.WebView
Bun.WebView es una API de navegador sin interfaz integrada que permite navegar, hacer clics, desplazarse, evaluar JavaScript y tomar capturas de pantalla. Observe la declaración await using: vincula la vida útil de la vista al ámbito que la contiene, de modo que el navegador se libera automáticamente cuando finaliza el bloque, incluso en caso de errores.
await using view = new Bun.WebView({
width: 800,
height: 600,
});
await view.navigate("https://bun.sh");
await view.click("a[href='/docs']");
const title = await view.evaluate("document.title");
await Bun.write(
"page.png",
await view.screenshot()
);
El script abre una página, sigue un enlace, lee el título del documento y guarda una captura de pantalla. Esto abarca muchas tareas pequeñas sin necesidad de utilizar un marco completo de automatización: servicios de captura de pantalla, pruebas básicas, herramientas para extracción de datos, verificaciones de disponibilidad, comprobadores de enlaces y flujos simples de control de calidad. Cuando se necesita un control de nivel más bajo, Bun.WebView ofrece una vía de escape hacia el Protocolo de Chrome DevTools. Para suites integrales a gran escala con requisitos entre navegadores, es probable que una herramienta dedicada siga siendo la opción más adecuada.
Renderizado de Markdown con Bun.markdown
Bun.markdown convierte Markdown a varios formatos de salida. La opción más simple devuelve una cadena HTML:
const html = Bun.markdown.html(
"# Hello **world**"
);
También puede generar elementos React directamente, lo cual es útil cuando un componente muestra una página README o de documentación:
export default function Page() {
return Bun.markdown.react(readme);
}
El renderizado puede personalizarse aún más, por ejemplo para formatear la salida en una terminal. Se admiten extensiones de Markdown al estilo GitHub como tablas, listas de tareas, texto tachado y enlaces automáticos. Esto es adecuado para sitios de documentación, portales de desarrolladores, blogs, visualizadores de README, ayuda en la línea de comandos, bases de conocimiento e interfaces que muestran Markdown generado por modelos.
Hay una advertencia que es más importante que las demás: la salida en HTML no está sanitizada. Cualquier contenido Markdown proveniente de usuarios, terceros o un LLM debe pasar por un sanitizador antes de llegar al navegador; de lo contrario, se corre el riesgo de inyección de scripts.
Tareas programadas con Bun.cron
Bun.cron() funciona en dos modos. En el primero, registra una tarea con el programador de tareas del sistema operativo: crontab en Linux, launchd en macOS y el Programador de tareas en Windows. La llamada acepta una ruta de script, una expresión cron y un nombre de tarea; esta última ejecuta un proceso cada lunes a las 02:30:
await Bun.cron(
"./worker.ts",
"30 2 * * MON",
"weekly-report"
);
Dado que el sistema operativo gestiona la programación, la tarea se ejecuta incluso cuando no hay ningún proceso Bun activo. En el segundo modo, la programación se encuentra dentro del proceso en ejecución, y en este caso se dispara cada cinco minutos. La declaración using detiene la tarea cuando finaliza su ámbito de validez:
using job = Bun.cron(
"*/5 * * * *",
async () => {
await cleanupTempFiles();
}
);
Las ejecuciones nunca se superponen, y se admiten zonas horarias explícitas. Buena candidatos son los trabajos de limpieza, los informes, el mantenimiento de bases de datos, la sincronización de datos, los lotes de correos electrónicos y las consultas periódicas. Tenga en cuenta que los trabajos dentro del proceso desaparecen cuando se reinicia el proceso, y si ejecuta varias réplicas, cada una se ejecutará a menos que agregue mecanismos de coordinación.
Ejecución paralela de scripts
bun run --parallel reemplaza a concurrently y npm-run-all. Pase varios nombres de scripts para ejecutarlos al mismo tiempo:
bun run --parallel build test
Los patrones globales seleccionan un grupo de scripts:
bun run --parallel "build:*"
Combinado con --filter, la misma opción ejecuta un script en todos los espacios de trabajo:
bun run --parallel --filter '*' build
Normalmente, un error detiene todo; --no-exit-on-error permite que las tareas restantes se completen, lo cual es útil para recopilar todos los errores de prueba a la vez:
bun run --parallel --no-exit-on-error --filter '*' test
Cada línea de salida lleva como prefijo el script que la generó, por lo que los registros entrelazados siguen siendo legibles. En un monorepo esto reemplaza una cadena secuencial como la siguiente por tareas distribuidas entre los núcleos de su CPU:
package A → build
package B → build
package C → build
Los ejecutivos en paralelo no comprenden las dependencias entre paquetes, por lo que si un paquete debe compilarse antes que otro, aún se necesita un orden específico o un ejecutor de tareas que modele ese grafo.
Ejecuciones de pruebas más rápidas
bun test cuenta con la bandera --parallel:
bun test --parallel
Puede establecerse explícitamente la cantidad de procesos trabajadores:
bun test --parallel=4
Los archivos se entregan dinámicamente a los procesos trabajadores en lugar de dividirse previamente en lotes fijos, de modo que un archivo lento no deja inactivos a los demás procesos. Tres banderas relacionadas están dirigidas a los entornos de integración continua. El sharding distribuye el conjunto de pruebas entre diferentes máquinas; aquí se muestra la primera de las tres divisiones:
bun test --shard=1/3
Ejecutar solo las pruebas afectadas por sus cambios acorta los ciclos de retroalimentación local:
bun test --changed
Registrar las duraciones permite que ejecuciones posteriores equilibren el trabajo utilizando datos de tiempo reales:
bun test --timings=timings.json
La ejecución paralela expone pruebas que comparten estado, como una base de datos común, puertos fijos o archivos temporales. Espere tener que solucionar algunos problemas de aislamiento la primera vez que lo active.
Corrección de dependencias vulnerables
El mantenimiento de la seguridad cuenta con una orden integrada:
bun audit fix
Actualiza los paquetes vulnerables a versiones corregidas e instálalas. Cuando una corrección requiere un aumento de versión mayor, Bun lo informa en lugar de aplicarlo; agregue --latest para activarlo. Revise esas actualizaciones mayores como cualquier cambio que pueda romper funcionalidades. En CI, esto integra la seguridad de las dependencias en el paso normal de instalación.
Eliminación de dependencias duplicadas
Los proyectos grandes suelen contener varias versiones casi idénticas de un mismo paquete:
esbuild@0.15.10
esbuild@0.15.11
Cuando una sola versión satisface todos los requisitos, este comando elimina las duplicadas:
bun dedupe
La variante de verificación falla con un error cuando quedan duplicadas, lo que la convierte en una puerta de control CI natural:
bun dedupe --check
Menos duplicadas significan árboles de dependencias más pequeños, instalaciones más rápidas, menos uso de disco, mantenimiento más sencillo y posiblemente despliegues más reducidos.
Control de programas interactivos con Bun.Terminal
Bun.Terminal es un pseudo-terminal integrado que permite a JavaScript controlar programas interactivos como estos sin necesidad de node-pty:
bash
vim
htop
Un pseudo-terminal es importante porque estos programas se comportan de manera diferente al detectar un terminal real: muestran interfaces a pantalla completa, utilizan colores y esperan entradas de teclado. Por eso Bun.Terminal resulta relevante para herramientas de desarrollo, CLIs, paneles de control de terminal, herramientas de desarrollo remoto, automatización interactiva y agentes de programación con IA, los cuales cada vez más trabajan directamente en una shell.
Compatibilidad con Node.js y Next.js
El cambio con el impacto más significativo podría ser la compatibilidad y no alguna nueva API. La versión añade 1,517 pruebas para Node.js y reporta mejoras en módulos como http, fs, stream, cluster, timers, zlib y vm. También destaca una mejor compatibilidad en varias categorías: frameworks (Next.js 16, Nuxt, Fastify), herramientas de pruebas (Vitest, Playwright, Testcontainers), soluciones de observabilidad (OpenTelemetry y dd-trace de Datadog) y clientes de datos o infraestructura (TypeORM, RabbitMQ y AWS S3).
La opción --bun obliga a la interfaz de línea de comandos de una herramienta a ejecutarse bajo Bun en lugar del binario de Node.js indicado en su shebang. Según la versión publicada, esto funciona con Next.js 16.3, Turbopack y el React Compiler:
bun --bun next build
La adopción depende, en última instancia, de si su aplicación actual sobrevive al cambio, por lo que una compilación exitosa de su propio proyecto vale más que cualquier prueba de rendimiento publicada.
Afirmaciones sobre el rendimiento en contexto
Las pruebas de rendimiento de Bun para la versión 1.4 muestran un uso de CPU en estado inactivo hasta cinco veces menor, un consumo de memoria significativamente más bajo en cargas de trabajo HTTP y un inicio más rápido en Linux y Windows. Se trata de cifras proporcionadas por el fabricante, por lo que deben interpretarse como orientativas. Un menor uso de CPU, memoria y tiempo de inicio puede traducirse en servicios más económicos y rápidos, pero solo sus propias cargas de trabajo pueden confirmarlo. Para una visión más amplia de los compromisos en cuanto al rendimiento, consulte nuestra comparación de Node.js, Deno y Bun.
Una forma de bajo riesgo para evaluar Bun 1.4
Mover un sistema de producción en su totalidad rara vez es una decisión sensata. Los experimentos pequeños y reversibles funcionan mejor.
Iniciar una nueva API
Cree un esqueleto para el proyecto y construya un servicio pequeño con Bun.serve:
bun init
Sustituir un flujo de trabajo de imágenes
Transfiera una única pipeline de sharp a Bun.Image y compare la calidad de salida y el tiempo de ejecución.
Mover una tarea programada
Elija un trabajo cron simple y reimplímenlo con Bun.cron().
Paralelizar las pruebas
Ejecute el conjunto de pruebas existente en paralelo y observe qué pruebas fallan debido al estado compartido:
bun test --parallel
Limpiar las dependencias
Pruebe los comandos de seguridad y deduplicación en una rama y revise la diferencia:
bun audit fix
bun dedupe
Construir su aplicación Next.js con Bun
Ejecuta la compilación de producción con el entorno ejecutivo de Bun y compárala con tu pipeline actual:
bun --bun next build
En todos los casos, mide los resultados en lugar de confiar en pruebas de rendimiento publicadas.
La tendencia a la consolidación
Bun 1.4 se centra menos en una lista de nuevas API que en un único entorno ejecutivo que asume las funciones que antes pertenecían a paquetes separados. La estructura general es una capa de entorno ejecutivo con las API de Node.js, una capa de herramientas que abarca pruebas, scripts, seguridad, CI y terminales, y una capa de bibliotecas para imágenes, Markdown, navegadores y cron:
Bun 1.4
│
┌─────────┼──────────┐
│ │ │
Runtime Tooling Libraries
│ │ │
Node.js Testing Image
APIs Scripts Markdown
Security Browser
CI Cron
Terminal
El ecosistema npm adquirió su poder al combinar miles de paquetes pequeños, pero ese poder conlleva costos en dependencias, configuración, trabajo de compatibilidad, actualizaciones de seguridad y herramientas fragmentadas. Bun apuesta por lo contrario: incluye primitivas útiles directamente dentro del entorno ejecutivo.
Puntos clave
- La pregunta importante ya no es “¿Es Bun más rápido que Node.js?”, sino “¿Qué partes de mi stack podría reemplazar Bun?”
- Los componentes integrados reducen las dependencias nativas, pero verifica la paridad de funcionalidades antes de reemplazar bibliotecas consolidadas como
sharpo Playwright. - Sanitiza la salida HTML generada por
Bun.markdownsiempre que los datos de entrada no sean fiables. - Los scripts y pruebas paralelas son soluciones rápidas, pero pueden revelar problemas ocultos relacionados con el orden de ejecución y el estado compartido.
- Considera los resultados de pruebas de otros proveedores como una hipótesis y valida cada funcionalidad con tus propios cargas de trabajo antes de adoptarla.