El asesino silencioso de dependencias
Bun 1.4, una importante reescritura en Rust, llegó recientemente, introduciendo mucho más que mejoras de rendimiento al runtime de JavaScript. Esta actualización refuerza la posición de Bun como un kit de herramientas todo en uno, con el objetivo de consolidar las utilidades del desarrollador en una plataforma única y cohesiva. Representa un movimiento estratégico hacia un entorno de desarrollo más integrado.
Fundamental para el impacto de Bun 1.4 es su nuevo ejecutor de scripts integrado, que maneja de forma nativa la ejecución paralela y secuencial de scripts en package.json. Esta capacidad hace que herramientas de terceros como concurrently y npm-run-all sean en gran medida obsoletas para muchos proyectos, absorbiendo funcionalidades que antes requerían dependencias externas. Los desarrolladores ahora pueden usar el flag --parallel para ejecutar múltiples scripts simultáneamente.
El ejecutor integrado proporciona características esenciales, incluyendo salida con prefijos para mayor claridad, coincidencia de patrones (glob matching) para la selección de scripts y filtrado de espacios de trabajo. Una opción también permite que otros scripts continúen incluso si uno falla, mejorando la robustez. Este mecanismo interno agiliza flujos de trabajo de desarrollo complejos directamente dentro de Bun.
Esta absorción de herramientas comunes ejemplifica la estrategia más amplia de Bun para simplificar el ecosistema de JavaScript. Al proporcionar alternativas nativas, Bun reduce activamente la hinchazón de node_modules y agiliza la configuración del proyecto, alejándose de las cadenas de herramientas fragmentadas. Ofrece una experiencia de desarrollo más unificada y eficiente.
Libera el poder del paralelismo, de forma nativa
Bun 1.4 introduce un flag nativo --parallel, alterando fundamentalmente cómo los desarrolladores ejecutan múltiples scripts de package.json. Esta mejora elimina la necesidad de herramientas externas como concurrently o npm-run-all, agilizando los flujos de trabajo de desarrollo directamente dentro de Bun. Los usuarios ahora pueden iniciar múltiples servidores de desarrollo o watchers simultáneamente desde un solo comando.
Ejecuta scripts de forma concurrente listándolos después de bun run --parallel. Por ejemplo, bun run --parallel "dev:frontend" "dev:backend" inicia ambas tareas en paralelo. Esto refleja las configuraciones comunes de package.json donde dev:frontend podría iniciar un servidor React y dev:backend una API de Node.js.
Las mejoras en la calidad de vida acompañan a la ejecución paralela. La salida de cada script concurrente incluye automáticamente un nombre con prefijo, aclarando qué proceso generó qué registro. Los desarrolladores también pueden aprovechar la coincidencia de patrones (glob matching); bun run --parallel "dev:*" ejecutará todos los scripts que coincidan con el prefijo dev:, como dev:frontend y dev:backend, sin necesidad de listarlos explícitamente.
Un mayor control está disponible a través de la opción --continue-on-error. Este flag asegura que un fallo no crítico en un script, como un linter reportando errores, no detenga todo el entorno de desarrollo. Otros procesos paralelos, como los servidores de desarrollo activos, continúan ejecutándose sin interrupciones, preservando la continuidad del flujo de trabajo. Esta característica mejora la robustez en configuraciones de desarrollo multiservicio complejas.
Más allá de la concurrencia: controla tu flujo
Bun 1.4 extiende sus capacidades nativas de ejecución de scripts más allá del procesamiento paralelo con la introducción del flag --sequential. Esta característica complementaria establece a Bun como un gestor de tareas (task runner) completo e integrado, eliminando la necesidad de paquetes npm externos para gestionar flujos de trabajo de scripts complejos.
El flag --sequential asegura que las tareas se ejecuten en un orden definido, lo cual es crítico para numerosos escenarios de desarrollo y despliegue donde existen dependencias entre pasos. Los casos de uso específicos incluyen:
- Ejecutar migraciones de base de datos hasta su finalización antes de que inicie un servidor.
- Ejecutar un proceso de compilación en su totalidad antes de iniciar una suite de pruebas.
- Realizar operaciones de carga de datos secuenciales donde la integridad de los datos depende de inserciones ordenadas.
Bun mantiene una experiencia de desarrollador consistente tanto en operaciones paralelas como secuenciales. Los desarrolladores aprovechan la misma sintaxis elegante de scripts en package.json, beneficiándose de una salida clara y prefijada que atribuye los registros directamente al script de origen, mejorando la depuración y el monitoreo.
Esta consistencia se extiende a capacidades de filtrado avanzadas, permitiendo un control preciso sobre qué scripts se ejecutan dentro de un workspace, lo cual es particularmente útil en entornos de monorepo. Para obtener información completa sobre estas opciones de filtrado, consulte bun --filter | Bun Docs. El flag --sequential de Bun, junto con --parallel, proporciona una orquestación de scripts nativa y robusta, simplificando la configuración del proyecto y reduciendo significativamente la dependencia de herramientas como concurrently o npm-run-all.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
El superpoder del monorepo: filtrado de Workspace
Bun 1.4 introduce el flag --filter, una mejora significativa para la gestión de monorepo. Esta característica permite a los desarrolladores apuntar a paquetes específicos dentro de un workspace al ejecutar scripts, agilizando directamente los flujos de trabajo de proyectos complejos. Aborda un desafío de larga data en entornos de desarrollo a gran escala, yendo más allá de la ejecución genérica de scripts.
Anteriormente, coordinar comandos a través de numerosos subpaquetes a menudo requería scripts de shell personalizados o configuraciones de herramientas intrincadas con utilidades externas como Lerna o Nx. Con --filter, Bun simplifica este proceso de forma nativa, integrando la conciencia del workspace en su núcleo. Por ejemplo, para ejecutar pruebas únicamente para un servicio backend específico, los desarrolladores ejecutan bun run test --filter=@my-app/backend.
Este comando apunta directamente al paquete @my-app/backend, aislando la ejecución de pruebas sin iniciar operaciones en componentes del proyecto no relacionados. La capacidad se extiende más allá de las pruebas, aplicándose a comandos de compilación, lint o servidores de desarrollo en todo el workspace. Proporciona un control granular y eficiente sobre las operaciones de múltiples paquetes.
El flag --filter reduce drásticamente la dependencia de soluciones de scripting personalizadas, que se vuelven difíciles de mantener y depurar a medida que los proyectos escalan. Esta integración nativa consolida la utilidad de Bun para organizaciones que gestionan bases de código extensas y dependencias complejas. Posiciona a Bun 1.4 como un ejecutor de tareas robusto y todo en uno para workspaces de nivel empresarial.
Preguntas frecuentes
¿Qué hay de nuevo en Bun 1.4 para ejecutar scripts?
Bun 1.4 introdujo soporte nativo para ejecutar scripts de package.json en paralelo (--parallel) o secuencialmente (--sequential), eliminando la necesidad de paquetes de terceros como concurrently o npm-run-all.
¿Cómo maneja los errores el ejecutor de scripts de Bun?
Por defecto, si un script falla, todos los demás se terminan. Sin embargo, puede usar un flag para permitir que los otros scripts continúen ejecutándose incluso si uno encuentra un error, lo cual es útil para entornos de desarrollo complejos.
¿Puedo ejecutar scripts para paquetes específicos en un monorepo con Bun?
Sí, Bun incluye un flag --filter que le permite apuntar a paquetes específicos dentro de un workspace (monorepo), permitiendo una ejecución precisa de comandos en todo su proyecto.
¿Bun solo admite scripts paralelos?
No, Bun admite tanto la ejecución de scripts en paralelo como de forma secuencial. El flag --sequential ejecuta los scripts uno tras otro, ofreciendo la misma salida con prefijos y capacidades de filtrado que el ejecutor en paralelo.
¿Por qué se hace referencia a Bun 1.4 como una reescritura en Rust?
La transcripción del video menciona a Bun 1.4 como una 'reescritura en Rust', lo que indica un cambio arquitectónico significativo donde partes importantes del runtime fueron reescritas en el lenguaje de programación Rust para mejorar el rendimiento y la seguridad.