BunがConcurrentlyを完全に置き換えました。

Rustで大幅に書き直されたBun 1.4がリリースされました。これはJavaScriptランタイムに単なるパフォーマンス向上以上のものをもたらします。このアップデートは、開発者向けのユーティリティを単一の統合プラットフォームに集約することを目指す、Bunの「オールインワンツールキット」としての地位を強化するものです。これは、より統合された開発環境に向けた戦略的な動きを象徴しています。

Bun 1.4のインパクトの中心にあるのは、新しい組み込みスクリプトランナーです。これはpackage.jsonスクリプトの並列および逐次実行をネイティブで処理します。この機能により、concurrentlyやnpm-run-allといったサードパーティ製ツールは多くのプロジェクトで不要となり、これまで外部依存関係を必要としていた機能が吸収されました。開発者は--parallelフラグを使用して、複数のスクリプトを並列で実行できるようになりました。

統合されたランナーは、明確なプレフィックス付き出力、スクリプト選択のためのグロブマッチング、ワークスペースフィルタリングなど、不可欠な機能を提供します。また、1つのスクリプトでエラーが発生しても他のスクリプトを継続させるオプションもあり、堅牢性が向上しています。この内部メカニズムにより、複雑な開発ワークフローがBun内で直接効率化されます。

一般的なツールの吸収は、JavaScriptエコシステムを簡素化するというBunの広範な戦略を体現しています。ネイティブな代替手段を提供することで、Bunはnode_modulesの肥大化を積極的に抑え、断片化されたツールチェーンから脱却し、プロジェクト構成を合理化します。これにより、より統一された効率的な開発者体験が提供されます。

Bun 1.4ではネイティブの--parallelフラグが導入され、開発者が複数のpackage.jsonスクリプトを実行する方法が根本的に変わりました。この強化により、concurrentlyやnpm-run-allのような外部ツールが不要になり、Bun内で直接開発ワークフローを効率化できます。ユーザーは単一のコマンドから複数の開発サーバーやウォッチャーを同時に起動できるようになりました。

スクリプトを並列実行するには、bun run --parallelの後にスクリプト名を列挙します。例えば、bun run --parallel "dev:frontend" "dev:backend"とすると、両方のタスクが並列で開始されます。これは、dev:frontendでReactサーバーを起動し、dev:backendでNode.js APIを起動するといった、一般的なpackage.jsonの設定を反映しています。

並列実行には、使い勝手を向上させる改善も含まれています。各並列スクリプトからの出力には自動的にプレフィックス名が含まれるため、どのプロセスがどのログを生成したかが明確になります。また、開発者はグロブマッチングを活用できます。bun run --parallel "dev:*"とすれば、dev:frontendやdev:backendのようにdev:プレフィックスに一致するすべてのスクリプトを、個別にリストアップすることなく実行できます。

さらに、--continue-on-errorオプションで詳細な制御が可能です。このフラグにより、リンターがエラーを報告するような重要度の低いスクリプトの失敗が、開発環境全体を停止させることがなくなります。アクティブな開発サーバーなどの他の並列プロセスは中断されることなく実行され、ワークフローの継続性が保たれます。この機能は、複雑なマルチサービス開発環境における堅牢性を高めます。

Bun 1.4は、--sequentialフラグの導入により、ネイティブスクリプト実行機能を並列処理以外にも拡張しました。この補完的な機能により、Bunは完全な統合型タスクランナーとしての地位を確立し、複雑なスクリプトワークフローを管理するために外部のnpmパッケージを使用する必要がなくなりました。

--sequential フラグは、タスクが定義された順序で実行されることを保証します。これは、ステップ間に依存関係が存在する多くの開発およびデプロイメントシナリオにおいて不可欠です。具体的なユースケースは以下の通りです：

• サーバーが起動する前にデータベースのマイグレーションを完了させる。
• テストスイートを開始する前にビルドプロセスを完全に実行する。
• データの整合性が順序付けられた挿入に依存する、シーケンシャルなデータシード操作を実行する。

Bunは、並列操作とシーケンシャル操作の両方で一貫した開発者体験を維持します。開発者は同じエレガントな package.json スクリプト構文を活用でき、ログがどのスクリプトから出力されたかを直接示す明確なプレフィックス付き出力の恩恵を受けることで、デバッグと監視が向上します。

この一貫性は高度なフィルタリング機能にも拡張されており、ワークスペース内でどのスクリプトを実行するかを正確に制御できます。これは特にモノレポ環境で役立ちます。これらのフィルタリングオプションに関する包括的な情報については、bun --filter | Bun Docs を参照してください。Bunの --sequential フラグは、--parallel と併せて、堅牢でネイティブな スクリプトオーケストレーション を提供し、プロジェクトのセットアップを簡素化し、concurrently や npm-run-all といったツールへの依存を大幅に削減します。

Bun 1.4 では、モノレポ 管理のための重要な機能強化である --filter フラグが導入されました。この機能により、開発者はスクリプト実行時にワークスペース内の特定のパッケージをターゲットにすることができ、複雑なプロジェクトのワークフローを直接効率化します。これは大規模な開発環境における長年の課題に対処するもので、汎用的なスクリプト実行の枠を超えたものです。

以前は、多数のサブパッケージ間でコマンドを調整するために、カスタムシェルスクリプトや、Lerna や Nx といった外部ユーティリティを使用した複雑なツール設定が必要でした。--filter を使用することで、Bunはこのプロセスをネイティブに簡素化し、ワークスペースの認識をコアに組み込みます。例えば、特定のバックエンドサービスのテストのみを実行するには、開発者は bun run test --filter=@my-app/backend を実行します。

このコマンドは @my-app/backend パッケージを直接ターゲットにし、関連のないプロジェクトコンポーネントで操作を開始することなく、テスト実行を分離します。この機能はテストだけでなく、ワークスペース 全体でのビルド、リント、または開発サーバーコマンドにも適用されます。これにより、マルチパッケージ操作に対して粒度の高い効率的な制御が可能になります。

--filter フラグは、プロジェクトの規模が拡大するにつれて保守やデバッグが困難になる、特注のスクリプトソリューションへの依存を劇的に減らします。このネイティブ統合により、大規模なコードベースと複雑な依存関係を管理する組織にとってのBunの有用性が確固たるものとなります。これにより、Bun 1.4 はエンタープライズレベルの ワークスペース に向けた、堅牢なオールインワンのタスクランナーとしての地位を確立しました。

Bun 1.4 でのスクリプト実行における新機能は何ですか？

Bun 1.4 では、package.json スクリプトを並列 (--parallel) またはシーケンシャル (--sequential) に実行するためのネイティブサポートが導入され、concurrently や npm-run-all といったサードパーティパッケージが不要になりました。

Bunのスクリプトランナーはエラーをどのように処理しますか？

デフォルトでは、1つのスクリプトが失敗すると他のすべてのスクリプトが終了します。ただし、フラグを使用することで、1つのスクリプトでエラーが発生しても他のスクリプトを実行し続けることができ、これは複雑な開発環境で役立ちます。

Bunを使用して、モノレポ内の特定のパッケージに対してスクリプトを実行できますか？

はい。Bunにはワークスペース（モノレポ）内の特定のパッケージをターゲットにできる --filter フラグが含まれており、プロジェクト全体で正確なコマンド実行が可能です。

Bunは並列スクリプトのみをサポートしていますか？

いいえ、Bunは並列および逐次スクリプト実行の両方をサポートしています。「--sequential」フラグを使用するとスクリプトが順番に実行され、並列実行時と同様のプレフィックス付き出力やフィルタリング機能を利用できます。

なぜBun 1.4は「Rust rewrite」と呼ばれるのですか？

動画のトランスクリプトでBun 1.4が「Rust rewrite」と言及されているのは、ランタイムの主要部分がパフォーマンスと安全性の向上のためにRustプログラミング言語で書き直されたという、重要なアーキテクチャの変更を指しています。