Node パッケージ管理開発の 5 つの段階について説明する記事-jsチュートリアル-php.cn

2009 年の Node の誕生以来、Node エコシステムは発展し、繁栄してきました。Node エコシステムから派生した Node パッケージマネージャーが隆盛し、npm、kpm、pnpm、yarn、cnpm などが登場しました。次々と現れた。実際、Node パッケージマネージャーの開発は主に 5 つの段階に分かれており、各段階の 主な機能 と 代表的な製品 を見てみましょう~

フェーズ 1: スラッシュアンドバーン

正確に言うと、Node はパッケージマネージャーなしでは存在しませんでした。2009 年に Node.js が登場したとき、 npmのプロトタイプも公開されました。 [関連チュートリアルの推奨事項: nodejs ビデオチュートリアル、プログラミング教育 ]

npm の正式名は Node.js Package Manager で、「Node の簡単な歴史」から引用されています。 js 中に見えます

2009 
Node.js is born 
The first form of npm is created

ログイン後にコピー

Node パッケージマネージャーが表示されなかったときのことを話しましょう。そのとき私がさらにやったことは、

です。
オンラインで探す jQuery などの各ソフトウェアの公式 Web サイト;
ダウンロードアドレスを見つけて zip パッケージをダウンロードします;
これを解凍して、libs ディレクトリというプロジェクトに置きます。
さらに便利にしたい場合は、CDN リンクを HTML

に直接貼り付けます。

当時はモジュール管理?バージョン番号管理?アップグレードに依存しますか？どれも存在しません！

フェーズ 2: ネストされたインストール

2009 年に Node.js が誕生し、npm のプロトタイプも作成されていました。バージョン 1.0 は 2011 年にリリースされました。npm はセマンティックバージョン管理を中心に構築されており、semver の考えに基づいて設計されており、デフォルトでは、Node パッケージ開発者は、依存パッケージのカスタムバージョン番号をアップグレードするときに、semver 仕様に従ってバージョン番号をアップグレードします。

代名詞: ノードパッケージ管理の標準化、node_modules ディレクトリのネストされたストレージ依存関係

代表的な製品: npm v1、v2 バージョン

主な機能:

(1) 依存パッケージのネストされたインストール、同じバージョンの依存関係が重複してインストールされます

(2) 依存パッケージのインストールの不確実性: 最新依存関係パッケージのバージョンはデフォルトでインストールされます (修正バージョンを設定できます)

(3) 依存関係のシリアルインストールが遅い; オフラインキャッシュはサポートされていません

説明 1: 依存関係 ネストされたインストール 、AがBに依存し、BがCに依存する場合、node_modulesディレクトリは次のようになります。

node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js

ログイン後にコピー

問題: ネストされる依存関係が多すぎると、ネスト地獄が発生します。同時に、同じ依存パッケージの冗長インストールが多数存在し、node_modules が大きくなりすぎるため、プログラマは定期的に rm -rf node_modules を実行する必要があります。 Windows システムでは、多くのプログラムは 260 文字を超えるファイルパスを処理できません。名前、npm の初期の Windows ユーザーはこのポップアップウィンドウを見たことがあるでしょう。

説明 2 : npm インストールごとに、依存関係の最新バージョンがデフォルトでインストールされるため、依存関係のインストールが発生します 不確実性 問題:

semver がバージョンを標準化します番号構成: X.Y.Z-[状態]、バージョン番号のアップグレード仕様は次のとおりです。

API ですが下位互換性があり、アップグレードのマイナーバージョン番号
Z はパッチですバージョン番号: 下位互換性のある欠陥修正が行われた場合、
状態は次のようになります: アルファ (内部テスト)、ベータ (パブリックベータ)、ガンマ (完全に成熟したベータ)、rc (プレリリース)

バージョンが不明な理由

: npm のデフォルトのインストール依存関係命令を実行すると、npm は、開発者全員が semver バージョンアップグレード仕様に従い、開発者用の依存関係パッケージの最新バージョンを直接インストールすると考えます

解決策 1: npm config set save-exact true コマンドを使用して、バージョン番号の前の ^ の使用をオフにすることができます。デフォルトの動作

概要: 解決できません依存ライブラリ自体の依存関係の問題、デフォルトで最新バージョンがインストールされる

npm-shrinkwrap.json を生成する Shrinkwrap コマンドを提供します。
すべてのライブラリとすべてのネストされた依存ライブラリの正確なバージョンを記録するファイル

フェーズ 3: フラットインストール

問題を解決するために、2015 年にネストされたインストールと、指定されていないバージョンの npm1 および npm2 が完全に書き直されました。npm プログラムは完全に書き直されました。

#製品を表します:

npm v3 バージョン

原則の簡単な説明: npm をインストールするときは、最初に依存関係ツリーを構築し、次にすべての依存関係をノードモジュールルートディレクトリにインストールします。サブ依存関係が同じ名前の異なるバージョンの依存関係に遭遇すると、それらは独自のノードモジュールの下にインストールされます

主な機能:

(1) 冗長インストールの削減: フラットインストールに依存し、特定の条件下での冗長パッケージのインストールを削減します。状況

既存の問題:

(1) 「幽霊依存」、「幽霊依存」問題

(2) 「見知らぬ双子」、「依存関係パッケージ」「クローン」問題

(3) ディレクトリが固定されていません: 依存関係のインストール順序によって、node_module ディレクトリ構造が決まります

説明 1: 依存関係のインストール順序によって決まります。 node_modules ディレクトリ構造

次のシナリオ: App1 は packageA と packageC、packageG と packageH に依存し、packageA と packageC は両方とも packageB v1.0、packageG と packageH に依存します。どちらも packageB の v2.0 バージョンに依存します

packageA または packageC を最初にインストールする場合、node_modules ディレクトリは次のとおりです

packageG または packageH を最初にインストールする場合、node_modules ディレクトリは次のとおりです。

上記の状況に対応して、npm はディレクトリを手動で整理および簡素化できるコマンド npm dedupe を提供します。 node_modules の構造。node_modules の編成されたディレクトリ構造は一貫性があり、依存パッケージのインストール順序には影響されません。

説明 2: 必ずしも冗長パッケージのインストールが削減されるわけではありません

例 1 を見ると、依存パッケージはフラットにインストールされているにもかかわらず、同じバージョンがまだ存在していることがわかります。依存パッケージには冗長パッケージがあります。

説明 3: 「双子の見知らぬ人」問題

例 1 を参照してください。同じバージョンの依存パッケージが 2 回インストールされ、2 つの場所に配置されます。この現象は「双子の見知らぬ人」と呼ばれます。

説明 4: "ゴースト依存関係" 問題

node_modules 第 1 レベルディレクトリの依存関係開発者はパッケージを直接使用できますが、依存関係パッケージは package.json で定義されていません。このような依存関係パッケージは「ゴースト依存関係」と呼ばれます。フロントエンドプロジェクトで「ゴースト依存関係」を使用すると、後で問題が発生する可能性があります。

この「ゴースト依存関係」は、他の依存関係のアップグレードとともに後で削除される可能性があるため、node_modules には存在しなくなります。npm install を実行すると、「ゴースト依存関係」は主観的にはインストールされません。その結果、プロジェクトは依存パッケージを見つけることができず、エラーを報告します。

フェーズ 4: セキュリティ、高速化

2016 年には、yarn と pnpm のリリース版が次々に登場し、セキュリティ上の不確実性はある程度解決されました。以前のインストールバージョンとインストール速度 npm と比較して、yarn の最初の機能はより目を引くもので、一貫性とセキュリティを確保し、インストール速度を向上させます

同義語: 依存型インストールは比較的安全です。高速化

代表的な製品: yarn リリース版、pnpm リリース版、npm v5 版 (npm v4 はあまり変わっていませんが、v5 は大きく前進しました)

主な機能:

(1) セキュリティ: バージョンロックファイルがデフォルトで生成され、インストールするたびに依存バージョンが同じになることが保証されます

(2) 高速化: オフラインキャッシュの追加インストール、並列インストール、インストール例外後の自動再試行

#(3) ワークスペース: Yarn は v1 バージョンからサポートされ、複数のプロジェクトの依存関係パッケージを効率的に管理できます。 npm v7 はワークスペースのみをサポートします

既存の問題:

(1)ゴースト依存性

(2)単一プロジェクトの繰り返しインストールと、プロジェクト間の依存関係パッケージ

(3) ディレクトリは固定されていません: 依存関係のインストール順序によって、node_module ディレクトリ構造が決まります

説明 1: セキュリティについて

yarn v0.x バージョンが先行し、npm v5.x バージョンが続きます。その後、依存関係をダウンロードするときに、依存関係ロックファイルがデフォルトで生成され、値

npm の .lock ファイル: インストールされている依存関係のバージョンと node_modules ディレクトリ構造を記録します

概要: 異なる端末に依存関係をインストールする必要性を回避します。バージョンの不一致の問題はありますが、「ゴースト依存関係」問題は依然として存在します

説明 2: 速度について改善 - オフラインキャッシュ

npm v2 バージョンはキャッシュをサポートしていますが、キャッシュされた依存関係を使用するにはオンライン検出が必要です

yarn v0.x バージョンは、オフラインキャッシュをサポートする最初のバージョンです。ネットワークはグローバルにキャッシュされます。次回のインストールでは、ローカルでの検索が優先され、見つかった場合は直接コピーされます。

npm v5 バージョンでは、キャッシュシステムが書き換えられ、オフラインインストールもサポートされ、インストール速度が大幅に向上します。

説明 3: 高速化 - 並列インストールについて

yarn は依存関係をサポートした最初のパッケージです。パッケージは並列にインストールされます。以前は、npm は依存関係をシリアルにインストールしていました。その後、npm は並列インストールも最適化しました。

説明 4: 依存関係をインストールすると、node_modules ディレクトリが自動的に編成されます。

開始時刻:yarn v1.x バージョン、npm v4.x バージョン

.lock ファイルがプロジェクトから削除された場合、依存関係が最初にインストールされるときに、node_modules ディレクトリが自動的に分類されます。npm v4.x より前のバージョンの場合、ユーザーは指示を手動で実行するには npm dedupe依存関係ディレクトリを整理する
node_modules はフラットな管理依存関係であるため、異なるバージョンの依存関係をインストールする場合、深い依存関係が第 1 レベルのディレクトリにインストールされる可能性があります。プロジェクトで依存関係のバージョンの競合が発生した場合、深い依存関係が第 1 レベルのディレクトリから親の依存関係ディレクトリに自動的に移動されます。[検証済み]