Основная проблема заключается в использовании ветвей (dev-master) вместо отмеченных версий. Использование ветвей, скорее всего, закончится проблемами. Я смотрю вопросы Composer на Stackoverflow, и каждый раз, когда кто-то сообщает о проблемах с пакетами, они используют ветви развития и «минимальную стабильность: dev» в 99% случаев.
Что происходит? Я должен предположить, что вы хотите установить эти пакеты в первый раз. Поэтому Composer не устанавливает, а обновляет пакеты. В противном случае рабочий набор версий, способных выполнять все требования к версии, был бы записан в composer.lock.
Так вот ситуация зависимости: два пакета зависят от третьего пакета, но эти два требуют несовместимых версий.
Вы можете исправить ошибки? В локальном файле composer.json есть только один инструмент, который сможет разрешить установку третьего пакета: установка его с помощью inline version alias.
"require": {
"anahkiasen/former": "dev-master",
"vespakoen/menu": "dev-master",
"anahkiasen/html-object": "dev-master as 1.1.2" /* add this line */
}
Установив DEV-мастер филиала и объявить его быть похожим на версии 1.1.2, композитор может разрешить зависимости обоих пакетов.
Проблема с этим в том, что в тот момент у вас будет три пакета в зависимости от четвертого - в трех разных версиях.
Правильная вещь для каждой ветви развития должна включать объявление ветви-алиаса в ИХ 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 обратите внимание на то, что оператор каретки отличается от оператора тильды - refer to the manual for more details. Я предпочитаю тильду для пакетов под моим контролем, которые были помечены 0.x, чтобы получить «совместимые» обновления функций, даже если семантическое управление версиями позволяет несовместимые обновления в диапазоне 0.x.
Но даже без семантического управления версиями каждая небольшая ошибка в номере версии помогает, например, определять 1.1.* (предположительно будет обновляться до всех предстоящих выпусков исправлений) или >=1.1.2,<1.2.5.
Худшие вещи требуют «dev-master». Хотя это действительно очень неточно (он будет разрешен для любой возможной фиксации в ветке, в зависимости от времени обновления), проблема в том, что вы не можете вернуться к предыдущей версии «dev-master», если не знаете точно, какое commit ID, и добавьте это требование в composer.json. Но тогда вы находитесь в той же ситуации, что и выше, требующей точной версии (тег git - это просто псевдоним имени для идентификатора фиксации).
vespakoen исправил это. но я задаю вопрос, который может возникнуть с другими пакетами. – cawecoy