"content-hash"是composer.lock的必备部分吗？

Question

像大多数人一样编写(和阅读)关于是否保持composer.lock版本控制的问题,我们将其保留在那里.

但是,每次在不同的代码分支中独立更新文件时,这都会给我们带来麻烦.即使更改不相关并且彼此远离影响文件的各个部分,该"content-hash"行每次都会引起冲突.更糟糕的是,"侧面"都不正确,无论谁进行合并,都必须手动重新生成文件......

也许,这条线不是真的有必要吗？在询问之前,是否(当前版本的)作曲家在没有它的情况下工作,会缺少什么功能？哈希似乎可以防止文件本身发生变化 - 但源控制系统已经在做了......

我可以简单地删除该线路吗？如果今天无法完成,它会成为作曲家的理想功能吗？

Answer 1

内容哈希的目的

如您所见Composer\Package\Locker::getContentHash(),内容哈希考虑了以下字段composer.json:

$relevantKeys = array(
    'name',
    'version',
    'require',
    'require-dev',
    'conflict',
    'replace',
    'provide',
    'minimum-stability',
    'prefer-stable',
    'repositories',
    'extra',
);

内容哈希更改的唯一原因是更改了相应属性中的一个值composer.json.

Composer使用内容哈希来确定相关字段是否与之composer.json同步composer.lock.你可以跑

$ composer validate

找出它们是否同步.

如果composer.json和composer.lock不同步,将显示类似于此的消息

锁定文件与composer.json中的最新更改不是最新的,建议您运行composer update.

有关参考,请参阅https://getcomposer.org/doc/03-cli.md#validate:

在提交composer.json文件之前以及标记版本之前,应始终运行validate命令.它会检查你的composer.json是否有效.

解决中的冲突 composer.lock

如果您在解决冲突方面遇到困难composer.lock,可能会有所帮助:

第1步:接受上游更改

通常,您可能会尝试在上游更改之上重新绑定分支.如果已经发生冲突,请使用IDE或运行

$ git checkout --theirs composer.lock

接受上游的变化composer.lock.由于这是一个生成的文件,因此您真的不想解决其中的冲突.

第2步:将更改重新应用于composer.json和composer.lock

如前所述,有一系列相关的密钥composer.json.其中一些可以通过相应的命令修改,其他则不能.

例如,如果其中一个更改是新添加或删除的包,请运行

$ composer require foo/bar:^1.2.3

要么

$ composer remove foo/bar

应用更改.

如果通过运行命令无法应用更改,请手动修改composer.json,然后运行

$ composer update --lock

这将更新内容哈希.

有关参考,请参阅https://getcomposer.org/doc/03-cli.md#update:

--lock:仅更新锁定文件哈希,以禁止有关锁定文件过期的警告.

Answer 2

来自 @localheinz 的 TL;DR 版本：

只需解决冲突，然后使用以下命令重新生成锁定文件：

$ composer update --lock

这将更新内容哈希。

有关参考，请参阅https://getcomposer.org/doc/03-cli.md#update：

--lock：仅更新锁定文件哈希以抑制有关锁定文件已过期的警告。