Концепция композиторских пакетов и репозиториев

Вступление

Репозитории и пакеты слов уже не будут для нас чем-то новым, если мы следуем предыдущим учебникам . В прошлом мы создавали, использовали и публиковали репозитории с использованием composer, а также сделали наши репозитории автоматически обновляемыми, но понимание концепции репозиториев и того, как они работают, отличается от простого их создания и использования.

Поэтому в этом руководстве мы подробно рассмотрим репозитории и попытаемся понять их концепции, типы и принципы работы.

#Основные понятия

1. Пакет: Composer, как мы знаем, является менеджером зависимостей, он устанавливает пакеты

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

Composer рассматривает каждую версию пакета как отдельный пакет, чтобы обеспечить стабильность кода. Это может на самом деле не иметь смысла при использовании композитора, но это стоит знать

Помимо имени и версий, пакет содержит несколько полезных метаданных. Одним из наиболее важных, используемых для установки пакета, является определение источника, которое описывает, где можно получить содержимое пакета. Данные пакета соответствуют содержимому пакета, и это имеет две опции.

• #Dist: Это упакованная версия данных пакета, обычно в выпущенной стабильной форме.
• # Источник: в основном используется для разработки. Обычно он исходит из репозитория исходного кода, такого как git. Мы используем это всякий раз, когда есть необходимость изменить загруженный пакет.

# Репозитории: репозиторий является источником пакета. Это список пакетов / версий. В репозитории хранится ваш пакет, поэтому композитор ищет и находит наши пакеты в репозиториях.

По умолчанию в компоновщике зарегистрирован только репозиторий Packagist, но в репозиторий можно добавить больше репозиториев, объявив их в файле composer.json. Репозитории доступны только для корневого пакета, а репозитории, определенные в наших зависимостях, не загружаются, таким образом, композитор не загружает репозитории ректально.

# Типы хранилищ

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

1. Репозитории Composer: основным типом репозитория является репозиторий Composer . Он использует один файл package.json, в котором определены все метаданные пакета. По умолчанию composer предполагает, что любой созданный репозиторий является репозиторием composer, если в файле composer.json не указано иное, добавляя поля «repository». Репозитории Composer публикуются на Packagist.org.
2. Репозитории системы контроля версий: включает в себя репозитории, размещенные и доступные напрямую через различные системы контроля версий, такие как git, svn, fossil или hg. Для таких репозиториев мы добавляем дополнительное поле в файл composer.json при их определении, чтобы дать возможность композитору узнать, где искать такие системы. Это дополнительное поле хранилища показано во фрагменте кода ниже

   {
   “repositories” : [
   	{
   	“type” : “vcs”,
   	“url” : “https://github.com/agavitalis/hello-composer”
   }
   ],
   “require” :{
   		“monolog/monolog”: “master”
   }
   }
   

   Приведенный выше фрагмент кода описывает, как определяется поле репозитория типа VCS composer.
3. Pear: Еще одним типом репозитория является репозиторий Pear, где такие репозитории устанавливаются композитором с использованием каналов PEAR. Composer при загрузке пакетов с грушей будет иметь префикс, а затем префикс «груша», чтобы избежать конфликтов. В файле composer.json также будут добавлены некоторые специфичные для Pear поля, чтобы сообщить композитору, что эти пакеты являются пакетами Pear.

   {
       "repositories": [
           {
               "type": "pear",
               "url": "https://pear2.php.net"
           }
       ],
       "require": {
           "pear-pear2.php.net/PEAR2_Text_Markdown": "*",
           "pear-pear2/PEAR2_HTTP_Request": "*"
       }
   }
   

   Приведенный выше фрагмент кода также иллюстрирует определение ключа хранилища в файле composer.json хранилища Pear.

# Принципы работы композитора

Composer как менеджер пакетов является мощным и очень полезным. При управлении пакетами composer по умолчанию ищет пакеты, определенные в блоке require файла composer.json, и другие указанные репозитории, если таковые имеются.

При загрузке он гарантирует, что пакеты не загружаются рекурсивно, в том смысле, что он загружает только те зависимости, которые указаны в файле package.json в корневом каталоге нашего приложения.

Эти загруженные зависимости заблокированы в файле composer-lock.json, чтобы гарантировать, что нужные пакеты загружаются, когда наши проекты используются другим.

Если указан параметр «Автозагрузка», композитор создаст папку поставщика, в которой будут храниться все загруженные пакеты для автозагрузки.

Таким образом, мы изучили концепции пакетов, типов и принципы их работы.

Не забудьте поделиться, лайкнуть и прокомментировать этот урок. Не стесняйтесь следовать за нами в социальных сетях. Увидимся в следующем уроке.

Предыдущий: Установка пакета с использованием композитора
Далее: схема composer.json