Bun hat Concurrently gerade den Garaus gemacht.

Bun 1.4, ein bedeutendes Rewrite in Rust, wurde kürzlich veröffentlicht und führt mehr als nur Performance-Verbesserungen für die JavaScript-Runtime ein. Dieses Update festigt Buns Position als All-in-One-Toolkit, das darauf abzielt, Entwickler-Utilities in einer einzigen, kohärenten Plattform zu konsolidieren. Es stellt einen strategischen Schritt in Richtung einer stärker integrierten Entwicklungsumgebung dar.

Zentral für die Auswirkungen von Bun 1.4 ist der neue integrierte Script-Runner, der die parallele und sequentielle Ausführung von package.json-Skripten nativ handhabt. Diese Fähigkeit macht Drittanbieter-Tools wie concurrently und npm-run-all für viele Projekte weitgehend überflüssig und absorbiert Funktionen, die zuvor externe Abhängigkeiten erforderten. Entwickler können nun das --parallel-Flag verwenden, um mehrere Skripte gleichzeitig auszuführen.

Der integrierte Runner bietet wesentliche Funktionen, darunter präfixierte Ausgaben für mehr Klarheit, Glob-Matching für die Skriptauswahl und Workspace-Filterung. Eine Option erlaubt es zudem, dass andere Skripte weiterlaufen, selbst wenn eines fehlschlägt, was die Robustheit erhöht. Dieser interne Mechanismus optimiert komplexe Entwicklungs-Workflows direkt innerhalb von Bun.

Diese Absorption gängiger Tools verdeutlicht Buns breitere Strategie, das JavaScript-Ökosystem zu vereinfachen. Durch die Bereitstellung nativer Alternativen reduziert Bun aktiv den node_modules-Ballast und optimiert die Projektkonfiguration, weg von fragmentierten Toolchains. Es bietet eine einheitlichere und effizientere Entwicklererfahrung.

Bun 1.4 führt ein natives --parallel-Flag ein, das grundlegend verändert, wie Entwickler mehrere package.json-Skripte ausführen. Diese Erweiterung eliminiert die Notwendigkeit für externe Tools wie concurrently oder npm-run-all und optimiert Entwicklungs-Workflows direkt innerhalb von Bun. Benutzer starten nun mehrere Entwicklungsserver oder Watcher gleichzeitig mit einem einzigen Befehl.

Führen Sie Skripte parallel aus, indem Sie sie hinter bun run --parallel auflisten. Zum Beispiel startet bun run --parallel "dev:frontend" "dev:backend" beide Aufgaben parallel. Dies spiegelt gängige package.json-Setups wider, bei denen dev:frontend einen React-Server und dev:backend eine Node.js-API starten könnte.

Verbesserungen der Lebensqualität begleiten die parallele Ausführung. Die Ausgabe jedes parallelen Skripts enthält automatisch einen präfixierten Namen, der verdeutlicht, welcher Prozess welches Log generiert hat. Entwickler können auch Glob-Matching nutzen; bun run --parallel "dev:*" führt alle Skripte aus, die dem dev:-Präfix entsprechen, wie dev:frontend und dev:backend, ohne dass sie explizit aufgelistet werden müssen.

Weitere Kontrolle ist durch die Option --continue-on-error verfügbar. Dieses Flag stellt sicher, dass ein nicht kritischer Skriptfehler, wie etwa ein Linter, der Fehler meldet, nicht die gesamte Entwicklungsumgebung anhält. Andere parallele Prozesse, wie aktive Dev-Server, laufen ununterbrochen weiter und bewahren so die Kontinuität des Workflows. Dieses Feature erhöht die Robustheit in komplexen Multi-Service-Entwicklungs-Setups.

Bun 1.4 erweitert seine nativen Skript-Ausführungsfähigkeiten über die parallele Verarbeitung hinaus mit der Einführung des --sequential-Flags. Dieses ergänzende Feature etabliert Bun als einen vollständigen, integrierten Task-Runner, der die Notwendigkeit für externe npm-Pakete zur Verwaltung komplexer Skript-Workflows eliminiert.

Das --sequential-Flag stellt sicher, dass Aufgaben in einer definierten Reihenfolge ausgeführt werden, was für zahlreiche Entwicklungs- und Bereitstellungsszenarien, in denen Abhängigkeiten zwischen Schritten bestehen, entscheidend ist. Zu den spezifischen Anwendungsfällen gehören:

• Vollständige Ausführung von Datenbankmigrationen, bevor ein Server startet.
• Vollständige Ausführung eines Build-Prozesses, bevor eine Test-Suite gestartet wird.
• Durchführung sequenzieller Daten-Seeding-Operationen, bei denen die Datenintegrität von geordneten Einfügungen abhängt.

Bun sorgt für eine konsistente Entwicklererfahrung sowohl bei parallelen als auch bei sequenziellen Operationen. Entwickler nutzen dieselbe elegante package.json-Skriptsyntax und profitieren von einer klaren, mit Präfixen versehenen Ausgabe, die Protokolle direkt ihrem ursprünglichen Skript zuordnet, was das Debugging und Monitoring verbessert.

Diese Konsistenz erstreckt sich auf erweiterte Filterfunktionen, die eine präzise Steuerung darüber ermöglichen, welche Skripte innerhalb eines Workspaces ausgeführt werden – besonders nützlich in Monorepo-Umgebungen. Umfassende Informationen zu diesen Filteroptionen finden Sie unter bun --filter | Bun Docs. Buns --sequential-Flag bietet zusammen mit --parallel eine robuste, native Skript-Orchestrierung, die die Projekteinrichtung vereinfacht und die Abhängigkeit von Tools wie concurrently oder npm-run-all erheblich reduziert.

Bun 1.4 führt das --filter-Flag ein, eine bedeutende Verbesserung für das Monorepo-Management. Diese Funktion ermöglicht es Entwicklern, beim Ausführen von Skripten gezielt bestimmte Pakete innerhalb eines Workspaces anzusprechen, was komplexe Projekt-Workflows direkt rationalisiert. Sie adressiert eine langjährige Herausforderung in großen Entwicklungsumgebungen und geht über die allgemeine Skriptausführung hinaus.

Zuvor erforderte die Koordinierung von Befehlen über zahlreiche Unterpakete hinweg oft benutzerdefinierte Shell-Skripte oder komplizierte Tool-Konfigurationen mit externen Dienstprogrammen wie Lerna oder Nx. Mit --filter vereinfacht Bun diesen Prozess nativ und integriert das Workspace-Bewusstsein in seinen Kern. Um beispielsweise Tests ausschließlich für einen bestimmten Backend-Service auszuführen, führen Entwickler bun run test --filter=@my-app/backend aus.

Dieser Befehl zielt direkt auf das @my-app/backend-Paket ab und isoliert die Testausführung, ohne Operationen für nicht zusammenhängende Projektkomponenten zu starten. Die Funktion geht über das Testen hinaus und lässt sich auf Build-, Lint- oder Entwicklungsserver-Befehle im gesamten Workspace anwenden. Sie bietet eine granulare, effiziente Kontrolle über Multi-Paket-Operationen.

Das --filter-Flag reduziert die Abhängigkeit von maßgeschneiderten Skriptlösungen drastisch, deren Wartung und Debugging mit zunehmender Projektgröße schwieriger wird. Diese native Integration festigt den Nutzen von Bun für Organisationen, die umfangreiche Codebasen und komplexe Abhängigkeiten verwalten. Sie positioniert Bun 1.4 als robusten All-in-One-Task-Runner für Workspaces auf Unternehmensebene.

Was ist neu in Bun 1.4 für die Ausführung von Skripten?

Bun 1.4 führte die native Unterstützung für die parallele (--parallel) oder sequenzielle (--sequential) Ausführung von package.json-Skripten ein, wodurch Drittanbieter-Pakete wie concurrently oder npm-run-all überflüssig werden.

Wie geht Buns Skript-Runner mit Fehlern um?

Standardmäßig werden alle anderen Skripte beendet, wenn ein Skript fehlschlägt. Sie können jedoch ein Flag verwenden, damit die anderen Skripte weiterlaufen, selbst wenn eines auf einen Fehler stößt, was für komplexe Entwicklungsumgebungen nützlich ist.

Kann ich mit Bun Skripte für bestimmte Pakete in einem Monorepo ausführen?

Ja, Bun enthält ein --filter-Flag, mit dem Sie bestimmte Pakete innerhalb eines Workspaces (Monorepo) gezielt ansprechen können, was eine präzise Befehlsausführung in Ihrem gesamten Projekt ermöglicht.

Unterstützt Bun nur parallele Skripte?

Nein, Bun unterstützt sowohl die parallele als auch die sequentielle Skriptausführung. Das --sequential-Flag führt Skripte nacheinander aus und bietet dieselben präfigierten Ausgaben und Filterfunktionen wie der parallele Runner.

Warum wird Bun 1.4 als Rust-Rewrite bezeichnet?

Das Videotranskript bezeichnet Bun 1.4 als 'Rust-Rewrite', was auf eine bedeutende architektonische Änderung hinweist, bei der wesentliche Teile der Laufzeitumgebung für verbesserte Leistung und Sicherheit in der Programmiersprache Rust neu geschrieben wurden.