bower
とnpm
の根本的な違いは何ですか?単純でシンプルなものが欲しいだけです。私の同僚の中には、自分のプロジェクトでbower
とnpm
を同じ意味で使っているのを見ました。
すべてのパッケージマネージャには多くの欠点があります。あなたはただ自分と一緒に暮らせるものを選ぶだけです。
npm はnode.jsモジュールの管理を始めました(これがパッケージがデフォルトでnode_modules
に入る理由です)が、 Browserify またはWebPackと組み合わせるとフロントエンドにも有効です。
Bower はフロントエンド専用に作成され、それを考慮して最適化されています。
npmは、汎用のJavaScript(国情報の場合はcountry-data
、フロントエンドまたはバックエンドで使用可能なソート機能の場合はsorts
など)を含め、bowerよりはるかに大きくなります。
Bowerははるかに少ない量のパッケージを持っています。
Bowerはスタイルなどを含みます.
npmはJavaScriptに焦点を当てています。スタイルは別々にダウンロードされるか、npm-sass
やsass-npm
のようなものによって必要とされます。
最大の違いは、npmは依存関係を入れ子にしている(しかしデフォルトではフラットです)のに対し、Bowerはフラットな依存関係ツリー を必要とします(依存関係の解決の負担がユーザーにかかります) 。
依存関係ツリーがネストされているということは、依存関係がそれぞれ独自の依存関係を持つことができるということです。これにより、2つのモジュールが同じバージョンの異なるバージョンを要求しても機能することができます。 npm v3以降、依存ツリーはデフォルトでフラットになり(スペースを節約し)、必要な場所にのみネストします(2つの依存関係が独自のバージョンのUnderscoreを必要とする場合など)。
Yeoman、Grunt、Gulp、JSHint、CoffeeScriptなどの開発者ツールにフロントエンドパッケージにnpmを、npmを使用するというプロジェクトが両方を使用します。
この答えはSindre Sorhusの答えに対する追加です。 npmとBowerの主な違いは、それらが再帰的な依存関係を扱う方法です。単一のプロジェクトでそれらを一緒に使用できることに注意してください。
npm FAQ : (2015年9月6日からのarchive.orgリンク)
依存関係をネストせずに依存関係の競合を回避するのははるかに困難です。これはnpmが機能する方法の基本であり、非常に成功したアプローチであることが証明されています。
Bower ホームページで:
Bowerはフロントエンド用に最適化されています。 Bowerはフラットな依存関係ツリーを使用しており、各パッケージにつき1つのバージョンしか必要としないため、ページの負荷が最小限に抑えられます。
つまり、npmは安定性を目指しています。 Bowerは最小限のリソース負荷を目指します。依存構造を描くと、これがわかります。
午後:
project root
[node_modules] // default directory for dependencies
-> dependency A
-> dependency B
[node_modules]
-> dependency A
-> dependency C
[node_modules]
-> dependency B
[node_modules]
-> dependency A
-> dependency D
見ての通り、それはいくつかの依存関係を再帰的にインストールします。依存関係Aには3つのインスタンスがインストールされています。
Ower:
project root
[bower_components] // default directory for dependencies
-> dependency A
-> dependency B // needs A
-> dependency C // needs B and D
-> dependency D
ここでは、すべての固有の依存関係が同じレベルにあることがわかります。
それでは、なぜnpmを使用するのが面倒でしょうか。
依存関係Bは依存関係Cとは異なるバージョンの依存関係Aを必要とするかもしれません。npmはこの依存関係の両方のバージョンをインストールするので動作しますが、Bowerはあなたにconflictを与えます。 Webページ上の同じリソースは非常に非効率的でコストがかかります。また、重大なエラーを引き起こす可能性があります。インストールしたいバージョンを手動で選択する必要があります。これは依存関係の1つが壊れるという効果をもたらす可能性がありますが、それはあなたがとにかく修正する必要があることです。
ですから、一般的な使い方はあなたのWebページに公開したいパッケージにはBower(例えば、重複を避けるためにruntime)、そしてテスト、構築、最適化、チェックのような他のものにはnpmを使います。など(例:開発時間、重複があまり心配されていない場合)。
npm 3用の更新:
npm 3はそれでもBowerとは違う動作をします。これは依存関係をグローバルにインストールしますが、それが遭遇した最初のバージョンに対してのみです。他のバージョンはツリーにインストールされます(親モジュール、次にnode_modules)。
詳細については、npm 3の docs を読むことをお勧めします。
Bowerはついに 非推奨になりました 。物語の終わり。
SpotifyのJavaScript開発者Mattias Petter Johanssonから :
ほとんどの場合、Bowerの上にBrowserifyとnpmを使うのがより適切です。これは単にBowerよりもフロントエンドアプリケーション用の優れたパッケージソリューションです。 Spotifyでは、npmを使ってWebモジュール全体(html、css、js)をパッケージ化していますが、とてもうまくいきます。
Webのパッケージマネージャとしてのブランド自体を強化する。これが本当であればそれは素晴らしいでしょう - フロントエンド開発者としての私の生活をより良くしたパッケージマネージャは素晴らしいでしょう。問題は、Bowerがその目的のための特別なツールを提供していないことです。それは私がそのnpmがしないことを私が知っているツールを提供しません、そして特にフロントエンド開発者にとって特に有用であるものは何もしません。 フロントエンド開発者がnpmよりもBowerを使用することは、まったく利点がありません。
私たちはbowerの使用をやめてnpmあたりに統合するべきです。ありがたいことに、それが が起こっていることです :
Browserifyやwebpackを使えば、すべてのモジュールを大きな縮小ファイルに連結することが非常に簡単になります。これは、特にモバイル機器にとって、パフォーマンスにとって素晴らしいものです。 Bowerでは、そうではありませんが、同じ効果を得るにはかなり多くの労力が必要になります。
npmはまたあなたにモジュールの複数のバージョンを同時に使用する能力を提供します。あまりアプリケーション開発をしていないのであれば、最初は悪いことに思いつくかもしれませんが、 Dependency hell をいくつか試した後で、1つのモジュールの複数のバージョンを持つことができることに気付くでしょう。かなり気の利いた素晴らしい機能です。 npmには非常に便利な dedupeツールが含まれていることに注意してください 実際に 持っている - 両方の場合 できる 同じバージョンの1つのモジュール、彼らはそうするでしょう。しかし、もし彼らが できない 場合は、あなたはとても便利です。
( Webpack および rollup は、2016年8月現在、Browserifyより優れていると広く認識されています。)
Bowerは単一バージョンのモジュールを維持しています、それはあなたがあなたのために正しい/最良のものを選択するのを助けることを試みるだけです。
モジュールシステムがあり、ローカルで作業しているため、NPMはノードモジュールに適しています。現時点ではグローバルスコープしかないため、ブラウザにはBowerが適しています。また、使用するバージョンについて非常に選択的になりたいと考えています。
私のチームはBowerから離れてnpmに移行しました。
詳細は "なぜ私のチームはbowerの代わりにnpmを使っているのか" を参照。
http://ng-learn.org/2013/11/Bower-vs-npm/からこの便利な説明を見つけました /
一方でnpmは、node.js環境で使用されるモジュール、またはKarma、lint、minifiersなどのnode.jsを使用して構築された開発ツールをインストールするために作成されました。 npmはプロジェクトをローカルに(デフォルトではnode_modulesに)インストールすることも、グローバルにインストールして複数のプロジェクトで使用することもできます。大規模プロジェクトでは、依存関係を指定する方法は、依存関係のリストを含むpackage.jsonというファイルを作成することです。このリストは、npm installを実行するとnpmによって認識され、次にnpm installがそれらをダウンロードしてインストールします。
その一方で、あなたのフロントエンドの依存関係を管理するためにbowerが作られました。 jQuery、AngularJS、アンダースコアなどのライブラリ。npmと同様に、bower.jsonという依存関係のリストを指定できるファイルがあります。この場合、フロントエンドの依存関係は、デフォルトではbower_componentsというフォルダにインストールされるbower installを実行してインストールされます。
ご覧のとおり、これらは似たようなタスクを実行しますが、非常に異なるライブラリのセットを対象としています。
Node.jsを扱う多くの人にとって、bowerの大きな利点は、まったくJavaScriptではない依存関係を管理することです。彼らがjavascriptにコンパイルする言語で働いているなら、npmはそれらの依存関係のいくつかを管理するために使われることができます。しかし、それらのすべての依存関係がnode.jsモジュールになるわけではありません。 javascriptにコンパイルするものの中には、ユーザがソースコードを期待しているときにjavascriptにコンパイルしてコンパイルすることを厄介なオプションにする奇妙なソース言語固有のマングリングを持つものがあるかもしれません。
Npmパッケージ内のすべてがユーザ向けのjavascriptである必要はありませんが、npmライブラリパッケージの場合、少なくともその一部はそうあるべきです。
BowerとNpmは、JavaScriptのパッケージマネージャです。 BowerかNpmを使うべきところに混乱がたくさんあります。いくつかのプロジェクトはNpmとBowerの両方を持っています。ここでは、これら2つのツールの目的について説明しましたが、bowerを使用する場所とnpmを使用する場所がわかるようになります。
Bower
Bowerはフロントエンド開発専用で作成され、それを考慮して最適化されています。フラットな依存関係ツリーを使用し、各パッケージに1つのバージョンしか必要としないため、ページの負荷が軽減されます。これは主に最小限のリソース負荷を目的としています。
Bowerにはbower.jsonという設定ファイルがあります。このファイルでは、Bowerの設定、必要な依存関係、ライセンスの詳細、説明、名前などを設定できます。
Bowerは、jquery、Angular、反応、Ember、ノックアウト、バックボーンなどのフロントエンドパッケージに適しています。
Npm(ノードパッケージマネージャ)
Npmは最も一般的にはNode.jsモジュールの管理に使用されますが、フロントエンドにも機能しますです。これはネストされた依存関係ツリーを使用します。つまり、あなたの依存関係はそれら自身の依存関係を持つことができます。依存関係ツリーがネストされているということは、依存関係がそれぞれ独自の依存関係を持つことができるということです。これは、スペースや待ち時間をあまり気にする必要がないサーバーでは、本当に素晴らしいことです。
私たちのプロジェクトではjQueryが必要なので、これは明らかにフロントエンドではうまくいきません。 jQueryのコピーが1つだけ必要ですが、別のパッケージにjQueryが必要な場合は、jQueryのコピーがもう1つダウンロードされます。これは主要なNpmの欠点の一つです。
Npmにはpackage.jsonという設定ファイルがあります。このファイルでは、必要な依存関係やライセンスの詳細、説明、名前など、Npmの設定を維持できます。 NpmはDependenciesとDevDependenciesを提供します。 DependenciesはJquery、Angularなどのフロントエンドファイルをダウンロードして管理します。 DevDependenciesはGrunt、Gulp、JSHintなどの開発ツールをダウンロードして管理します。
多くのプロジェクトが両方を使用するのは、フロントエンドパッケージにBowerを使用し、Grunt、Gulp、JSHintなどの開発者ツールにNpmを使用するためです