Комментарии 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 сталкиваются.
Не думаю что подобное нужно для ноды. Если вы используете библиотеку которую хотите пропатчить — то делайте форк, а потом вместо цифры версии в package.json вставляете ссылку на ваш гитхаб.
Не знаю, как это будет работать для случая, когда вы используете зависимость, которая зависит от форка, при этом есть другие пакеты, которые зависят от оригинала. Не уверен, что там не будет проблем с тем, что бы определить, какую версию ставить.
Но даже если там оно как-то поставится, то в случае форка, его всё равно нужно будет при обновлении зависимости всегда обновлять форк. Патч же с большой вероятностью установится на следующую минорную версию.
В общем, я думаю в npm при использовании форков будут проблемы, подобные тем, что описаны в статье.
Не знаю, как это будет работать для случая, когда вы используете зависимость, которая зависит от форка, при этом есть другие пакеты, которые зависят от оригинала.
Все будет работать идеально. Ваш код будет подгружать код с форка, а остальные пакеты будут использовать оригинальные версии, именно так работает require в node.
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: фиксим зависимости без боли