Комментарии 25
Наступила неделя "простых инвайтов" от TM, количество некачественно оформленных статей будет увеличено в двое, количество авторов со слитой кармой будет утроено.
Resident234 — если серьезно, то советую пока скрыть статью в черновики и доработать её, пока не слили карму.
P.S. Пусть, лично для меня, как и для большинства разработчиков не несёт никакой полезной и новой информации, но видно, что автор старался, всё написано по делу и до сих пор не устарело. Не вижу причин ставить такому материалу минусы, даже наоборот, плюсану за старания и качество.
И — кому надо столь иллюстрированное пособие «для самых маленьких», разве что тем, кто пользуется той же ОС и прочим инструментарием что и Вы.
Информационность хорошая, глупостей нет.
Форматирование пойдет (ну да, картинки можно было бы спрятать под спойлеры, но это мелочь, имхо).
Указание тильды (~1.2.3) будет включать в себя все версии до 1.3 (не включительно), так как в семантическом версионировании это является моментом внедрения новых функциональных возможностей. В данном случае будет получена последняя из стабильных минорных версий. Т.е. будет меняться только последняя цифра — 1.2.5, 1.2.8 и тд.
Если бы все авторы библиотек / пакетов придерживались семантики — было бы замечательно. На практике же нет волшебного джинна, который стучал бы по голове любителям вкидывать новые фичи (вместе с багами) в maintenance updates, вследствие чего приходится часто прикручивать жесткие версии («1.2.5») как минимум на наиболее важные зависимости. Никто не мешает попробовать и с тильдой, просто учтите риски.
вследствие чего приходится часто прикручивать жесткие версии («1.2.5»)
Веселуха начинается тогда, когда основные пакты тысячу лет назад обновились, а какая-то зависимость висит в мастере. И начинается что-то вроде "sonata-project/olololo-admin-bundle": "dev-master@dev#commit278843ghdog872".
Было пару раз такое (при обновлении symfony 2.8 -> 3.0), никому не рекомендую поступать аналогично. Там композер начинает творить ад (включая 1.8.3+, т.е. последние билды). Ну например, он качает исходники из указанного коммита, а сам composer.json строит по последнему доступному в мастер ветке, так что любые изменения в нём ломают весь проект к чертям, даже lock не помогает.
Ну например, он качает исходники из указанного коммита, а сам composer.json строит по последнему доступному в мастер ветке
В каком смысле он «composer.json строит» — это если composer require использовать, чтобы он вписал зависимость в composer.json? Я просто обычно вписываю строку в «require» напрямую в редакторе, и потом composer update — так он вроде бы держит указанный коммит. Или я что-то не так понял?
2) А ещё я тут подумал: Это возможно бага в artifactory (это шняжка для проксирования), попробую завтра на работе отрубить её и проверить что будет, если тянуть напрямую из packagist.
Note: This feature has severe technical limitations, as the composer.json metadata will still be read from the branch name you specify before the hash. You should therefore only use this as a temporary solution during development to remediate transient issues, until you can switch to tagged releases. The Composer team does not actively support this feature and will not accept bug reports related to it.
Отчасти это послужило «пинком под зад» в расстановке semver-тегов для своих внутренних компонтентов
Windows Installer
The installer will download composer for you and set up your PATH environment variable so you can simply call composer from any directory.
Download and run Composer-Setup.exe — it will install the latest composer version whenever it is executed.
За статью спасибо. Про публикацию пакета очень интересно.
Раздел «Composer и PhpStorm» на самом деле было бы приятней прочитать текстом чем на картинках, тем более что на скринах нет пояснений на что смотреть и что кликать, если это инструкция, то надо описывать последовательность действий, к картинкам нужны комментарии.
Можно ещё добавить про composer init
В зависимости от сложности изменений меняйте версии, обновлять каждый раз, на то она и разработка. Сложнее когда зависимостей для пакета много, и по мере надобности править одновременно несколько пакетов. Главное хуки в репах настроить, чтоб пакажист сам тянул, ну и оно ещё требует подождать, так как версии не сразу подтягивает. Есть неочевидный прикол на пакажисте, я вместо логина прописывал мыло, и долго не понимал, почему хук не работает
Хотя можно наверное указать дев ветку, и просто тянуть без исправлений версии
Если хотим стабильности то — да обновлять каждый раз и контролировать версии.
Версии нужно контролировать тегами git.
Желательно следовать semver https://semver.org/lang/ru
Composer для самых маленьких