Комментарии 20
Разве алиаса не будет достаточно?
composer.phar require phpunit/php-code-coverage 'dev-7.0.8-myFix as 7.0.7'
Спасибо, искал, но не нашёл такую возможность.
Тем не менее по вашей ссылке:
Note: Inline aliasing is a root-only feature. If a package with inline aliases is required, the alias (right of theas) is used as the version constraint. The part left of theasis discarded. As a consequence, if A requires B and B requiresmonolog/monologversiondev-bugfix as 1.0.x-dev, installing A will make B require1.0.x-dev, which may exist as a branch alias or an actual1.0branch. If it does not, it must be inline-aliased again in A'scomposer.json.
Note: Inline aliasing should be avoided, especially for published packages/libraries. If you found a bug, try and get your fix merged upstream. This helps to avoid issues for users of your package.
Т.е. в каждом проекте всё равно нужно будет вручную прописывать алиасинг. Я рассмотрю подробнее эту возможность и возможно обновлю статью с учётом её.
Мало занимаюсь js, поэтому не сталкивался с проблемой фикса зависимостей.
Так или иначе беглый гуглинг выдаёт patch-package. Т.е. с похожей проблемой в js сталкиваются.
Не знаю, как это будет работать для случая, когда вы используете зависимость, которая зависит от форка, при этом есть другие пакеты, которые зависят от оригинала. Не уверен, что там не будет проблем с тем, что бы определить, какую версию ставить.
Но даже если там оно как-то поставится, то в случае форка, его всё равно нужно будет при обновлении зависимости всегда обновлять форк. Патч же с большой вероятностью установится на следующую минорную версию.
В общем, я думаю в npm при использовании форков будут проблемы, подобные тем, что описаны в статье.
cat vendor/phpunit/php-code-coverage/src/CodeCoverage.php | grep example
Не рассматривал, но на вскидку будут все те же проблемы, с форками, т.к. этап форк и его поддержки никуда не денется. Так же вопрос, а что если будет 2 библиотеки, в которых разные replace-ы на одну и ту же библиотеку. Скорее всего они будут не совместимы.
This allows you to fork a package, publish it under a different name with its own version numbers, while packages requiring the original package continue to work with your fork because it replaces the original package.
Про свои версии я не очень понял, в статье пункт на эту тему был "Сделать в своём форке phpunit/php-code-coverage, чтобы тег 7.0.8 ссылался на другой коммит. Это как минимум неочевидно, а как максимум — в Git неудобно работать с тегами, ссылающимися на разные коммиты с одним названием в разных удалённых репозиториях.".
А как вы считаете, какие преимущества у replace по сравнению патчами?
а что если будет 2 библиотеки, в которых разные replace-ы на одну и ту же библиотеку. Скорее всего они будут не совместимы.
Согласен, они скорее всего будут несовместимы, но об этом я узнаю на этапе установки зависимостей.
Про версии я так понял можно в composer.json в секции replace указывать не просто какие библиотеки реплейсятся текущей, но и мапинг какая версия на какую. Таким образом и можно весть совершенно иную ветку с версиями. Ну например смапить max/php-code-coverage версии 1.0.0 на phpunit/php-code-coverage версии 7.0.8.
Про преимущества replace следующий кейс: предположим есть библиотека А которую мы патчим, но еще есть зависимость какой-то другой зависимости B, которая у себя в зависимостях имеет библиотеку А. Но B может быть не рассчитана на накатываемые патчи, а узнаем мы об этом уже из логов (если узнаем). Так как патч у нас может быть любой, а имея дело с отдельной библиотекой мы так или иначе задумываемся об обратной совместимости и семантическом версионировании.
P.S. я как раз сейчас сам выбираю по какому пути пойти и replace пока не испытывал.
Если вдруг кому будет интересно, чем форк лучше оригинала:
- Для меня, в первую очередь, автообнаружением патчей. Я очень не люблю править composer.json руками;
- Уже упомянутая в статье возможность применять разные патчи для разных версий установленного пакета.
Allan Paiste (я же правильно понимаю, о ком идет речь в «автор vaimo/composer-patches»?)
Да.
Вообще, добавление форка в Packagist не выглядит как хорошая идея.
Не могли бы вы раскрыть свою мысль?
Моя мысль была в том, что у Allan Paiste уже был hard fork, который он не собирался вливать в оригинал со своим именем в composer.json и своим уникальным функционалом. В данном случае просто напрашивается опубликовать пакет на Packagist.
Для меня, в первую очередь, автообнаружением патчей. Я очень не люблю править composer.json руками;
Согласен, я это как раз отметил как одно из преимуществ, но немного другими словами.
Статья старая, но всё еще актуальная. Так вот, заголовок не соответствует действительности - совсем не без боли. Как патч то создать? В том же js (patch-package) просто берешь и редактируешь код зависимости, запускаешь команду и у тебя готовый патч (еще и под разные версии той библиотеки что патчим). При этом этап создания патча самый трудоемкий, к сожалению, в PHP до сих пор предлагается всё это делать ручками. Т.е. форкаем библиотеку, добавляем её как-то в проект, редактируем, генерим патч, а потом это всё поддерживать как-то надо. Красотища :(
ЗЫ: Очередной раз за несколько лет понадобилось добавить патч в проект, но снова мне лень ибо генерировать патчи руками это мертворожденный подход, как мне кажется.
PHP Composer: фиксим зависимости без боли