npm、spm、bowerの3つのパッケージマネージャの異同

npmはnodeモジュールのマネージャに属します.spmとbowerはフロントエンドモジュール管理です.この2つの大きな違いは2つあります.
1.NPMはnodeモジュールに対して、元々commonJSをサポートしているが、フロントエンドモジュールはこのマネージャが自分で決めない限り、規範は統一できない.commonJSが規定されていても、必ずパッケージ化して実際の運転を実現します.
2.依存の扱い方が異なる.NPMはnodeモジュールに対して,その依存性は木状である.プロジェクトで使用されるA,B,Cの3つのモジュールは,互いに影響を及ぼさずに異なるバージョンのlodashに依存することができる.しかし、フロントエンドモジュールは、良好なモジュール分離(commonJSが実現され、うまくパッケージ化されている場合でも、フロントエンド環境の特殊性は同じモジュールの異なるバージョンが併存することに耐えられない.例えば、ページに2つのバージョンのjQueryが導入され、コードデータ伝送X 2が導入される)を行わない限り、一般的な依存は扁平である.
一、Bower
Twitterはパッケージ管理ツールを発売した.パッケージ構造に強制的な仕様がないことを特徴とし、bower自体は構築ツールを提供していない.基本的には静的リソースの共有プラットフォームとして機能している.
bower自体はモジュールファイル自体を格納しない(NPMおよびSPMはモジュール作成者のファイルを自分のサーバにパッケージして保存する)、モジュールのバージョン情報も保存しない.モジュールのパブリッシャーは登録を通じて(register)方式では、モジュールのアクセス可能な公開gitアドレスをbowerのデータベースに記録する.すべてのバージョンは、モジュールパブリッシャがコードライブラリのtagを自分で制御することによって決定される.
bowerはインストールプロセスで基本的に登録されたgitアドレスの特定のtag cloneをローカルのbowerに1部渡すと簡単に考えることができます.componentsディレクトリにあります.
bower自体が提供する機能や実装は、価格よりも簡単に見えますが、最も広いフロントエンドモジュール管理ツールを使用しています.githubのプロジェクトには1 w+のstarがあります.bowerがこのように流行しているのは、ゆとりのある規範が多くの既存のプロジェクトに直接応用されているおかげで、誰もが簡単にbowerを追加することができます.jsonおよび補足関連情報は,コードやディレクトリ構造を変更する必要がなく,すぐに登録を用いて自分のモジュールを公開し始める.
二、component
(よし、公式サイトが开かないことに気づいた.私は....)
TJ大神のプロジェクトは、bowerよりも多くの規範とセットツールを提供しています.

commonJS仕様

を使用

それはbowerと同じように、モジュールコードを格納しないで、githubアカウント名/モジュール名の方式を通じてモジュールの識別子として、はい、この言葉の意味はそのモジュールがgithub上にあることであり、さらに、github上にpublicの倉庫を新築する過程は新しいモジュールを発表する過程であり、他のモジュールdownがローカルに着いた後、フォルダとしてユーザー名も付けられます.強迫症のある人にとっては、これは少し狂っていますが、フロントエンドモジュールの再名の問題(例えば、slide、tooltipのようなほとんどの合格したフロントエンド開発が自分で車輪を1回早く通過したコンポーネントは、あまりにも一般的です)

を解決することができます.

プロファイルには、必要な静的ファイルリソースが羅列されているため、ダウンロード中にこのプロファイルをキャプチャしてからgithubのrawインタフェースを介してリストされたファイルをキャプチャします.伝送効率はbower方式よりも効率的である.ダウンしたファイルディレクトリも簡潔になります.

commonJSの使用について言及した以上、パッケージツールcomponent/builderも提供されています.パッケージツールに含まれる内容はここでは詳しく説明しません(「どのような良いフロントエンド構築ツールが推奨されていますか?」このような問題)には、主に2つの特徴があります.

commonJS仕様

に基づく

ES 6向け(はい、componetでES 6の構文を使用できますが、パッケージングツールは互換性があります.これもcomponentが演じたい役割です.「Component is currently a stopgap for ES 6 modules and Web Components」)

Compare component with other solutionsを添付
三、spm 3
Seaとしてjs - A Module Loader for the Web
の生態圏のパッケージ管理ツールは、seajsをめぐって構築され、モジュールのリリース、伝送共有だけでなく、一連の構築ツールも含まれています.
なぜなら、SPM 3の機能をよく見ると、基本的にはbower、compoent、npm、その他の有名なパッケージ管理ツールの利点を吸収しているからです.ここでは、SPM 3のメリットについてお話しします.

SPMから3.XはCommonJSに全面的に迎え始め、CMDを徐々に放棄した.CMDで一番有名な実現者は誰ですか?SeaJS!はい、ここで言いたいのは、CommonJSのサポートでSPMのコミュニティをうまく拡大できる一方で(例えばComponentのモジュールは簡単に移行できる)、SPM 3がパッケージにStandaloneモードを提供しているのを見て、SeaJS

に依存しないということです.

は、NPMのリリースと同様に爽快なフロントエンドモジュール管理プラットフォームです.上記のbowerとcomponent自体はユーザーのモジュールコードを管理していません.モジュールの使用は、開発者自身が倉庫とバージョン(tag)を維持することである.このような問題は、1つのモジュールの実際のバージョンが安定しているかどうかは保証しにくい(同じtagを繰り返して打つことができる)上に、コードが他の人の手に握られている安定性は保証しにくいということである.(componentはgithubを使うのは信頼できるが、bowerというgitソースを限定しないのは難しい).SPMでは

$ spm publish

このようにコードを公開しました.

は、次のような完全な構築プロセスとツールを提供します.

パッケージ

デバッグ

テスト統合

文書生成

支付宝チームメンテナンス(支付宝自身はSPMを使用しているので、このツールは必ず実戦の試練を経ている)、中国語ドキュメント.これらは国内ユーザーにとって重要です.

----------------------まとめ------------------------
bower

の利点:コンストレイントがばらばらで、使用が簡単-->使用可能なモジュールが多い

の欠点:構築ツールが提供されていない(現在はコミュニティからbowerに対する構築ツールを見つけることができるはずである)、bowerに直接モジュールをインストールする安定性は保証しにくい(ソースの安定性、および国内のネットワーク速度の安定性).
しかし、社内で使用する場合は、会社自体のgit倉庫と組み合わせて、プライベートなbower serverを作成し、仕様とパッケージツールをカスタマイズすることもできます.(はい、これは私が前に考えた私の工場内で実施する案です)
component

利点:commonJSに基づいて、比較的完備した構築ツールがあり、ES 6向けであり、命名衝突問題

を解決できる.

欠点:githubに基づいて、ディレクトリにユーザー名が含まれています...

spm

の利点:管理モジュールコード、国内ネットワーク伝送の安定性(これはbowerおよびcomponentに比べて重要な優位性)、完全な構築プロセス、中国語ドキュメント

欠点:モジュール数(現在400以上、componentおよびbowerの4桁に比べて差がある)

転載先:http://www.zhihu.com/question/24414899