“内容哈希”是 composer.lock 的强制性部分吗？

Question

像大多数人写（和读）关于whether to keep composer.lock in version-control 的问题一样，我们把我们的问题留在那里。

但是，每次文件在不同的代码分支中独立更新时，这都会给我们带来麻烦。即使更改是不相关的，并且会影响文件中相距较远的部分，"content-hash" 行每次都会导致冲突。更糟糕的是，“一方”都不正确，进行合并的人必须手动重新生成文件...

也许，这条线真的没有必要吗？在询问之前，（当前版本的）composer 是否可以在没有它的情况下工作，会缺少哪些功能？哈希似乎可以防止文件本身发生变化——但源代码控制系统已经在这样做了......

我可以简单地删除该行吗？如果今天做不到，它会是作曲家想要的功能吗？

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：仅更新锁定文件哈希以抑制有关锁定文件已过期的警告。