npm 7でpackage-lock.jsonのサポートを終了したのはなぜですか？

ファイルがnpm 7 yarn.lockでサポートされることを発表した瞬間から、彼らは私に何度も同じ質問をしました。それは次のように聞こえましたpackage-lock.json。だけを使用しないのはなぜyarn.lockですか？」 この質問に対する簡単な答えは次のとおりです。「npmのニーズを完全に満たしていないためです。それだけに依存している場合、これはnpmの最適なパッケージインストールスキームを形成する機能と、プロジェクトに新しい機能を追加する機能を低下させます。この資料では、より詳細な回答を示しています。







yarn.lock

yarn.lockファイルの基本構造

このファイルyarn.lockは、パッケージ依存関係指定子と、これらの依存関係の解決を説明するメタデータの対応の説明です。例えば：

mkdirp@1.x:
  version "1.0.2"
  resolved "https://registry.yarnpkg.com/mkdirp/-/mkdirp-1.0.2.tgz#5ccd93437619ca7050b538573fc918327eba98fb"
  integrity sha512-N2REVrJ/X/jGPfit2d7zea2J1pf7EAR5chIUcfHffAZ7gmlam5U65sAm76+o4ntQbSRdTjYf7qZz3chuHlwXEA==

このスニペットは次のように述べています：「依存関係はmkdirp@1.xここで指定されたとおりに正確に解決する必要があります。」複数のパッケージがに依存している場合mkdirp@1.x、これらの依存関係はすべて同じ方法で解決されます。



npm 7では、プロジェクトにファイルが存在する場合yarn.lock、npmはそのファイルに含まれるメタデータを使用します。フィールド値resolvedは、パッケージをどこからダウンロードする必要があるかをnpmに通知します。フィールド値は、integrity何が受信されるかをチェックして、受信が予期されるものと一致することを確認するために使用されます。パッケージがプロジェクトに追加またはプロジェクトから削除されると、それに応じてコンテンツが更新されyarn.lockます。



同時に、以前と同様に、npmはファイルを作成しますpackage-lock.json... このファイルがプロジェクトに存在する場合、依存ファイルの構造（フォーム）に関する信頼できる情報源として使用されます。



ここでの質問は、「yarn.lockYarnのパッケージマネージャーにとって十分なものである場合、npmがこのファイルを使用できないのはなぜですか？」です。

確定的依存関係のインストール結果

Yarnを使用してパッケージをインストールした結果は、同じファイルyarn.lockと同じバージョンのYarn を使用しても同じであることが保証されています。異なるバージョンのYarnを使用すると、パッケージファイルがディスク上で異なる場所に配置される可能性があります。



ファイルyarn.lockは、確定的な依存関係の解決を保証します。たとえば、でfoo@1.x許可されている場合foo@1.2.3、同じファイルを使用するとyarn.lock、これはすべてのバージョンのYarnで常に発生します。しかし、これは（少なくともそれ自体で）依存関係ツリーの構造の確定性を保証することと同等ではありません！



次の依存関係グラフを考えてみます。

root -> (foo@1, bar@1)
foo -> (baz@1)
bar -> (baz@2)

次に、いくつかの依存関係ツリー図を示します。それぞれが正しいと見なすことができます。



ツリー番号1：

root
+-- foo
+-- bar
|   +-- baz@2
+-- baz@1

ツリー番号2：

+-- foo
|   +-- baz@1
+-- bar
+-- baz@2

ファイルyarn.lockは、どの特定の依存関係ツリーを使用するかを通知できません。rootコマンドがパッケージ内で実行された場合require(«baz»)（この依存関係は依存関係ツリーに反映されないため、これは正しくありません）、ファイルyarn.lockはこの操作の正しい実行を保証しません。これは、ファイルが与えることのできる確定性の形式ですが、与えることはできpackage-lock.jsonませんyarn.lock。



実際には、もちろん、ヤーン以来、ファイルyarn.lock、依存関係の適切なバージョンを選択するために必要なすべての情報があり、誰もが同じバージョンのYarnを使用している限り、選択は確定的です。つまり、バージョンの選択は常に同じ方法で行われます。コードは、誰かが変更するまで変更されません。 Yarnは十分にインテリジェントであるため、依存関係ツリーを作成するときに、パッケージマニフェストの読み込み時間に関する不一致に依存しないことに注意してください。そうでなければ、結果の確定性は保証されません。



これはYarnアルゴリズムの詳細によって決定され、ディスク上のデータ構造（使用されるアルゴリズムを識別しない）によって決定されないため、この決定論の保証は、package-lock.jsonディスクに格納されている依存関係ツリーの構造の完全な説明が含まれています。



つまり、Yarnが依存関係ツリーを構築する方法はyarn.lock、Yarn自体のファイルと実装に影響されます。そしてnpmでは、ファイルのみが依存関係ツリーに影響しますpackage-lock.json。これpackage-lock.jsonにより、異なるバージョンのnpmで説明されているように、誤ってプロジェクト構造を壊すことが難しくなります。ファイルに変更が加えられた場合（誤って、または意図的に）、バージョン管理システムを使用するプロジェクトリポジトリに変更されたバージョンを追加すると、これらの変更がファイルに明確に表示されます。

ネストされた依存関係と依存関係の重複排除

さらに、ファイルがyarn.lock依存関係の解決の結果を正確に反映できず、実際にはnpmで使用される場合、ネストされた依存関係の操作と依存関係の重複排除を伴う状況のクラス全体があります。さらに、これはnpmがyarn.lockメタデータをソースとして使用する場合にも当てはまります。 npmはこれyarn.lockを信頼できる情報源として使用しますが、npmはこのファイルを依存関係バージョンに課された制限に関する信頼できる情報源とは見なしません。



場合によっては、Yarnが非常に高いレベルのパケット重複を持つ依存関係ツリーを作成し、それが不要になります。その結果、そのような場合に糸のアルゴリズムを正確にたどることは理想からほど遠いことがわかりました。



次の依存関係グラフを考えてみます。

root -> (x@1.x, y@1.x, z@1.x)
x@1.1.0 -> ()
x@1.2.0 -> ()
y@1.0.0 -> (x@1.1, z@2.x)
z@1.0.0 -> ()
z@2.0.0 -> (x@1.x)

プロジェクトがroot依存する1.xパッケージのバージョンx、yおよびz。パッケージyはx@1.1およびに依存しz@2.xます。zバージョン1のパッケージには依存関係はありませんが、同じバージョン2のパッケージはに依存していx@1.xます。



この情報に基づいて、npmは次の依存関係ツリーを生成します。

root (x@1.x, y@1.x, z@1.x) <--   x@1.x
+-- x 1.2.0                <-- x@1.x   1.2.0
+-- y (x@1.1, z@2.x)
|   +-- x 1.1.0            <-- x@1.x   1.1.0
|   +-- z 2.0.0 (x@1.x)    <--   x@1.x
+-- z 1.0.0

パッケージz@2.0.0は依存しますx@1.xが、同じことが言えrootます。ファイルyarn.lockはx@1.xcにマップされます1.2.0。ただし、パッケージの依存関係（zそれも示されているx@1.x場合）は代わりに解決されますx@1.1.0。



その結果、依存関係x@1.xはで説明さyarn.lockれていますが、パッケージバージョン1.2.0で許可する必要があることが示されていますが、パッケージバージョンでは2番目の解決結果x@1.xがあります1.1.0。



フラグを付けてnpmを実行すると、--prefer-dedupeシステムはさらに一歩進んで、依存関係のインスタンスを1つだけインストールしますx。これにより、次の依存関係ツリーが形成されます。

root (x@1.x, y@1.x, z@1.x)
+-- x 1.1.0       <-- x@1.x       1.1.0
+-- y (x@1.1, z@2.x)
|   +-- z 2.0.0 (x@1.x)
+-- z 1.0.0

これにより、依存関係の重複が最小限に抑えられ、結果の依存関係ツリーがファイルにコミットされますpackage-lock.json。



ファイルyarn.lockは依存関係が解決された順序のみをキャプチャし、結果のパッケージツリーはキャプチャしないため、Yarnは次のような依存関係ツリーを生成します。

root (x@1.x, y@1.x, z@1.x) <--   x@1.x
+-- x 1.2.0                <-- x@1.x   1.2.0
+-- y (x@1.1, z@2.x)
|   +-- x 1.1.0            <-- x@1.x   1.1.0
|   +-- z 2.0.0 (x@1.x)    <-- x@1.1.0   , ...
|       +-- x 1.2.0        <-- Yarn     ,    yarn.lock
+-- z 1.0.0

xYarnを使用すると、 パッケージが依存関係ツリーに3回表示されます。追加設定なしでnpmを使用する場合-2回。フラグを使用する場合--prefer-dedupe-一度だけ（ただし、依存関係ツリーはパッケージの最新バージョンではなく、最適なバージョンでもありません）。



結果として得られる3つの依存関係ツリーはすべて、各パッケージが指定された要件を満たす依存関係のバージョンを受け取るという意味で正しいと見なすことができます。ただし、重複が多すぎるパッケージツリーは作成しません。xそれがどうなるかを考えてください-それはそれ自身の多くの依存関係を持つ大きなパッケージです！



その結果、確定的で再現可能な依存関係ツリーの作成をサポートしながら、npmがパッケージツリーを最適化できる唯一の方法があります。この方法は、ロックファイルの使用にあります。ロックファイルの作成および使用の原理は、基本的なレベルではとは異なりyarn.lockます。

ユーザーインテントの実装結果の記録

すでに述べたように、npm 7では、ユーザーはフラグ--prefer-dedupeを使用して依存関係ツリー生成アルゴリズムを適用できます。このアルゴリズムでは、依存関係の重複排除が優先され、常に最新バージョンのパッケージをインストールする必要はありません。フラグの使用は--prefer-dedupe通常、パケットの重複を最小限に抑える必要がある状況で理想的です。



このフラグを使用すると、上記の例の結果のツリーは次のようになります。

root (x@1.x, y@1.x, z@1.x) <--   x@1.x 
+-- x 1.1.0                <-- x@1.x   1.1.0   
+-- y (x@1.1, z@2.x)
|   +-- z 2.0.0 (x@1.x)    <--   x@1.x
+-- z 1.0.0

この場合、npmはx@1.2.0、要件を満たすのはパッケージの最新バージョンですが、x@1.x代わりに選択することはかなり可能であると判断しますx@1.1.0。このバージョンを選択すると、依存関係ツリー内のパッケージの重複が少なくなります。



ロックファイルの依存関係ツリーの構造を修正しなかった場合、チーム内のプロジェクトで作業する各プログラマーは、チームの他のメンバーがセットアップするのと同じ方法で作業環境をセットアップする必要があります。これだけで、彼は他の人と同じ結果を得ることができます。依存関係ツリー構築メカニズムの「実装」を同様の方法で変更できる場合、これはnpmユーザーに、特定のニーズに基づいて依存関係を最適化するための深刻な機会を与えます。ただし、ツリーの作成結果がシステムの実装に依存している場合は、確定的な依存関係ツリーを作成できなくなります。これはファイルの使用がもたらすものyarn.lockです。



高度なnpm設定がさまざまな依存関係ツリーの作成にどのようにつながるかを示すいくつかの例を次に示します。

• --legacy-peer-deps、npmに完全に無視させるフラグpeerDependencies。
• --legacy-bundling、依存ツリーをより「フラット」にしようとすべきではないことをnpmに伝えるフラグ。
• --global-style、すべての推移的な依存関係が上位レベルの依存関係フォルダーでネストされた依存関係として設定されるためのフラグ。

依存関係の解決の結果のキャプチャと修正、および依存関係ツリーを生成するメカニズムをカスタマイズする機能をユーザーに提供する場合、同じアルゴリズムを使用して依存関係ツリーを生成するという期待は、状況に応じて機能しません。



完成した依存関係ツリーの構造を修正することで、ユーザーにそのような機会を与え、同時に決定論的で再現可能な依存関係ツリーを構築するプロセスを中断させないようにすることができます。

パフォーマンスとデータの完全性

このファイルはpackage-lock.json、依存関係ツリーの確定性と再現性を保証する必要がある場合だけでなく、役に立ちます。また、このファイルを使用してパッケージのメタデータを追跡および保存し、package.jsonnpmレジストリの使用に費やされる時間を大幅に節約します。ファイルの可能性はyarn.lock非常に限られているため、絶えずダウンロードする必要のあるメタデータはありません。



npm 7では、ファイルにpackage-lock.jsonはnpmがプロジェクトの依存関係ツリーを完全に構築するために必要なすべてのものが含まれています。 npm 6では、このデータはあまり便利に保存されないため、古いロックファイルが発生した場合、システムに追加の作業をロードする必要がありますが、これは1つのプロジェクトに対して1回だけ実行されます。



結果として、yarn.lock 依存関係ツリーの構造に関する情報が記録されている場合、別のファイルを使用して追加のメタデータを保存する必要があります。

将来の機会

ここで説明してきたことは、ディスクに依存関係を配置するためのさまざまな新しいアプローチを考慮すると、劇的に変化する可能性があります。これらは、pnpm、yarn 2 / berry、およびPnP Yarnです。



npm 8に取り組んでいる私たちは、仮想ファイルシステムに基づいて依存関係ツリーを構築する方法を探求します。このアイデアはTinkでモデル化され、コンセプトは2019年に検証されました。pnpmで使用される構造のようなものに切り替えるというアイデアについても議論していますが、これはある意味では、仮想ファイルシステムを使用するよりも劇的な変化です。



すべての依存関係が何らかの中央リポジトリにあり、ネストされた依存関係がシンボリックリンクまたは仮想ファイルシステムのみで表されている場合、依存関係ツリーの構造のモデル化は、それほど重要な問題ではありません。ただし、ファイルで提供できる以上のメタデータが必要yarn.lockです。そのため、package-lock.jsonへの完全な移行よりも、既存のファイル形式を更新して合理化する方が理にかなっていますyarn.lock。

これは、「yarn.lockの危険性について」と呼ぶことができる記事ではありません。

私が知っていることから、ヤーンは確実に正しいプロジェクト依存関係ツリーを生成することを指摘したいと思います。また、特定のバージョンのYarn（執筆時点では、これはすべての新しいバージョンのYarnに適用されます）の場合、これらのツリーは、npmと同様に完全に確定的です。



このファイルはyarn.lock、同じバージョンのYarnを使用して確定的な依存関係ツリーを作成するのに十分です。しかし、多くのツールで同様のメカニズムを使用しているため、パッケージマネージャーの実装に依存するメカニズムに依存することはできません。これは、ファイル形式の実装がyarn.lock正式にはどこにも文書化されていません。 （これはYarnに固有の問題ではありません。npmでも同じ状況が発生しました。ファイル形式の文書化はかなり深刻な仕事です。）



厳密に決定される依存関係ツリーの構築の信頼性を保証する最良の方法は、長期的には依存関係の解決結果を修正することです。同時に、パッケージマネージャーの将来の実装では、依存関係を解決するときに、以前の実装と同じパスをたどるという信念に頼るべきではありません。このアプローチでは、最適化された依存関係ツリーを構築する能力が制限されます。



依存関係ツリーの最初に固定された構造からの逸脱は、ユーザーの明示的な欲求の結果である必要があります。そのような逸脱は、依存関係ツリーの構造に関する以前に記録されたデータに変更を加えることによって、それ自体を文書化する必要があります。



のみpackage-lock.json、またはこのファイルのようなメカニズムは、npmにそのような機能を提供できます。



JavaScriptプロジェクトでどのパッケージマネージャーを使用していますか？