Bowerは消え、npmよ永遠に。Yarnもwebpackも。

フロントエンドプロジェクトで選ばれる依存関係管理ツールとしてのBowerの役割は終わりつつあります。オープンソースプロジェクトとしてのメンテナンスは続いていますが、開発者は非推奨とすることを決め、Yarnやwebpackなど、ほかのソリューションへの移行方法を案内しています。

この記事では、Bowerがかつて優れていた理由と、今では不要になった6つの理由を紹介し、より新しく優れたテクノロジーへ移行する方法を解説します。

Bowerは何に役立っていたのか？

Bowerはnpmのようなパッケージマネージャーです。フレームワーク、ライブラリ、アセット、ユーティリティを管理してインストールし、最新の状態に保ちます。

従来、多くのウェブ開発プロジェクトではnpmとBowerを併用していました。バックエンドの依存関係はnpmで、フロントエンドの依存関係はBowerで管理していました。実際、そもそもBowerをインストールするにはnpmが必要でした。

Bowerがnpmより優れていた主な点は、依存関係グラフがフラットだったことです。npmはパッケージの依存関係を解決し、同じパッケージの重複コピーを含め、数千もの依存パッケージやサブ依存パッケージを自動的にインストールする場合があります。想像できるとおり、これはフロントエンドプロジェクトには好ましくありません。成果物の容量が非常に大きくなる可能性があるためです。

一方、Bowerでは依存関係の管理をユーザーに委ねていました。たとえば、プロジェクト内の多数のライブラリがjQueryに依存している場合、ユーザーはインストールするjQueryのバージョンを選び、そのバージョンをほかのライブラリの依存関係として指定できました。

Bowerの利点は魅力的でしたが、今ではnpm、Yarn、webpackなどのほかのツールがその役割を担っています。また、Bowerには知っておくべき明確なデメリットもあります。

Bowerの利用をやめ、新しいワークフローに切り替えるべき6つの理由

フロントエンドの依存関係管理にBowerを使い続けるのではなく、移行すべき主な理由を紹介します。

1. Bowerは開発者によって非推奨とされた

長く激しいGitHubでの議論を経て、Bowerの開発者は、現在のウェブ開発スタックに価値を加えないとして、プロジェクトを終了すべきだと判断しました。既存ユーザーのためにオープンソースプロジェクトのメンテナンスは続いていますが、このプラットフォームを使い続けない大きな理由の一つです。

2. Bowerで実現できたフラットな依存関係グラフは、今ではnpmやYarnでも利用できる

npm 3ではフラットな依存関係グラフを利用できます。さらに、必要に応じて同じパッケージの複数のバージョンにも対応できます（Bowerではできません）。Yarnを使っている場合は、yarn install --flatコマンドでBowerと同様の効果が得られます（Yarn CLIのドキュメントを参照）。

3. Bowerはnpmを必要とするため、複雑さが増し、機能も重複する

Bowerの実行にはnpmが必要でした。そのため、「すでにnpmを使っているのに、なぜ別のパッケージマネージャーを追加する必要があるのか？」という質問がよく寄せられていました。

多くのユーザーにとって、Bowerはバックエンドとフロントエンドのパッケージを分けて管理するのに役立っていました。しかし、たとえばリポジトリを2つ作成するなど、npmでも同じように分けて管理する方法があります。すでにnpmを使っている人にとって、Bowerは機能が重複するコンポーネントと言えるでしょう。

4. Bowerには独自のパッケージエコシステムがある

モジュール開発者にとって、npmが広く普及していることは大きな利点です。誰もがnpmを使っているため、新しいパッケージを公開すれば、ユーザーが簡単に利用できると確信できます。しかし最近まで、フロントエンドのパッケージ開発者はnpmとBowerの両方にパッケージを公開する必要があり、手間がかかっていました。

5. Bowerは依存関係管理の負担をユーザーに負わせていた

npmの優れた機能の一つは、コードで参照されているパッケージが必要とする依存関係をすべて自動でインストールすることです。これは非常に便利な一方で、複雑さを招き、依存関係地獄として知られる厄介な事態につながる可能性もあります。

Bowerにはこの機能がなく、どのパッケージがどの依存関係を必要とするかを、ユーザーが苦労して定義しなければなりませんでした。これにより依存関係の問題は避けられましたが、ユーザーの手作業が大幅に増えていました。

npmやwebpack、Yarnなどの関連テクノロジーが進歩したことで、依存関係が連鎖する場合も、はるかに簡単に扱えるようになりました。

6. Bowerは同じページで同一パッケージの異なるバージョンをサポートしない

これはまれなケースですが、比較的よくあります。Bowerでは、同じライブラリを異なる2つのパッケージから、異なるバージョンで参照することはできませんでした。npm 3なら、フラットな依存関係グラフとともに、この機能を標準で利用できます。

現在、パッケージはどのように管理されているのか？

Bowerの利点は、より新しいツールに取って代わられたと説明しました。Nodeパッケージの管理にnpm/Yarnを、静的アセットの管理にwebpackを使う現代的な依存関係スタックによって、Bowerは不要になっています。

• バックエンドとフロントエンドのどちらのパッケージにも、npmが選ばれています。

• Yarnはnpmのフロントエンドとして、いくつかの重要な利点を提供します。依存関係のインストールが高速で、パッケージを特定のバージョンに固定しやすく、セキュリティが強化されているほか、オフラインモードも利用できます。npm 3のリリース以降、こうした利点の一部は以前ほど顕著ではなくなりました。Yarnがワークフローに価値をもたらすか、詳しく検討してみるとよいでしょう。

• webpackはモジュールバンドラー、つまりビルドツールです。ローダーやプラグインを使って、ウェブプロジェクトの静的ファイル依存関係を準備できます。たとえば、複数のCSSファイルをまとめて圧縮し、プロジェクトの一部としてビルドできます。ウェブアプリの構築に使うアセットの多くはNode.jsのコンポーネントではないため、webpackはnpmユーザーにとって重要な不足部分を補います。npmがウェブアプリで使うNodeライブラリをインストールする一方で、webpackはそれ以外の要素を取り込み、準備してインストールできます。

Bowerから、より現代的で柔軟なスタックに移行する方法を解説した優れたリソースがすでにいくつかあります。Anrejs Abrickisによる優れた記事や、Bowerの開発者Adam Stankiewiczによる公式記事などです。

まとめ

現在利用できるフロントエンドライブラリやフレームワークは複雑に入り組んでいるため、フロントエンドの依存関係管理にパッケージマネージャーを使うことが不可欠です。

Bowerは、フロントエンド開発者が依存関係を管理する方法の改善に重要な役割を果たしました。Bowerがもたらした利点は、後にnpmやYarnへ追加される機能の土台となりました。しかし、今ではBowerが最良の選択肢ではありません。Yarnの登場とnpm 3の変更により、手間をかけずにBowerの利点をすべて得られるようになりました。

npmまたはYarnに移行すれば、開発プロセスを大幅に簡素化できます。現在のツールを使えば、膨大な数のフロントエンドコンポーネントも、これまで以上に簡単に扱えます。