tooling.report を使用してプロジェクトに最適なビルドツールを選択する

ベスト プラクティスに基づいてビルドツールを選択して構成する。

本日、web.dev は tooling.report という新しいイニシアチブを開始します。ウェブ デベロッパーを対象に、一般的なビルドツールでサポートされている機能の概要を紹介するウェブサイトです。このサイトは、次のプロジェクトに適したビルドツールの選択、あるツールから別のツールへの移行に価値があるかどうかの判断、ツール構成やコードベースにベスト プラクティスを取り入れる方法を検討する際に役立つ情報を提供します。ツールによって重点分野が異なり、ニーズも異なるため、ツールの選択と構成にはトレードオフが伴います。tooling.report の目的は、こうしたトレードオフについて説明し、特定のビルドツールでベスト プラクティスに従う方法を文書化することです。

いかがでしょうか。まずは tooling.report にアクセスするか、Google がこのサイトをどのように開発したかについて以下をお読みください。

ビルドツールが妨げとなることが多い

GoogleChromeLabs では、SquooshProxx などのウェブアプリのほか、Chrome Dev Summit 2019 のようなウェブサイトを構築しています。他のウェブ開発プロジェクトと同様に、通常は、ホスティング環境、フレームワーク、ビルドツールの設定などのプロジェクトのインフラストラクチャについて検討します。インフラストラクチャはプロジェクトが進行するにつれて更新されます。たとえば、採用したフレームワークや手法に対応するために新しいプラグインを追加したり、目的をビルドツールがよく理解できるようにコードの記述方法を変更したりします。このプロセス全体を通して、私たちが選んだツールが最終的に作業を妨げてしまうことがよくあります。

Google のチームは、最適なウェブ エクスペリエンスをユーザーに提供することに注力しており、その結果、フロントエンド アセットの構成と配信方法が微調整されていることがよくあります。たとえば、メインスレッド スクリプトとウェブ ワーカー スクリプトに共有の依存関係がある場合、スクリプトごとに 2 回バンドルするのではなく、依存関係を 1 回ダウンロードします。これをすぐにサポートできるツールもあれば、デフォルトの動作を変更するために多大なカスタマイズ作業が必要なツールもあれば、まったくできないツールもあります。

この経験をきっかけに、さまざまなビルドツールで何ができるのか、何ができないのかを調査しました。次回新しいプロジェクトを開始するときに、自分のプロジェクトに最適なツールを評価して選択できるように、機能のチェックリストを作成したいと考えました。

Google のアプローチ

さまざまなビルドツールを 1 か所で評価、比較するにはどうすればよいか?そのために、テストケースを作成しました。

Google のチームは、ウェブ開発のベスト プラクティスを反映していると考えられるテスト基準について検討し、設計しました。特に、高速で応答性が高く、スムーズなユーザー エクスペリエンスを提供する方法に焦点を当て、2 つの比較できない結果を測定しないように、デベロッパー エクスペリエンスに関連するテストを意図的に除外しています。

テストリストを作成したら、各ツールがテストの成功基準を満たすかどうかを確認するため、ツールごとにビルド スクリプトを作成しました。まず、webpack v4、Rollup v2、Parcel v2 を調査することにしました。多くのプロジェクトでまだこの設定を使用しているため、Browserify と Gulp についてもテストしました。テストに合格するには、一般公開されているツールの機能またはツールのプラグインのみを使用できます。最初のテストセットが作成された後、Google はビルドツールの作成者と協力し、ツールを正しく使用し、公正に表現されるようにしました。

tooling.report のスクリーンショット。

${tool_name} のみを使用していますが、それでも問題ありませんか?

多くのチームにはビルド インフラストラクチャのメンテナンス専任の人物がおり、チームの他のメンバーがビルドツールを選択することは決してないかもしれません。このページが、皆さんが利用するツールに対する期待値を伝える手段として、今でもお役に立てば幸いです。テストごとに、テストが重要な理由の説明と補足情報を記載しています。任意のツールでベスト プラクティスを採用する場合は、そのために必要な構成ファイルがリポジトリのテスト セットアップに含まれています。

サイトに寄付できますか?

現在ない機能をテストする必要があると思われる場合は、GitHub の問題で提案してディスカッションを開始してください。Google は実際のユースケースをカプセル化することを目指しており、これらの成果をより正確に評価する追加のテストを歓迎します。

初期セットに含まれていないツールのテストを作成することも可能です。詳しくは、CONTRIBUTING.md をご覧ください。