将npm的package-lock.json置于版本控制之下有什么意义？根据我的经验，这个文件源控制引起了比效率提升更多的麻烦和混乱。
package-lock.json处于源代码管理状态会导致主要问题 。特别是在复杂/大型应用程序上工作，其中package-lock.json可以长达数万行。即使只是吹走node_modules并运行一个新的npm install，也会在包锁中产生剧烈的变化。
还有其他一些关于包锁的SO问题：
GitHub问题与大量关于package-lock的讨论：
这让我觉得仍有广泛的不确定性需要消除。
根据文档
对于npm修改node_modules树或package.json的任何操作，都会自动生成
package-lock.json。
所以你为什么要将自动生成的文件放在源代码管理下呢？
上面的GitHub问题详细说明了一些人为了应对与package-lock.json的混淆，如何将他们的npm install脚本更改为rm -f package-lock.json && npm install，这也感觉不正确。
似乎package-lock.json正在努力成为节点模块依赖关系的确切版本的真实来源，但这不正是package.json的功能吗？什么时候解决这个文件中的合并冲突的难以忍受的痛苦开始得到回报？
答案 0 :(得分：8)
根据我的经验，将package-lock.json置于版本控制下没有意义。它使管理大型合并/转换成为一场噩梦。但是，有些情况下包锁可能非常有用。
最近（2017/10/10）moment.js介绍breaking changes in a minor version update。意思是如果一个人没有发送package-lock.json ，并且在他们的package.json中有这样的东西：
"moment": "^2.12.0"
2.19.0版中引入的一些重大更改会以几乎无痕迹的方式静默渗透您的代码。
这就是为什么在削减一个分支作为候选发布者之后，这对于：
至关重要npm install以生成package-lock.json 这可确保您的npm模块版本将保持锁定在已测试的相同版本上。
答案 1 :(得分：3)
创建.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
然后在合并时，您只需选择版本与代码合并。以为你可能会以这种方式遇到包冲突。
我们通过检查构建过程中的版本来缓解这种情况。
答案 2 :(得分：1)
IMO package-lock.json（或yarn-lock.json）应始终用于源代码控制。除了合并/变基冲突（yarn BTW可以大大缓解-您可以yarn install在变基中期来自动解决问题），这是最好的保证，您可以确保该提交时的代码将生成并重新签出并安装后即可正常运行。