Является ли" content-hash " обязательной частью composer.замок?

Как и большинство людей, пишущих (и читающих) вопрос о сохранит ли composer.lock в версии-control, мы держим там наши.

однако это вызывает у нас проблемы каждый раз, когда файл независимо обновляется в разных ветвях кода. Даже если изменения не связаны между собой и влияют на разделы файла вдали друг от друга,"content-hash" строка вызывает конфликт каждый раз. Хуже того, ни одна "сторона" не является правильной, и тот, кто делает слияние должно регенерировать файл вручную...

может, не обязательно? Прежде чем спросить, будет ли (текущая версия) composer работать без него, какая функциональность будет отсутствовать? Хэш, кажется, защищает от изменения самого файла , но система управления версиями уже делает это...

могу я просто извлечь линию? Если это невозможно сделать сегодня, будет ли это желательной особенностью для композитора?

8
composer-php

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.json синхронизированы с composer.lock. Вы можете запустить

$ composer validate

для узнайте, синхронизированы ли они.

если composer.json и composer.lock не синхронизированы, будет показано сообщение, подобное этому

файл блокировки не в курсе последних изменений в composer.json, рекомендуется запустить composer update.

для справки, см. https://getcomposer.org/doc/03-cli.md#validate:

вы всегда должны запускать команду validate перед фиксацией composer.json файл, и перед тем, как пометить релиз. Он будет проверять, если ваш 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: только обновляет хэш файла блокировки, чтобы подавить предупреждение о том, что файл блокировки устарел.

14