Как разрешить конфликты двух пакетов при запуске компоновщика?

Ответ 1

Основная проблема здесь заключается в использовании ветвей (dev-master) вместо отмеченных версий. Использование ветвей, скорее всего, закончится проблемами. Я смотрю вопросы Composer на Stackoverflow, и каждый раз, когда кто-то сообщает о проблемах с пакетами, они используют ветки развития и "минимальную стабильность: dev" в 99% случаев.

Что происходит? Я должен предположить, что вы хотите установить эти пакеты в первый раз. Поэтому Composer не устанавливает, а обновляет пакеты. В противном случае рабочий набор версий, способных выполнять все требования к версии, был бы записан в composer.lock.

Итак, вот ситуация зависимости: два пакета зависят от третьего пакета, но эти два требуют несовместимых версий.

Вы можете это исправить? В локальном файле composer.json есть только один инструмент, который сможет разрешить установку третьего пакета: установка его с помощью встроенной псевдонимы версии.

"require": {
    "anahkiasen/former": "dev-master",
    "vespakoen/menu": "dev-master",
    "anahkiasen/html-object": "dev-master as 1.1.2" /* add this line */
}

Установив ветку dev-master и объявив ее равной версии 1.1.2, Composer может разрешить зависимости обоих пакетов.

Проблема заключается в том, что он не сработает в тот момент, когда у вас есть три пакета в зависимости от четвертого - в трех разных версиях.

Правильная вещь для каждой ветки развития должна включать объявление ветки-алиаса в THEIR composer.json, что позволит Composer обнаружить, что ветвь dev-master фактически эквивалентна версии 1.1.x, что могло бы помочь здесь (но нет, если какой-либо пакет явно требует определенного номера версии - 1.1.x не является 1.1.2). Добавление псевдонимов ветки по-прежнему является хорошей вещью и должно быть сделано. Если сопровождающий хочет избежать постоянного обслуживания этого псевдонимов с жесткой кодировкой в ​​composer.json, они могут альтернативно разработать эту версию в ветке, которая имеет версию .x в своем имени (то есть "v1.1.x" или "1.1. x" будет обнаружен Composer, чтобы содержать указанную версию в стабильности разработки).

Обратите внимание, что проблема, которую я описал в последнем абзаце, заключается в том, что для пакетов явно требуется данный номер версии. При таком подходе, если вам нужен такой пакет, вы не можете использовать другую версию этого зависимого пакета самостоятельно или в другом пакете. Хотя могут быть случаи, когда требуется только одна версия, лучшим решением является необходимость в диапазонах версий.

Мое личное предпочтение заключается в использовании оператора каретки для версий более 1.0: ^1.1.7 потребует 1.1.7 в качестве минимальной версии, но не будет обновляться до версии 2.0.0, которая считается несовместимой с изменениями. Если пакет тщательно помечен новой версией в соответствии с семантическим версированием, это работает как шарм. Вы никогда не будете удивлены несовместимыми изменениями (если, конечно, человеческая природа не вмешивается, но вы должны обнаружить эту ошибку и отбросить обновление, если ваше программное обеспечение ломается).

Для версий ниже 1.0 обратите внимание, что оператор каретки работает не так, как оператор тильды - обратитесь к руководству для более подробной информации. Я предпочитаю тильду для пакетов под моим контролем, которые были помечены 0.x, чтобы получить "совместимые" обновления функций, даже если семантическое управление версиями позволяет несовместимые обновления в диапазоне 0.x.

Но даже без семантического управления версиями каждая маленькая неточность в номере версии помогает, например, определение 1.1.* (предположительно, будет обновляться во всех предстоящих выпусках исправлений) или >=1.1.2,<1.2.5.

Худшие вещи требуют "dev-master". Хотя это действительно очень неточно (он будет разрешен для любой возможной фиксации в ветке, в зависимости от времени обновления), проблема в том, что вы не можете вернуться к предыдущей версии "dev-master", если не знаете точно, какое commit ID, и добавьте это требование в composer.json. Но тогда вы находитесь в точно такой же ситуации, как и выше, для чего требуется точная версия (тег git - это только именованный псевдоним для идентификатора commit).