将npm的“package lock.json”置于版本控制之下有什么意义？

Question

将npm的包锁定有什么意义。json是否在版本控制下？根据我的经验，控制此文件的源代码比提高效率带来的麻烦和混乱更多。

具有包锁。每次添加/删除/修改任何节点模块的开发人员需要解决分支之间的冲突时，源代码管理下的json都会让人头疼。尤其是在软件包锁定的复杂/大型应用程序上工作。json可以有数万行长。即使只是吹走节点_模块并运行新的npm安装，也会在包锁中产生剧烈的变化。

关于包锁还有几个其他问题：

• 我是否提交包锁。npm创建的json文件
• Npm-包锁。json角色
• 为什么npm安装重写包锁。json

还有一个GitHub问题，关于包锁的大量对话：

• 包裹锁。打包后未更新json文件。json文件已更改

这让我觉得仍然存在广泛的不确定性，需要澄清。

根据医生的说法

包锁。对于npm修改节点\模块树或包的任何操作，都会自动生成json。json。

那么，您为什么要将自动生成的文件置于源代码控制之下呢？

上面的GitHub问题详细描述了一些人如何响应与package-lock.json的混淆，将他们的npm安装脚本更改为rm-fpackage-lock.json

好像是包锁。json正在努力成为准确版本的节点模块依赖项的真实来源，但这不正是软件包的目的吗。json会吗？在这个文件中解决合并冲突的痛苦何时开始得到回报？




Answer 1

IMOpackage-lock.json（或yarn-lock.json）应始终致力于源代码控制。撇开合并/重新基冲突不谈（这在很大程度上通过yarnBTW得到缓解——你可以yarn安装中期重新基来自动解决问题），这是你最好的保证，提交时的代码将在新鲜结账并安装。

Answer 2

创建一个。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

然后，当您合并时，您只需选择版本与代码合并。我认为这样可能会遇到包冲突。

我们通过在构建过程中检查版本来缓解这种情况。

Answer 3

根据我的经验，将包锁定是没有意义的。版本控制下的json。这使得管理大型合并/重定基准成为一场噩梦。但是，在某些情况下，包锁可能非常有用。

最近（2017/10/10）时刻。js在一次小版本更新中引入了突破性的更改。也就是说，如果一个人在装运时没有包裹锁。json，在他们的包中有类似的东西。json:

“时刻”：“^2.12.0”

2.19.0版中引入的一些突破性更改会悄悄地渗透到您的代码中，几乎没有任何痕迹。

这就是为什么在切割一个分支作为发布候选之后，关键是：

• 卸下包锁。json来自。gitignore
• 运行npm install生成包锁。json
• 使用此包锁进行测试、qa和部署

这可以确保您的npm模块版本在测试的相同版本上保持锁定。