Bun vient de tuer Concurrently.

Bun 1.4, une réécriture majeure en Rust, vient de sortir, apportant bien plus que de simples améliorations de performance au runtime JavaScript. Cette mise à jour renforce la position de Bun en tant que boîte à outils tout-en-un, visant à consolider les utilitaires de développement au sein d'une plateforme unique et cohérente. Cela représente une avancée stratégique vers un environnement de développement plus intégré.

Au cœur de l'impact de Bun 1.4 se trouve son nouveau lanceur de scripts intégré, qui gère nativement l'exécution parallèle et séquentielle des scripts package.json. Cette capacité rend des outils tiers tels que concurrently et npm-run-all largement obsolètes pour de nombreux projets, en absorbant des fonctionnalités qui nécessitaient auparavant des dépendances externes. Les développeurs peuvent désormais utiliser le flag --parallel pour exécuter plusieurs scripts simultanément.

Le lanceur intégré fournit des fonctionnalités essentielles, notamment une sortie préfixée pour plus de clarté, la correspondance par glob pour la sélection de scripts et le filtrage d'espaces de travail. Une option permet également aux autres scripts de continuer même si l'un d'eux rencontre une erreur, améliorant ainsi la robustesse. Ce mécanisme interne rationalise les flux de travail de développement complexes directement au sein de Bun.

Cette absorption d'outils courants illustre la stratégie plus large de Bun visant à simplifier l'écosystème JavaScript. En fournissant des alternatives natives, Bun réduit activement l'encombrement des node_modules et rationalise la configuration des projets, s'éloignant ainsi des chaînes d'outils fragmentées. Il offre une expérience de développement plus unifiée et efficace.

Bun 1.4 introduit un flag --parallel natif, modifiant fondamentalement la façon dont les développeurs exécutent plusieurs scripts package.json. Cette amélioration élimine le besoin d'outils externes comme concurrently ou npm-run-all, rationalisant les flux de travail de développement directement dans Bun. Les utilisateurs lancent désormais plusieurs serveurs de développement ou observateurs simultanément à partir d'une seule commande.

Exécutez des scripts simultanément en les listant après bun run --parallel. Par exemple, bun run --parallel "dev:frontend" "dev:backend" lance les deux tâches en parallèle. Cela reflète les configurations courantes de package.json où dev:frontend pourrait démarrer un serveur React et dev:backend une API Node.js.

Des améliorations de confort accompagnent l'exécution parallèle. La sortie de chaque script simultané inclut automatiquement un nom préfixé, clarifiant quel processus a généré quel journal. Les développeurs peuvent également tirer parti de la correspondance par glob ; bun run --parallel "dev:*" exécutera tous les scripts correspondant au préfixe dev:, tels que dev:frontend et dev:backend, sans liste explicite.

Un contrôle supplémentaire est disponible via l'option --continue-on-error. Ce flag garantit qu'une défaillance de script non critique, comme un linter signalant des erreurs, n'arrête pas l'ensemble de l'environnement de développement. Les autres processus parallèles, tels que les serveurs de développement actifs, continuent de fonctionner sans interruption, préservant la continuité du flux de travail. Cette fonctionnalité améliore la robustesse dans les configurations de développement multi-services complexes.

Bun 1.4 étend ses capacités natives d'exécution de scripts au-delà du traitement parallèle avec l'introduction du flag --sequential. Cette fonctionnalité complémentaire établit Bun comme un exécuteur de tâches complet et intégré, éliminant le besoin de paquets npm externes pour gérer des flux de travail de scripts complexes.

Le flag --sequential garantit que les tâches s'exécutent dans un ordre défini, ce qui est crucial pour de nombreux scénarios de développement et de déploiement où des dépendances existent entre les étapes. Les cas d'utilisation spécifiques incluent :

• Exécuter les migrations de base de données jusqu'à leur terme avant le démarrage d'un serveur.
• Exécuter un processus de build entièrement avant de lancer une suite de tests.
• Effectuer des opérations de peuplement de données séquentielles où l'intégrité des données repose sur des insertions ordonnées.

Bun maintient une expérience développeur cohérente à la fois pour les opérations parallèles et séquentielles. Les développeurs utilisent la même syntaxe élégante de scripts package.json, bénéficiant d'une sortie claire et préfixée qui attribue les logs directement au script d'origine, améliorant ainsi le débogage et la surveillance.

Cette cohérence s'étend aux capacités de filtrage avancées, permettant un contrôle précis sur les scripts qui s'exécutent au sein d'un espace de travail, particulièrement utile dans les environnements monorepo. Pour des informations complètes sur ces options de filtrage, consultez bun --filter | Bun Docs. Le flag --sequential de Bun, aux côtés de --parallel, offre une orchestration de scripts native et robuste, simplifiant la configuration des projets et réduisant considérablement la dépendance à des outils comme concurrently ou npm-run-all.

Bun 1.4 introduit le flag --filter, une amélioration significative pour la gestion des monorepos. Cette fonctionnalité permet aux développeurs de cibler des packages spécifiques au sein d'un espace de travail lors de l'exécution de scripts, rationalisant directement les flux de travail de projets complexes. Elle répond à un défi de longue date dans les environnements de développement à grande échelle, allant au-delà de l'exécution de scripts génériques.

Auparavant, la coordination des commandes entre de nombreux sous-packages nécessitait souvent des scripts shell personnalisés ou des configurations d'outils complexes avec des utilitaires externes comme Lerna ou Nx. Avec --filter, Bun simplifie ce processus nativement, intégrant la connaissance de l'espace de travail dans son cœur. Par exemple, pour exécuter des tests uniquement pour un service backend spécifique, les développeurs exécutent bun run test --filter=@my-app/backend.

Cette commande cible directement le package @my-app/backend, isolant l'exécution des tests sans lancer d'opérations sur des composants de projet non liés. La capacité s'étend au-delà des tests, s'appliquant aux commandes de build, de lint ou de serveur de développement sur l'ensemble de l'espace de travail. Elle offre un contrôle granulaire et efficace sur les opérations multi-packages.

Le flag --filter réduit considérablement la dépendance aux solutions de script sur mesure, qui deviennent difficiles à maintenir et à déboguer à mesure que les projets évoluent. Cette intégration native renforce l'utilité de Bun pour les organisations gérant des bases de code étendues et des dépendances complexes. Elle positionne Bun 1.4 comme un exécuteur de tâches robuste et tout-en-un pour les espaces de travail de niveau entreprise.

Quoi de neuf dans Bun 1.4 pour l'exécution de scripts ?

Bun 1.4 a introduit la prise en charge native de l'exécution de scripts package.json en parallèle (--parallel) ou séquentiellement (--sequential), éliminant le besoin de packages tiers comme concurrently ou npm-run-all.

Comment l'exécuteur de scripts de Bun gère-t-il les erreurs ?

Par défaut, si un script échoue, tous les autres sont terminés. Cependant, vous pouvez utiliser un flag pour permettre aux autres scripts de continuer à s'exécuter même si l'un d'eux rencontre une erreur, ce qui est utile pour les environnements de développement complexes.

Puis-je exécuter des scripts pour des packages spécifiques dans un monorepo avec Bun ?

Oui, Bun inclut un flag --filter qui vous permet de cibler des packages spécifiques au sein d'un espace de travail (monorepo), permettant une exécution précise des commandes dans tout votre projet.

Bun prend-il uniquement en charge les scripts parallèles ?

Non, Bun prend en charge l'exécution de scripts en parallèle et en séquentiel. L'option --sequential exécute les scripts les uns après les autres, offrant les mêmes capacités de sortie préfixée et de filtrage que l'exécuteur parallèle.

Pourquoi Bun 1.4 est-il qualifié de réécriture en Rust ?

La transcription de la vidéo mentionne Bun 1.4 comme une « réécriture en Rust », indiquant un changement architectural significatif où des parties majeures du runtime ont été réécrites dans le langage de programmation Rust pour améliorer les performances et la sécurité.