Node パッケージ管理開発の 5 つの段階について説明する記事

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 コマンドを使用して、バージョン番号の前の ^ の使用をオフにすることができます。デフォルトの動作

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

解決策 2: npm は、
• 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 バージョンが続きます。 その後、依存関係をダウンロードするときに、依存関係ロック ファイルがデフォルトで生成され、値

でバージョンを正確にロックします。 yarn の .lock ファイル: インストールされている依存関係のバージョンのみを記録し、package.json と組み合わせる必要があります。node_modules ディレクトリ構造を決定します
• 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 レベルのディレクトリから親の依存関係ディレクトリに自動的に移動されます。[検証済み]

フェーズ5: より安全、高速、低コスト

pnpm の成熟に直面して、開発者はより安全、高速、ストレージ消費量の削減など、pnpm によってもたらされる恩恵を享受し、問題を解決しています。 「ゴースト依存関係」の解消と反復依存の問題の解決

代名詞: 安全 (WYSIWYG インストールによる)、高速 (反復インストールなし)、低ストレージ消費 (ハードリンクとソフト)リンク)

代表製品: pnpm

主な特長:

(1) 非常に高速です : ストレージ センターは依存関係を一元管理し、プロジェクト node_modules/.pnpm に直接ハード リンクします。以前の作業方法と比較して、グローバル node_modules のコピーからプロジェクトへの大量の IO 操作が削減されます。

(2) ディスク使用率が非常に高くなります。:

• 同じバージョンの依存関係をプロジェクト間で共有します: ハード リンク、ソフト リンク
• 同じ依存関係の異なるバージョンを最大限に再利用します: 異なるバージョンを保存する Diff ファイルのみを追加します

(3 ) 高いセキュリティ:node_modules ディレクトリ構造は package.json 依存関係リストであり、「ゴースト依存関係」問題を解決します

パフォーマンスは次のとおりです。

ノード関連の知識の詳細については、nodejs チュートリアルを参照してください。

以上がNode パッケージ管理開発の 5 つの段階について説明する記事の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。