Как стать автором
Обновить

Комментарии 19

Спасибо, искал, но не нашёл такую возможность.
Тем не менее по вашей ссылке:


Note: Inline aliasing is a root-only feature. If a package with inline aliases is required, the alias (right of the as) is used as the version constraint. The part left of the as is discarded. As a consequence, if A requires B and B requires monolog/monolog version dev-bugfix as 1.0.x-dev, installing A will make B require 1.0.x-dev, which may exist as a branch alias or an actual 1.0 branch. If it does not, it must be inline-aliased again in A's composer.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.

Т.е. в каждом проекте всё равно нужно будет вручную прописывать алиасинг. Я рассмотрю подробнее эту возможность и возможно обновлю статью с учётом её.

Добавил пункт в статью, подробно не стал рассматривать, т.к. по количеству действий этот вариант не сильно отличается от тега альфа релиза.
Ещё раз спасибо!

Спасибо. А для npm есть подобное?

Мало занимаюсь js, поэтому не сталкивался с проблемой фикса зависимостей.
Так или иначе беглый гуглинг выдаёт patch-package. Т.е. с похожей проблемой в js сталкиваются.

Не думаю что подобное нужно для ноды. Если вы используете библиотеку которую хотите пропатчить — то делайте форк, а потом вместо цифры версии в package.json вставляете ссылку на ваш гитхаб.

Не знаю, как это будет работать для случая, когда вы используете зависимость, которая зависит от форка, при этом есть другие пакеты, которые зависят от оригинала. Не уверен, что там не будет проблем с тем, что бы определить, какую версию ставить.
Но даже если там оно как-то поставится, то в случае форка, его всё равно нужно будет при обновлении зависимости всегда обновлять форк. Патч же с большой вероятностью установится на следующую минорную версию.
В общем, я думаю в npm при использовании форков будут проблемы, подобные тем, что описаны в статье.

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

Все будет работать идеально. Ваш код будет подгружать код с форка, а остальные пакеты будут использовать оригинальные версии, именно так работает require в node.

Точно, в js нет неймспейсов, есть модули, поэтому спокойно можно использовать разные версии одних и тех же библиотек.
Значит остаётся только небольшая трудность — подтягивать изменения в свой форк при обновлении оригинальной библиотеки. В общем проблема есть, но не такая острая.

cat vendor/phpunit/php-code-coverage/src/CodeCoverage.php | grep example
Зачем вы раз за разом используется cat, где он не нужен? Сразу grep запускайте.

Привычка осталась с давних времён, когда по другому не умел)
Спасибо, поправил.

Вариант переименования библиотеки и добавления секции replace в composer не рассматривали?

Не рассматривал, но на вскидку будут все те же проблемы, с форками, т.к. этап форк и его поддержки никуда не денется. Так же вопрос, а что если будет 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 пока не испытывал.
Вообще, добавление форка в Packagist не выглядит как хорошая идея. Именно поэтому Allan Paiste (я же правильно понимаю, о ком идет речь в «автор vaimo/composer-patches»?) его туда и не добавил.

Если вдруг кому будет интересно, чем форк лучше оригинала:

  • Для меня, в первую очередь, автообнаружением патчей. Я очень не люблю править composer.json руками;
  • Уже упомянутая в статье возможность применять разные патчи для разных версий установленного пакета.
Allan Paiste (я же правильно понимаю, о ком идет речь в «автор vaimo/composer-patches»?)

Да.


Вообще, добавление форка в Packagist не выглядит как хорошая идея.

Не могли бы вы раскрыть свою мысль?
Моя мысль была в том, что у Allan Paiste уже был hard fork, который он не собирался вливать в оригинал со своим именем в composer.json и своим уникальным функционалом. В данном случае просто напрашивается опубликовать пакет на Packagist.


Для меня, в первую очередь, автообнаружением патчей. Я очень не люблю править composer.json руками;

Согласен, я это как раз отметил как одно из преимуществ, но немного другими словами.

Не могли бы вы раскрыть свою мысль?

На странице с формой добавления пакета Packagist пишет, что не стоит добавлять форки. Правда, они дописали, что если это hard fork то пожалуйста, но я не помню этого текста раньше :)

Стоит отметить, что размер, а соответственно и сложность vaimo/composer-patches в несколько раз больше чем cweagans/composer-patches. Поэтому если последний решает вашу задачу, то возможно лучше выбрать более простое решение.

Имхо, лучше использовать пакет, который активно поддерживается.
С другой стороны, в случае использования и проблем с cweagans/composer-patches можно стать одним из мейнтейнеров этого пакета. Т.к. cweagans/composer-patches проще, то делать в него вклад тоже должно быть проще.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.