兄弟node_modules構造
npmの問題の1つは、 node_modules内の依存関係のツリー構造です。 Windowsでは、これにより生成されるファイルパスが長すぎ、ほとんどのプログラムはそのようなファイルを操作する機能を失いました。 さらに、依存関係の複製:人気のあるライブラリが他のいくつかのライブラリで使用されている場合、各ライブラリは独自のnode_modulesで独自のコピーを受け取りました 。 これは重複排除ユーティリティによって部分的に修正できますが、場合によっては、ファイル記述子が仮想マシンで終了したために、 npmインストールがはるかに早くエラーで失敗しました。
npmの3番目のバージョンでは、ほとんどの依存関係が1つのルートnode_modulesディレクトリにインストールされます。 異なるバージョンのライブラリに対して例外が作成されます:依存関係の調査中にnpmが同じライブラリの複数の異なるバージョンをインストールする必要があると判断した場合、そのうちの1つはnode_modulesのルートディレクトリにインストールされ、残りはローカルnode_modulesにインストールされます。
peerDependenciesは自動的に設定されなくなりました
依存関係を指定するすべての方法の中で、 peerDependenciesは常に際立っていました。 このフィールドを使用して、プラグインの「逆の関係」を指定できます。プラグインが互換性のあるライブラリまたはユーティリティのバージョン。 2つのプラグインがライブラリの互換性のないバージョンを必要とする場合、npmはエラーを報告し、インストールを終了しました。 しかし、1つの不快な瞬間がありました。プラグインのインストール時にライブラリがまだインストールされていない場合、npmはそれを自動的にインストールしました。 さらに、プラグインのnode_modulesディレクトリではなく、より高いレベルに。 一般に、それは論理的ですが、インストールされた依存関係のバージョンが正しくないという不愉快な結果をもたらしました。 3番目のバージョンでは、自動インストールが削除され、警告メッセージに限定されました。 これで、依存関係のリスト内のライブラリの存在は、このリストでプラグインを指定した人によって監視されるはずです。
多段インストーラー
以前のバージョンでは、 preinstallやpostinstallなどのスクリプトフィールドで指定されたスクリプトは、依存関係のインストール中に実行されました。 同時に、「postinstall」の実行中にすべての子依存関係が既にインストールされる保証はありませんでした。 それは多くの問題につながりました。 3番目のバージョンでは、インストールは次の手順に分かれています。
- npmはすべての依存関係をダウンロードします
- preinstallスクリプトはすべての依存関係に対して実行されます
- npmは、ダウンロードした依存関係をnode_modulesディレクトリ(およびバージョンの競合の場合はサブディレクトリ)にインストールします。
- 「postinstall」スクリプトは、インストールされているすべての依存関係に対して実行されます。
この変更により、多数の「長期にわたる」問題を取り除くことが可能になり、インストール中のスクリプトの実行が簡単かつ簡単になりました。 そう願っています。
在庫のささいなこと
3つの大きな変更に加えて、npmの3番目のバージョンには多くの小さな変更があります。 これは、進行状況バーを使用したインストールの進行状況の新しい表示であり、コマンドラインは--only = / --also =を切り替えます。これは--devを廃止し、多くの小さなことを行いました。 リリースセクションで変更の履歴を読むことを強くお勧めします 。 きらめきだけでなく変化を説明する完全に気紛れな女の子のコミュニティマネージャーがいます-彼女は広場でナパームを燃やします。 見て、あなたはそれを好きになるでしょう。
npmの最新バージョンをインストールするには、次のコマンドラインスペルを実行するだけです。
npm install -g npm@3
OSXでは、homebrewを使用してnpmをインストールすると問題が発生する場合があります。 この構成では、スペルが少し異なります。
cd /usr/local/lib/node_modules/npm npm install -g npm@3
2015年11月1日からの更新
約束どおり、node.jsバージョン5.0の新しいリリースでは、npmの3番目のバージョンが使用されます。 現在-ほとんどの開発者: goo.gl/04k5ny