依存地獄から私たちを救い出す

依存地獄から私たちを救い出す

現代のほとんどのサービスとアプリケーションは、増え続けるnode-modulesフォルダに存在する大量の依存関係を持っています。 一般的に、これらのライブラリの多くは、積極的に維持、変更、および更新されています。 あなたの依存関係が不十分に管理されている場合は、すぐに依存関係の地獄に自分自身を見つけることができます。

npmに慣れていない場合は、

Grocery Grocery Shopping

ノードアプリケーションを起動するとき、最初のステップの1つはnpm installを実行することです。 これを実行すると、ノードはプロジェクトのベースにpackage.jsonというファイルをチェックします。 そのファイルが見つかった場合、アプリケーションが必要とする「食材」(コードビット)を収集するために、dependencyセクションを一種の「食料品の買い物リスト」とし この場合の「食料品店」は、npmがregistryと呼ぶものです。 デフォルトでは、nodeアプリはこれらのパッケージのために公開npmレジストリを調べます。 パッケージがレジストリで見つかった場合、nodeはその”ingredient”をプロジェクトのベースにあるnode_modulesディレクトリに置きます。

あなたが必要とするパッケージは、独自の”買い物リスト”(パッケージ)を持っている可能性があることに注意することが重要です。これらのネストされた依存関係はすべて、アプリが独自のパッケージ内の次の依存関係に移動する前に解決する必要があります。json。

Altテキスト

⬆️ バージョン、Careキャレット、およびWildワイルドカード

あなたの依存関係のバージョンは、一般的にv1.3.5のようなものです。 これはセマンティックバージョン管理、またはsemverと呼ばれます。 Semverでは、数字はさまざまな重大度-MAJOR.MINOR.PATCHのコードへの変更を表します。

互換性のないAPI変更を行う場合のメジャーバージョン、下位互換性のある方法で機能を追加する場合の
マイナーバージョン、下位互換性のあるバグ修正を行

これを念頭に置いて、多くの人は、依存関係が新しい、壊れない変更で持つ可能性のある新鮮な新しいものでアプリを自動的に更新したいと思っています。

前にチルダ~を付けると、新しいPATCH更新が得られますが、メジャーまたはマイナーは得られません。 したがって、~1.3.11.3.9をインストールできますが、1.4.0

の前にキャレット^を付けると、新しいPATCHおよびMINORバージョンが提供されますが、メジャーではありません。 そのため、^1.3.11.4.9をインストールできますが、1.5.0
Altテキスト
Altテキストはインストールできません

コードの依存関係ツリーの例を見てみましょう:

my-breakfast | | milk | |coffee-script 

わかりました、より多くの棒のように、しかしうまくいけば依存関係の連鎖は明確です。 私達のパッケージ。jsonはバージョンv0.5.0具体的にはmilkが必要ですが、milkは0.9.61.0.0のどこかcoffee-scriptが必要です。 npm installが実行され、我々は我々のアプリを開発し、すべてがhunky-doryです。

←今は2ヶ月早送りしましょう。 誰かがあなたのプロジェクトを見つけ、貢献したいと思っています。 彼らはあなたのレポをフォークしてクローンし、npm installを実行し、aaaaandそれは動作しません。 “しかし、それは私のマシン上で働いた!”あなたは泣く。 コラボレーターがノードモジュールをインストールしたとき、milkの特定のバージョンが保証されましたが、milkのパッケージのためにcoffee-scriptの別のバージョンが保証されました。jsonはsemverを使用しました。

🗿依存関係をstone

に設定するこれに対する1つの解決策は、package-lock.jsonファイルを使用することです。 このファイルを使用すると、インストールするすべての依存関係のバージョンを非常に詳細に制御できます。 あなたのpackage.jsonが買い物リストのようなものであれば、あなたのpackage-lock.jsonは予算のようなものです。 あなたはシリアルを持っていることができますが、それはつもりCap’nクランチの代わりにストアブ この特異性は、依存関係ツリーのすべての枝の下でずっと実行されます。 ロックファイルを使用する場合は、package.jsonが必要です(package.jsonは依存関係管理だけでなく、この投稿の焦点にすぎません)。

Wrappingラップアップ

私は個人的にpackage-lock.jsonファイルを常に使用する必要があると感じています(npmの新しいバージョンでは、実際には自動的に生成されます)。 これにより、環境や展開全体ですべての信頼性が向上します。 ここでは、扶養家族に来るときうまくいけば助けるためにいくつかの最後の小さなナゲットです:

  • npm install --save 自動的にあなたのロックファイルとパッケージを更新します。そのパッケージのjson。
  • npm cinpm installだけではなく、ノードモジュールを自動的に再構築し、ロックファイルからビルドします。 これはCI/CDにとって本当に便利なコマンドであり、一般的にはロックファイルと並行して使用するのが最善です。
  • 大規模なプロジェクト、および超堅牢な依存関係については、dockerとcontainersをチェックしてください。 これは、コードとその依存関係を完全に含む仮想マシンのように機能し、さまざまな環境に昇格するために複製されます。 だからうまくいけば、あなたははるかに少ない”それは私のマシンで働いた”種類の問題に終わります。

コメントを残す

メールアドレスが公開されることはありません。