Я не хочу, чтобы все в Packagist смеялись надо мной.
Наличие Github за Packagist — это удобный способ сделать ваши пакеты общедоступными и доступными для вас и всех. Однако есть проблема: вы не можете легко сделать то же самое с частными репозиториями.
Самая прямая альтернатива использованию Composer с приватными пакетами — это платная услуга Частный упаковщик. Есть и другие альтернативы, такие как Satis или Packeton, но вам придется размещать их самостоятельно. Существует также Repman, который является бесплатным, но это может быть слишком излишним, чтобы просто хотеть использовать свой частный репозиторий в своем проекте.
Если вам нужен бесплатный и простой способ разместить частный пакет в Github и загрузить его в свой проект, он есть.
1. Подготовка пакета в Github
Этот шаг должен быть простым, если вы уже создали пакет PHP для публикации в Packagist. По сути, сделайте допустимый composer.json с именем пакета, зависимостями, автозагрузкой и т. д. Точно так же, как вы сделали бы для публичной публикации пакета.
Например, это composer.json моего частного пакета локальных подписок. Я буду использовать это в качестве примера во всей статье.
Как только наш манифест Composer и частный пакет будут готовы и заработают, мы укажем нашему проекту использовать этот код.
Пока вы этим занимаетесь, рекомендуется выпустить
v1.0.0версию, чтобы вы могли получить свой пакет с помощью управления версиями.
2. Подготовка учетных данных
Прежде чем идти дальше, нам нужен способ аутентификации с помощью Github при извлечении кода из репозитория. Чтобы сделать это, не раскрывая наши учетные данные (пароль) и не собираясь генерировать SSH-ключи, что само по себе является целой задачей, мы можем использовать токены личного доступа.
Войдите в свою учетную запись или по ссылке выше и предоставьте repo все разрешения.
После того, как вы сохраните его с именем, например Laravel Subscription Package, Github покажет токен только один раз. Не закрывайте окно, просто скопируйте куда-нибудь.
Считайте этот токен своим паролем, поэтому не показывайте его в Интернете: у него все еще есть доступ для записи в частный репозиторий. Вы можете обвинить Github в том, что он не имеет возможности только для чтения частных репозиториев, но он лучше, чем вышеупомянутые механизмы аутентификации, потому что в случае утечки его можно отозвать.
На самом деле я ищу поддержку для моего Локального пакета подписки, так что заходите на мой Patreon, если у вас есть лишняя пара баксов.
3. Добавьте свой пакет в свой проект
Следующий шаг — перейти к composer.json вашего проекта и добавить его в качестве зависимости. Поскольку Laragear Subscriptions только что запущен, мы установим set is как версию 1.*.
Этого, конечно, будет недостаточно. Нам также нужно указать, где он находится, в данном случае это наш личный репозиторий на Github. Мы можем использовать клавишу repositories, чтобы добавить места, которые следует использовать для извлечения пакетов.
Внутри этого массива мы перечислим каждый репозиторий с пакетом, который он предоставляет, и типом. В данном случае тип — vcs, поскольку git — это система управления версиями; наше имя Laragear Subscription, которое мы объявили и планируем использовать; и URL-адрес местоположения git.
Поскольку я не использую ветку main/master по умолчанию, мне нужно будет указать, какую из них нужно оформить с помощью branch, но в противном случае вы можете ее опустить.
Теперь Composer нужны учетные данные для использования и извлечения кода.
4. Добавление учетных данных
Поскольку наш пакет находится за аутентификацией, мы будем использовать созданный нами токен, чтобы Composer мог использовать его для входа в частный репозиторий и извлечения кода.
Вы можете создать файл auth.json и напрямую использовать ключ github-oauth вместе с токеном Github. Это предпочтительный способ, поскольку вы можете добавить этот файл в .gitignore и не загружать его в Интернет. В противном случае вы всегда можете просто засунуть его внутрь клавиши config.
Если вы планируете использовать этот токен в общедоступном репозитории, вам следует использовать Секреты репозитория для управления токеном, а не размещать его на видном месте.
5. Проверка работы
Вы можете проверить, работает ли это, используя интерфейс командной строки Composer, чтобы проверить, можно ли правильно подобрать ваш пакет.
Если вы не видите подобного вывода, то вы можете легко проверить, в чем проблема: неверные токены, плохо написанное имя пакета или что-то еще.
6. Использование вашего пакета
После того, как вы выполните вышеуказанные шаги, и все будет правильно, вы можете использовать composer update для обновления ваших зависимостей в вашем проекте, что автоматически извлечет код из вашего частного репозитория.
Отличительной особенностью Composer является то, что он также знает о выпусках в вашем репозитории, поэтому мы использовали 1.* вместо dev-1.x или dev-main для ограничения версии.
Использование релизов для маркировки вашего кода разными версиями — отличный способ отметить стабильные релизы.
В нашем случае мы можем получить большую выгоду, загружая только новые теги нашего пакета вместо того, чтобы всегда получать все, что работает в ветках разработки.
Это самый простой способ включить ваш частный пакет в свой проект без необходимости иметь дело с ключами Private Packagist или SSH.
Конечно, проще использовать Private Packagist, если вам нужно обработать больше, чем пару частных посылок, поэтому не стесняйтесь получить план или используйте Repman, если у вас ровно 0 долларов.
