web-dev-qa-db-ja.com

npmの「package-lock.json」をバージョン管理下に置く意味は何ですか?

Npmのpackage-lock.jsonをバージョン管理下に置く意味は何ですか?私の経験では、このファイルソースを制御することで、効率の向上よりも多くの問題と混乱を引き起こしています。

ソース管理下にpackage-lock.jsonがあると、ノードモジュールを追加/削除/変更した開発者がブランチ間で競合を解決する必要があるたびに大きな頭痛が発生します。特に、package-lock.jsonが数万行に及ぶ可能性のある複雑で大きなアプリでの作業。 node_modulesを吹き飛ばして新しいnpm installを実行するだけでも、パッケージロックに大幅な変更が発生する可能性があります。

他にもいくつかのSOパッケージロックに関する質問があります:

そして、GitHubの問題で、パッケージロックに関する大量の会話があります。

これにより、解決する必要のある広範な不確実性がまだあると思います。

ドキュメントによると

package-lock.jsonは、npmがnode_modulesツリーまたはpackage.jsonを変更する操作に対して自動的に生成されます。

では、自動生成されたファイルをソース管理下に置く必要があるのはなぜですか?

上記のGitHubの問題は、package-lock.jsonとの混乱に対応して、一部の人々がnpm installスクリプトをrm -f package-lock.json && npm installに変更する方法を詳しく説明していますが、これも正しくありません。

package-lock.jsonは、ノードモジュールの依存関係の正確なバージョンの真実のソースを目指しているようですが、package.jsonが正確に行うことではありませんか?このファイルのマージの競合を解決するための耐え難いほどの苦痛はいつ報われ始めますか?

25
Cumulo Nimbus

私の経験では、package-lock.jsonをバージョン管理下に置くのは意味がありません。大規模なマージ/リベースの管理は悪夢になります。ただし、package-lockが非常に役立つ場合があります

最近(2017/10/10)moment.jsが導入されました マイナーバージョンアップデートの重大な変更 。意味package-lock.jsonなしで出荷する予定で、package.jsonに次のようなものがある場合:

"moment": "^2.12.0"

バージョン2.19.0で導入されたいくつかの互換性のない変更は、ほとんど痕跡を残さずにコードに潜入します。

これが、リリース候補として機能するようにブランチをカットした後、次のことが重要である理由です。

  • .gitignoreからpackage-lock.jsonを削除する
  • npm installを実行して、package-lock.jsonを生成します
  • test、qa、このパッケージロックで展開

これにより、npmモジュールのバージョンが、テストされたものと同じバージョンにロックされたままになることが保証されます。

8
Cumulo Nimbus

.gitattributesエントリを作成します。

# common settings that generally should always be used with your language specific settings

# Auto detect text files and perform LF normalization
* text=auto

#
# The above will handle all files NOT found below
#

#*.svg text
*.lock binary

次に、マージするときに、バージョンとコードのマージを選択するだけで済みます。この方法でパッケージの競合が発生する可能性があると思いました。

ビルドプロセスでバージョンをチェックすることにより、これを軽減しました。

3
Fitch

IMO package-lock.json(またはyarn-lock.jsonalwaysをソース管理にコミットする必要があります。マージ/リベースの競合は別として(これはyarn BTWによって大幅に軽減されます-yarn installリベースの途中で問題を自動的に解決します)。これは、コミット時のコードが新しいチェックアウトとインストールの後に正しくビルドおよび実行されることを保証する最良の方法です。

2
linguamachina