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が正確に行うことではありませんか?このファイルのマージの競合を解決するための耐え難いほどの苦痛はいつ報われ始めますか?
私の経験では、package-lock.json
をバージョン管理下に置くのは意味がありません。大規模なマージ/リベースの管理は悪夢になります。ただし、package-lockが非常に役立つ場合があります。
最近(2017/10/10)moment.jsが導入されました マイナーバージョンアップデートの重大な変更 。意味package-lock.jsonなしで出荷する予定で、package.jsonに次のようなものがある場合:
"moment": "^2.12.0"
バージョン2.19.0で導入されたいくつかの互換性のない変更は、ほとんど痕跡を残さずにコードに潜入します。
これが、リリース候補として機能するようにブランチをカットした後、次のことが重要である理由です。
npm install
を実行して、package-lock.jsonを生成しますこれにより、npmモジュールのバージョンが、テストされたものと同じバージョンにロックされたままになることが保証されます。
.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
次に、マージするときに、バージョンとコードのマージを選択するだけで済みます。この方法でパッケージの競合が発生する可能性があると思いました。
ビルドプロセスでバージョンをチェックすることにより、これを軽減しました。
IMO package-lock.json
(またはyarn-lock.json
)alwaysをソース管理にコミットする必要があります。マージ/リベースの競合は別として(これはyarn
BTWによって大幅に軽減されます-yarn install
リベースの途中で問題を自動的に解決します)。これは、コミット時のコードが新しいチェックアウトとインストールの後に正しくビルドおよび実行されることを保証する最良の方法です。