composer-php - “content-hash”是composer.lock的必需部分吗？

Question

就像大多数人写(和阅读)有关whether to keep composer.lock in version-control的问题一样，我们将问题保留在那里。

但是，这每次在不同的代码分支中独立更新文件时都会给我们带来麻烦。即使更改无关紧要，并且影响文件的各个部分，但"content-hash"行每次都会引起冲突。更糟糕的是，任何一个“边”都不正确，并且进行合并的任何人都必须手动重新生成文件。

也许，这行不是真的必要吗？在询问之前，如果没有它， Composer (当前版本)是否可以使用，缺少什么功能？哈希似乎可以防止文件本身发生变化-但是源代码控制系统已经在这样做了...

我可以简单地删除行吗？如果今天不能完成，对 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不同步，将显示类似的消息

The lock file is not up to date with the latest changes in composer.json, it is recommended that you run composer update.

供引用，请参阅https://getcomposer.org/doc/03-cli.md#validate:

You should always run the validate command before you commit your composer.json file, and before you tag a release. It will check if your composer.json is valid.

解决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: Only updates the lock file hash to suppress warning about the lock file being out of date.