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

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

Наступила неделя "простых инвайтов" от TM, количество некачественно оформленных статей будет увеличено в двое, количество авторов со слитой кармой будет утроено.


Resident234 — если серьезно, то советую пока скрыть статью в черновики и доработать её, пока не слили карму.

Да ладно, пусть и устаревшая, но довольно приличная статья для тех, кто ещё не успел войти в мейнстрим, получше всяких DBX и аналогичных, что сыпятся последнее время.

P.S. Пусть, лично для меня, как и для большинства разработчиков не несёт никакой полезной и новой информации, но видно, что автор старался, всё написано по делу и до сих пор не устарело. Не вижу причин ставить такому материалу минусы, даже наоборот, плюсану за старания и качество.
> приличная статья для тех, кто ещё не успел войти в мейнстрим

И таких оооочень много. В свое время был удивлен.
залейте картинки на habrastorage.org
Боже, они всё-таки загрузились. Не загружайте такие картинки никуда…
Текст вместо картинок использовать религия не позволяет?
И — кому надо столь иллюстрированное пособие «для самых маленьких», разве что тем, кто пользуется той же ОС и прочим инструментарием что и Вы.

Информационность хорошая, глупостей нет.
Форматирование пойдет (ну да, картинки можно было бы спрятать под спойлеры, но это мелочь, имхо).

Неожиданная встреча. Если я не обознался. Я когда то тоже писал файловый менеджер.

Указание тильды (~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 — так он вроде бы держит указанный коммит. Или я что-то не так понял?
Помимо composer.json есть ещё lock для версий и installed.json из которого он всё читает, генерируя автолоад и проч. Так вот, этот installed не соответсвует указанным.
А, так понятно — просто в оригинале я прочитал, что он «composer.json строит по последнему доступному в мастер ветке», потому и запутался. Сейчас проверил в проекте — у меня такого не происходит, installed.json содержит те же хэши коммитов, что указаны в composer.json, притом upstream ушел дальше, новые коммиты там есть. Сам composer версии 1.6.3. Может, что-то еще пошло не так (тм)?
1) Там не в хеше дело, хеш он записывает в `lock` как раз тот, который указан в самом `json`. Там сами внутренности другие (т.е. все require, autoload и проч.). Именно они берутся из самого последнего коммита.
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-тегов для своих внутренних компонтентов
композер можно установить не только из командной строки — https://getcomposer.org/download/:
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

Народ подскажите как организовать процесс разработки пакета? Вот есть у меня пакет и есть приложение которое использует его. Потом я что то изменил в пакете или исправил баг. Что потом делать? Менять новую версия и отправлять в гит, а потом в приложение запустить composer update? И так что нужно каждый раз делать?

В зависимости от сложности изменений меняйте версии, обновлять каждый раз, на то она и разработка. Сложнее когда зависимостей для пакета много, и по мере надобности править одновременно несколько пакетов. Главное хуки в репах настроить, чтоб пакажист сам тянул, ну и оно ещё требует подождать, так как версии не сразу подтягивает. Есть неочевидный прикол на пакажисте, я вместо логина прописывал мыло, и долго не понимал, почему хук не работает

Хотя можно наверное указать дев ветку, и просто тянуть без исправлений версии

Если хотим стабильности то — да обновлять каждый раз и контролировать версии.
Версии нужно контролировать тегами git.


Желательно следовать semver https://semver.org/lang/ru

Уточню, на всякий случай — если пакет стянут с гитхаба, то в vendor/[vendor]/[package] окажется копия соответствующего GIT-репозитария. Соответственно, можно прямо в этой папке спокойно работать с гитом, менять ветки как захочется, и высылать изменения в апстрим, если позволяют права работы с репозитарием. Когда наигрались и изменения приняты (и в идеале помечены тегом) — обновляем composer.json, делаем composer update. Как по мне — достаточно удобно. Если это общеизвестная информация, прошу прощения за капитанство.
Раз уж решили описать публикацию в packagist, можно заодно и описать процесс настройки веб-хуков на гитхабе

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

О как! А я всё ручками, да ручками… Спасибо!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории