NPMメカニズムの深い理解

不言
リリース: 2019-03-29 10:06:49
転載
1871 人が閲覧しました

この記事は、NPM メカニズムを深く理解するのに役立ちます。一定の参考価値があります。困っている友人は参照できます。お役に立てば幸いです。

NPM を使用してインストールすると、パッケージの競合 (複数のメイン モジュールのサブモジュールのバージョンの不一致など) が頻繁に発生し、その結果、開発プロセス中にさまざまな重大または軽微な問題が発生します。ここでは、次の内容をすべて紹介します。

  1. 主な NPM インストール方法
  2. NPM パッケージ情報のクエリ
  3. NPM インストールの仕組み (メイン)

インストール&クエリコマンド

##NPMの各種インストール方法

  • #npm install packageName[@next | @versionNumber]

    node_modules でモジュールが指定されていない場合にインストールされます (~/.npm ディレクトリはチェックされません)
  • ##npm install packageName - -f | -- 強制
  • モジュールがインストールされているかどうかに関係なく、npm は

    強制的に再インストールされます
  • npm update packageName
  • リモート バージョンが新しい場合、またはローカル バージョンが存在しない場合はインストールします

  • NPM クエリ サービス

NPM は、レジストリ クエリ サービスを通じて各モジュールの最新バージョンを認識します。

  • npm view packageName [version]
  • NPM インストールメカニズム
npm install を入力して、対応するモジュールの情報を照会できます。コマンドを入力して Enter を押すと、次の段階が実行されます (npm 5.5.1 を例にします):

1. プロジェクト自体のプレインストールを実行します

現在の npm プロジェクトが定義されている場合、この時点でプレインストール フックが実行されます。

2. 第 1 レベルの依存関係モジュールを決定する

最初に行う必要があるのは、プロジェクト内の第 1 レベルの依存関係、つまり dependency

および

devDependency 属性で直接指定されたモジュール (この時点で npm install パラメーターが追加されていないと仮定します)。 プロジェクト自体は、依存関係ツリー

全体のルート ノードです。各第 1 レベルの依存関係モジュールは、ルート ノードの下のサブツリーです。npm は、各第 1 レベルの依存関係から複数のプロセスを開始します。モジュールは徐々に深いノードの検索を開始します。

指定したモジュールが既に node_modules ディレクトリに存在する場合、再インストールされません。

3. モジュールの取得

モジュールの取得は次のとおりです。 a再帰のプロセス

は次のステップに分かれています:

モジュール情報の取得
  • モジュールをダウンロードする前に、まず次のことを決定する必要があります。これは、package.json にセマンティック バージョン (semver、セマンティック バージョン) が含まれることが多いためです。

      このとき、バージョン記述ファイル (npm-shrinkwrap.json または package-) にモジュールに関する情報があれば、 lock.json) を直接取得します。そうでない場合は、ウェアハウスから取得します (レジストリへのクエリ)。たとえば、packaeg.json 内のパッケージのバージョンが ^1.1.0 である場合、npm はウェアハウスに移動して 1.x.x 形式に準拠する最新バージョンを取得します。
    • #モジュール エンティティを取得します。
    前のステップでは、モジュールの圧縮パッケージ アドレス (解決済みフィールド) を取得します。npm はこのアドレスを使用してローカル キャッシュを確認します。キャッシュ内にある場合は、直接取得されます。そうでない場合は、ウェアハウスからダウンロードされます。
    • このモジュールの依存関係を検索します
    依存関係がある場合は手順 1 に戻り、依存関係がない場合は停止します。
    • 4. モジュールのフラット化 (重複排除)
  • 1 つのステップで、ロットを含む完全な依存関係ツリーが得られます。反復モジュールの。たとえば、モジュール A はloadsh に依存し、モジュール B も lodash に依存します。 npm3 より前は、インストールは依存関係ツリーの構造に厳密に基づいていたため、モジュールの冗長性が生じていました。

npm3 バージョン 以降、重複排除プロセスがデフォルトで追加されています。これはすべてのノードを走査し、ノード モジュールの最初のレベルであるルート ノードの下にモジュールを 1 つずつ配置します。重複したモジュールが見つかった場合、それらは破棄されます。

ここでは、重複したモジュールを定義する必要があります。これは、

モジュール名が同じであり、互換性がある

を参照します。各サーバーは、許可されたバージョン範囲に対応します。2 つのモジュールの許可されたバージョン範囲が重複する場合、まったく同じバージョン番号を持つ必要がなく、互換性のあるバージョンを取得できます。これにより、重複排除プロセス中により多くの冗長モジュールを削除できます。 たとえば、node-modules の下の foo モジュールが lodash@^1.0.0 に依存し、bar モジュールが lodash@^1.1.0 に依存する場合、^1.1.0 は互換性のあるバージョンです。

foo が lodash@^2.0.0 に依存し、bar が lodash@^1.1.0 に依存する場合、semver の規則に従って、この 2 つの間に互換性のあるバージョンはありません。 1 つのバージョンは node_modules に配置され、もう 1 つは依存関係ツリーに残ります。

たとえば、依存関係ツリーが元々次のようになっているとします:

node_modules
    -- foo
  • ---- lodash@version1
  • -- bar
  • ---- lodash@version2

バージョン 1 とバージョン 2 に互換性のあるバージョンがあると仮定すると、重複排除後は次の形式になります:

node_modules
-- foo

-- bar


-- lodash (保持されるバージョンは互換バージョンです)

version1 と version2 が非互換バージョンであると仮定すると、後続のバージョンは依存関係に保持されます。ツリー:

node_modules
-- foo

-- lodash@version1

-- bar

---- lodash@version2

5 .モジュールのインストール


このステップでは、プロジェクト内のnode_modulesを更新し、モジュール内のライフサイクル関数を(プレインストール、インストール、ポストインストールの順序で)実行します。

6. プロジェクト独自のライフ サイクルを実行します

現在の npm プロジェクトにフックが定義されている場合、この時点でフックが実行されます (インストール、ポストインストール、事前公開、準備)。

最後のステップでは、バージョン説明ファイルを生成または更新し、npm インストール プロセスが完了します。

この記事はここで終了しました。その他のエキサイティングなコンテンツについては、PHP 中国語 Web サイトの JavaScript ビデオ チュートリアル 列に注目してください。

以上がNPMメカニズムの深い理解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
ソース:segmentfault.com
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
最新の問題
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート