Bun v1.0.0: un kit de herramientas todo en uno y rápido para ejecutar, compilar, probar y depurar JavaScript y TypeScript

• Bun 1.0 gestiona la ejecución, compilación, pruebas y depuración de JavaScript y TypeScript en una sola herramienta, y ya está estabilizado y listo para producción
• Con el objetivo de ser un reemplazo de Node.js, admite APIs de Node y resolución de módulos como fs, path, net, __dirname, process y la resolución de node_modules; además, aplicaciones basadas en Express, Koa, Hono y Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart y Vite funcionan en Bun
• La compilación nativa para Windows se ofrece por primera vez, pero es altamente experimental; actualmente solo admite el runtime de JavaScript, y el gestor de paquetes, el runner de pruebas y el bundler están desactivados
• Entre los cambios desde Bun 0.8, se agregó soporte para Next.js, Astro y Nest.js, y se eliminó el comando bun dev, que había quedado obsoleto; ahora ejecuta el script "dev" de package.json
• Entre las nuevas APIs de Node.js compatibles se agregan child_process.fork() e IPC, fs.cp(), fs.cpSync(), fs.watchFile(), fs.unwatchFile() y sockets Unix en node:http
• El runtime incluye un transpilador de JavaScript integrado, lo que permite ejecutar archivos .js, .ts, .cjs, .mjs, .jsx y .tsx sin dependencias adicionales
• Admite ESM y CommonJS al mismo tiempo, por lo que se pueden usar import y require() en el mismo archivo sin depender de la extensión del archivo ni de la configuración "type": "module" en package.json
• Incluye APIs estándar de la Web como fetch, Request, Response, WebSocket y ReadableStream, disponibles sin paquetes como node-fetch y ws
• Con la opción --hot se puede usar hot reloading, y Bun.serve() también queda incluido en el hot reloading
• Las APIs de Bun Bun.file(), Bun.write(), Bun.serve(), bun:sqlite y Bun.password permiten manejar entrada/salida de archivos, servidores HTTP/WebSocket, SQLite, y hashing y verificación de contraseñas con bcrypt y argon2
• El gestor de paquetes ofrece bun install, bun add, bun remove y bun update, y es compatible con npm: lee package.json y escribe en node_modules
• El runner de pruebas bun:test ofrece una API compatible con Jest, y remapea internamente los imports de @jest/globals y vitest a bun:test
• El bundler admite bundling y minificación de JavaScript y TypeScript, y ofrece una API de plugins compatible con esbuild junto con macros de JavaScript, que ejecutan funciones de JavaScript en el momento del bundling para insertar valores inline

[GN⁺]

Opiniones de Hacker News

• Estoy participando en el desarrollo de Bun. Si tienen preguntas, puedo responderlas.
  Sería bueno que los moderadores cambiaran el enlace al post del blog, porque explica mejor que la página de releases de GitHub.
  Post del blog: https://bun.sh/blog/bun-v1.0

  • Lo cambié desde https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0

• Lo que más me impresiona es que se puedan usar import y require() en el mismo archivo, y que no haya que preocuparse por .js/.cjs/.mjs ni por "type": "module".
  Sin esto, el ecosistema de Node.js está casi completamente roto, y parece que Bun podría salvarlo. Creo que lo más increíble de Bun, más que el rendimiento, son las decisiones prácticas y amigables para desarrolladores que Jarred ha mantenido de forma constante.

  • Este problema ya tiene mucho tiempo, y me parece dudoso decir que Bun lo “resolvió” más que otras herramientas.
    Simplemente eligió otro compromiso, y como resultado es probable que otro conjunto de paquetes no funcione. Me gustaría saber si hay alguna base para pensar que Bun resolvió un secreto que otras herramientas no pudieron resolver.
  • Cuando Node propuso dividir la sintaxis, impulsé que se admitiera este enfoque, y me alegra mucho que Bun lo haya adoptado.
    Para mí, esta es la forma correcta. El ecosistema dividido de Node le hizo mucho daño al lenguaje y al runtime en general.
  • Cada ciertos años me toca usar mucho JavaScript, y cuando volví a meterme recientemente, perdí horas por culpa de import vs. require.
    Si no estás usando una app de React o una solución prefabricada, el ecosistema moderno de JS es realmente doloroso, especialmente si estás creando una librería pequeña. No puedo imaginar lo difícil y frustrante que debe ser para quienes empiezan.
    El simple hecho de que Bun resuelva ese problema ya es razón suficiente para probarlo. No pensé que pudiera sentir tanta expectativa por otro runtime o herramienta de build de JS, y gracias al equipo de Bun espero que mi día pueda ser un poco más cuerdo.
  • Desde hace casi un año hago proyectos de módulos por defecto. Después de que en TypeScript 5.0 apareció la estrategia de resolución bundler, los últimos seis meses han sido mayormente buenos.
    Hubo problemas muy ocasionales, pero los he esquivado con pnpm patch y cambios de metadatos hasta que los proyectos los corrigieran. 2023 puede considerarse el año de los módulos, y el agua está bien.
  • Estoy de acuerdo. A estas alturas debería ser experto en JavaScript, pero nada me hace sentir más tonto que navegar por type: module y .js/.cjs/.mjs/.ts.
    En una app de producción obviamente hay que tener claro qué se está usando, pero para prototipar, el comportamiento permisivo de Bun permite escribir código primero y preocuparse por el resto después.

• Me pregunto si no podrían usar una frase mejor que reemplazo directo para un release 1.0 que decidió no implementar todo node:.
  Me decepcionó mucho que los dos primeros proyectos en los que lo probé no fueran reemplazos directos, y ahora desconfío de toda la comunicación de Bun.
  Para dar contexto, ambos proyectos usan osc, que necesita dgram. Encontré un ticket de seguimiento de solicitud de función de hace 9 meses, pero no había planes de implementación, y al buscar dgram en la página de este anuncio no aparece nada.
  Como sugerencia rápida, estaría bien indicar explícitamente los módulos que Bun 1.0 no admite e incluirlos en la sección de compatibilidad con Node.js.
  Edición: encontré la documentación de soporte de Node — https://bun.sh/docs/runtime/nodejs-apis . Sería bueno enlazarla en las notas del release.
  A ojo, parece haber unos 17 módulos implementados, 17 parcialmente implementados y 7 sin implementar.

  • La versión real parece más cercana a 1.0.0-beta que a 1.0.0.
    Acabo de instalar v1.0.0 y ejecuté bun repl, pero falló con código de salida 1; resulta que el REPL intenta usar el puerto 3000 y en mi entorno ya estaba ocupado. Viendo los bugs reportados en GitHub, parece que hay bastantes problemas pequeños de este tipo, así que conviene ser algo escéptico ante todas las afirmaciones.
    Aun así, me impresionan muchísimo la velocidad y el resultado. No esperaba que este proyecto llegara tan rápido hasta aquí; pensé que tomaría mucho más tiempo. En comparación, Deno empezó mucho antes y ahora se siente bastante rezagado, así que pienso usar Bun en proyectos personales.
  • Lo importante no es cuántos son, sino qué módulos son.
    Como anécdota, estamos probando Bun en una aplicación grande con millones de clientes existentes, y hasta ahora el único problema no ha sido Bun en sí, sino que patch-package todavía no admite el archivo de lock bun.lockb.
    Bun es sin duda mucho más rápido que Yarn. Y lo digo como alguien a quien realmente le gusta Yarn.
  • La sección de compatibilidad con Node.js ya dice esto:
    “Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
    En la lista detallada se indican los módulos no admitidos.
  • Estoy de acuerdo con este comentario. Tenía muchas ganas de probarlo, pero no pudo ejecutar la mayoría de nuestros proyectos.
    No pudimos usar AWS SDK v3 porque fallaba al parsear respuestas, y como node:crypto no está completamente implementado, no pudimos usar cosas que dependen de octokit o jsonwebtoken. No existe jest.resetAllMocks(), así que no pudimos correr los tests, y en otro proyecto bun test ni siquiera arrancó porque decía que una llamada a una librería compartida era incorrecta.
    Así que nuestro flujo local es: “intentar ejecutarlo con Bun y, si falla, volver a ejecutarlo con Node”. Al menos podría servir como reemplazo de npm, pero todavía es difícil imaginar usarlo para correr servicios. Cuando funciona, es realmente sorprendente, así que espero con ganas su futuro; pero si el punto de venta es la compatibilidad con Node, me parece difícil llamarlo 1.0.

• Me pregunto si se consideró mover el chat de la comunidad a una plataforma que no sea Discord.
  Discord se ha mencionado varias veces en HN por problemas de accesibilidad, privacidad y dependencia de una plataforma propietaria, y no parece encajar muy bien con el espíritu open source. [1] también vale la pena revisarlo.
  [1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...

  • Aunque sea importante no usar Discord, no parece probable que cambie.
    En los comentarios del anuncio de Bun 0.6, una pregunta similar recibió tantos downvotes que casi fue marcada con flag: https://news.ycombinator.com/item?id=35970869
    En los comentarios del anuncio de Bun 0.8, la misma pregunta casi no recibió atención, y la reacción fue más o menos “otros proyectos también lo usan…”: https://news.ycombinator.com/item?id=37244294
  • La accesibilidad de Discord ha mejorado bastante. Incluso el usuario de lector de pantalla citado en la sección de fuentes de ese artículo está de acuerdo en que la accesibilidad de Discord ha mejorado recientemente y que más personas con discapacidad visual lo están usando.
    Sinceramente, Discord es un buen lugar para que los proyectos de software libre y open source ubiquen su comunicación. Los argumentos del artículo de que “elegir Discord legitima esa plataforma y le quita valor a las plataformas FOSS” parecen bastante débiles. Discord es, de hecho, una plataforma legítima, gratuita, con muchas funciones atractivas y buena accesibilidad. Sobre todo, elegir Discord no hace que desaparezca el valor de las plataformas de comunicación FOSS.
    Lo de “usen IRC” tampoco tiene sentido. IRC es muy difícil de acceder para muchas personas que no están familiarizadas con las computadoras y el software.
  • ¿Existe alguna alternativa FOSS a Discord que no cueste dinero?
  • ¿answeroverflow.com podría servir como solución temporal?

• Bun está financiado con capital de riesgo, así que me da curiosidad su plan de monetización.
  Cuando veo una tecnología nueva, evalúo “qué tan probable es que esta tecnología siga desarrollándose activamente dentro de N años”. Bun tiene que ganar dinero de alguna forma; si no, se quedará sin financiamiento.
  Que la licencia de Bun sea MIT es excelente y da esperanza de que el proyecto no muera aunque la empresa quiebre. Espero que a la empresa le vaya bien, pero si adopto Bun, me pregunto qué tipo de upsell podría aparecer más adelante.

  • El plan de negocio está explicado en https://oven.sh/.
    Oven ofrecerá hosting serverless muy rápido e integración continua para apps JavaScript de backend y frontend, y estará impulsado por Bun.
    Planea dar soporte a frameworks de frontend como Next.js, Vite, SvelteKit y SolidStart, y a frameworks de backend como Express, Fastify y NestJS.
    El plan es operar servidores propios en el edge de centros de datos de todo el mundo, y Oven busca integrar de punta a punta todo el stack de JavaScript hasta el hardware para abrir nuevas posibilidades.
  • Como es un bundler, supongo que ganarán dinero con hosting de apps JS en algo tipo bun deploy.
    Es una estrategia común: primero conseguir adopción masiva entre desarrolladores y luego llevarlos suavemente hacia el hosting de aplicaciones propio.
  • Antes existía un servidor de desarrollo con HMR genial llamado Pundle. Era lo bastante rápido como para sentirse instantáneo, pero también era un proyecto mantenido por una sola persona en un país pobre.
    Sufrí tanto intentando seguirle el paso a un side project de una sola persona que terminé migrando todo a Rollup y no miré atrás.
    Las preocupaciones de un proyecto financiado con capital de riesgo y las de un side project cualquiera son claramente distintas, pero el riesgo final en ambos casos es: “¿qué pasa si quien lo creó no puede darme soporte?”.
  • Creo que probablemente irán por el camino de NextJS/Vercel o Deno/Deploy, y no descartaría un cambio de licencia.
    Es el enfoque de promocionar todo como “open source” para obtener reportes de bugs, contribuciones, marketing y adopción gratis, y luego empujar a la gente hacia un producto comercial.

• La propuesta de poder reemplazar el caos de capas de herramientas basadas en Node es muy atractiva.
  Porque permitiría reducir node, ts-node, nodemon, tsc, jest, ts-jest, webpack, Babel, dos especificaciones de módulos incompatibles entre sí, el caos de UMD, tres gestores de paquetes y la explosión de archivos de configuración que todo eso provoca.
  El ecosistema de herramientas alrededor de JavaScript es sin duda el mayor dolor, y convierte a ES6 + TypeScript, que originalmente es un lenguaje bastante capaz y agradable, en una carga de trabajo tediosa. Espero que Bun lo logre.
  Creo que se sentiría parecido a pasar de CMake a Cargo.

• El post del blog presenta de forma muy convincente la propuesta de valor de un software todo en uno más simple.
  Últimamente me atrae más el software “con baterías incluidas” que el de “trae todo tú mismo”, así que tengo ganas de probar Bun.
  Se siente como la versión en runtime de las herramientas Rome, que intentaban reemplazar varias piezas de software por una sola más rápida. Rome fracasó y pasó a ser OSS con un nuevo equipo. Espero que Bun tenga más éxito, pero claramente es un problema difícil de resolver.

  • Estoy de acuerdo con el enfoque de “baterías incluidas”. Para empezar, si el ecosistema de Node.js hubiera sido armonioso, este enfoque no habría sido necesario.
    Como Apple, cuando eres dueño y controlas directamente el hardware y el sistema operativo, puedes optimizar el sistema en profundidad y también dar la tranquilidad de que todos los dispositivos funcionan de forma fluida. Un conjunto de herramientas todo en uno reduce la carga de andar buscando la solución perfecta y te permite usar la solución que ya tienes enfrente.

• A alguien que haya usado tanto Bun como Deno, me gustaría escuchar cuál de los dos resulta en la práctica el sucesor de Node más convincente.
  El sitio web de Bun afirma que tiene un rendimiento mucho mejor que Deno, y me da curiosidad si en la práctica también es así. Si lo es, también quisiera saber por qué. Deno parece tener objetivos parecidos.
  También me pregunto si hay grandes diferencias filosóficas entre ambos proyectos. Por ejemplo, no sé si Bun intenta reimplementar todo tipo de cosas, mientras que Deno quiere una nueva forma de hacer las cosas después de Node. ¿Hay alguien que haya usado bastante ambos?

  • Ninguno de los dos me atrae demasiado, pero para empezar me pregunto por qué se necesita un sucesor de Node.
    Tanto Bun como Deno son herramientas financiadas con venture capital, así que tengo dudas básicas sobre su monetización y sostenibilidad.
    El principal punto de venta de Bun parece ser el rendimiento, pero no he tenido muchos problemas graves de rendimiento con Node. No es ultrarrápido, pero es mucho más probable chocar con límites de entrada/salida que con la velocidad de Node.
    El principal punto de venta de Deno era ser, en varios sentidos, un “Node bien hecho”, con mejor empaquetado, uso pleno de ES6, etc., y ese argumento me atraía, pero parece que abandonó el intento de crear un ecosistema nuevo y se movió hacia agregar compatibilidad con Node.
    Al mismo tiempo, las mejoras recientes del propio Node, como su test runner nativo y el soporte integrado de .env, son alentadoras. Por eso me cuesta encontrar una razón fuerte para usar Bun o Deno, y aun si cambiara, necesitaría una ruta concreta para volver a Node si las herramientas de nueva generación dejan de ser sostenibles.
  • Estas herramientas son demasiado jóvenes como para decir que alguien las haya usado durante muchísimo tiempo.
    Bun intenta agruparlo todo y hacerlo muy rápido, manteniendo al mismo tiempo la mayor compatibilidad posible con Node. No abandona el ecosistema existente.
    Deno adoptó una postura demasiado confrontativa frente al ecosistema de Node, y ahora está volviendo a agregar soporte.
    Desde el punto de vista de un sucesor, veo a Bun como la única opción, porque intenta innovar con nuevas funciones manteniendo la compatibilidad con Node.
  • No soy un usuario experto y he trabajado principalmente con Deno.
    Deno parece más bien un runtime alternativo a Node que pone la seguridad como principio central, e incluye herramientas como soporte integrado para TypeScript y JSX, y un linter. También está basado en V8. Parece acercarse a la forma en que Ryan Dahl, tardíamente, pensó que Node debería haber sido.
    Bun técnicamente está basado en WebKit, aunque no sé exactamente por qué, y parece no solo un runtime sino una mejor herramienta todo en uno. También ofrece compatibilidad de base con frameworks existentes. Hasta hace poco Deno no era compatible con npm, y me pregunto si desde el principio esa era la intención o si fue un cambio de rumbo en curso.
  • Somos un equipo full-stack de TypeScript y mantenemos unas 50 bibliotecas internas y alrededor de 500.000 líneas de TypeScript.
    El mes pasado probamos tanto Deno como Bun como runtimes alternativos. En resumen, en una base de código con cierta complejidad, Bun casi siempre funciona y Deno casi siempre no.
    Ahora ejecutamos todas las pruebas tanto en Node.js como en Bun, y abandonamos el intento de adoptar Deno.
  • Si mal no recuerdo, Bun no soporta Windows, a diferencia de Node/Deno.
    Edición: parece que eso está cambiando. Gracias por la corrección.

• Originalmente estaba planeado lanzarlo ayer, pero había una prueba fallida de streaming del cuerpo de fetch() que había que corregir.
  La publicación del blog no estaba prevista para hacerse pública hasta que Bun 1.0 estuviera en GitHub, pero el enlace era accesible públicamente y había un bug que no ocultaba los borradores en el feed RSS.
  El bug real no estaba en el streaming del cuerpo de fetch(), sino en los bindings de JavaScriptCore al obtener una propiedad de un objeto en el que esa propiedad podía no estar definida. Parte del código solo verificaba si el valor era un JSCell, sin comprobar si era un objeto; aunque JSCell normalmente es un objeto, cosas como símbolos o BigInt no son JSObject.
  Hilo de ayer: https://news.ycombinator.com/item?id=37424724

  • Sería bueno que actualizaran la sección de instalación de la documentación de Linux, porque faltan DEB/RPM.
    Como pista adicional, para la instalación del tipo “descargar de internet, no desde el repositorio de la distribución”, podrían ofrecer ejemplos de playbooks/conjuntos de tareas de Ansible que incluyan checksums adecuados, como SHA-256. Lo mismo para Puppet, aunque sería un poco más complejo.
    Eso podría aliviar un poco el trabajo de los administradores de sistemas y, si quieren ponerle nombre, podrían llamarlo SAX, es decir, experiencia del administrador de sistemas.

• Si Bun puede ejecutar y empaquetar apps TypeScript React de forma nativa, me pregunto cuál es la ventaja de usar Vite.js encima de eso.
  La guía del sitio oficial muestra cómo usar Bun + Vite.js al crear una app TypeScript React, así que resulta confuso. [1]
  También hay un issue relacionado en GitHub. [2]
  ¿Será que Vite.js se encarga de escenarios más complejos o casos de uso avanzados que Bun no puede manejar? Mi uso de Vite.js se limita básicamente a partir de una configuración TS+React básica y hacer el build, así que quizá se me esté escapando algo.
  [1] https://bun.sh/guides/ecosystem/vite
  [2] https://github.com/oven-sh/bun/issues/250

  • Vite sigue aprovechando Node, esbuild, swc, tsc, etc., para las partes de las que no se responsabiliza directamente.
    Todavía no tengo experiencia usando Bun, pero entiendo que para ejecutar el servidor de desarrollo local se puede usar Bun en lugar de Node; para el bundling, Bun en lugar de esbuild o tsc, Rollup, o alguna combinación de ellos; y para las transformaciones, Bun en lugar de Babel y TypeScript.
    Lo que Vite ofrece es una configuración que facilita el desarrollo de aplicaciones frontend y brinda una buena experiencia de desarrollador durante el trabajo local.
  • Solo he visto usar Vite junto con Bun para HMR.
    Por ahora todavía hay complejidad de configuración, así que no creo que combinarlos sea especialmente bueno.
  • Pedirle a la gente que adopte todo un ecosistema de una sola vez es una carga grande.
    La compatibilidad con el ecosistema existente es un objetivo central de Bun, así que la idea es que la gente pueda empezar a usarlo de inmediato en bases de código existentes e introducirlo gradualmente en más partes.
  • Parece que se podría aprovechar el ecosistema de plugins de Vite, cosas como PostCSS, Tailwind y Terser.
    Además, como la mayoría de los nuevos meta frameworks como Nuxt, SvelteKit, Astro, SolidStart y Qwik corren sobre Vite, esto puede abrir un camino para adoptar Bun.
  • Esto es parecido a preguntar por qué se necesita Vite si ya existe tsc.
    Más que decir que Bun “ejecuta apps TypeScript React”, yo lo vería como que trae de base la transformación JSX/TSX.