Настройка и использование плагинов

  1. Сводка
  2. Создание плагина
    1. Пакет плагинов
    2. Класс плагина
  3. Обработчик события
  4. Возможности плагина
    1. Поставщик команд
  5. Использование плагинов

Сводка #

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

В этих случаях вы можете создать плагин для обработки вашей конкретной логики.

Создание плагина #

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

Пакет плагинов #

Файл пакета такой же, как и любой другой файл пакета, но со следующими требованиями:

  1. Атрибут type должен быть composer-plugin.
  2. Атрибут extra должен содержать class элемента, определяющий имя класса плагина (включая пространство имен). Если пакет содержит несколько плагинов, это может быть массив имен классов.
  3. Вы должны потребовать специальный пакет, называемый composer-plugin-api, чтобы определить, с какими API-версиями плагина совместим ваш плагин.

Необходимая версия composer-plugin-api соответствует тем же правилам, что и для обычного пакета.

Текущая версия API-интерфейса плагина для композитора - 1.1.0.

Пример действительного файла composer.json плагина (при отсутствии части автозагрузки):

{
 "name": "my/plugin-package",
 "type": "composer-plugin",
 "require": {
 "composer-plugin-api": "^1.1"
 },
 "extra": {
 "class": "My\\Plugin"
 }
}

Класс плагина #

Каждый плагин должен предоставить класс, который реализует Composer\Plugin\PluginInterface. Метод activate () плагина вызывается после загрузки плагина и получения экземпляра Composer\Composer, а также экземпляра Composer\IO\IOInterface. Используя эти два объекта, вся конфигурация может быть прочитана, и все внутренние объекты и состояние можно манипулировать по желанию.

Пример:

getInstallationManager()->addInstaller($installer);
 }
}

Обработчик события #

Кроме того, плагины могут реализовывать Composer\EventDispatcher\EventSubscriberInterface, чтобы его обработчики событий автоматически регистрировались в EventDispatcher при загрузке плагина.

Чтобы зарегистрировать метод для события, реализуйте метод getSubscribedEvents () и возвращайте его массив. Ключ массива должен быть именем события, а значение - именем метода в этом классе, который должен быть вызван.

public static function getSubscribedEvents()
{
 return array(
 'post-autoload-dump' => 'methodToBeCalled',
 // ^ event name ^ ^ method name ^
 );
}

По умолчанию приоритет обработчика события устанавливается равным 0. Приоритет можно изменить, добавив кортеж, где первое значение является именем метода, как и прежде, а второе значение представляет собой целое число, представляющее приоритет. Высшие целые числа представляют более высокие приоритеты. Приоритет 2 вызывается перед приоритетом 1 и т. Д.

public static function getSubscribedEvents()
{
 return array(
 // Will be called before events with priority 0
 'post-autoload-dump' => array('methodToBeCalled', 1)
 );
}

Если нужно вызвать несколько методов, то к каждому событию может быть присоединен массив кортежей. Кортежи не должны включать приоритет. Если он опущен, по умолчанию он будет равен 0.

public static function getSubscribedEvents()
{
 return array(
 'post-autoload-dump' => array(
 array('methodToBeCalled' ), // Priority defaults to 0
 array('someOtherMethodName', 1), // This fires first
 )
 );
}

Вот полный пример:

composer = $composer;
 $this->io = $io;
 }

 public static function getSubscribedEvents()
 {
 return array(
 PluginEvents::PRE_FILE_DOWNLOAD => array(
 array('onPreFileDownload', 0)
 ),
 );
 }

 public function onPreFileDownload(PreFileDownloadEvent $event)
 {
 $protocol = parse_url($event->getProcessedUrl(), PHP_URL_SCHEME);

 if ($protocol === 's3') {
 $awsClient = new AwsClient($this->io, $this->composer->getConfig());
 $s3RemoteFilesystem = new S3RemoteFilesystem($this->io, $event->getRemoteFilesystem()->getOptions(), $awsClient);
 $event->setRemoteFilesystem($s3RemoteFilesystem);
 }
 }
}

Возможности плагина #

Composer определяет стандартный набор возможностей, которые могут быть реализованы плагинами. Их цель - сделать плагиновую экосистему более стабильной, поскольку она уменьшает необходимость возиться с внутренним состоянием Composer\Composer, предоставляя явные точки расширения для общих требований плагина.

Классы Capable Plugins должны реализовывать интерфейс Composer\Plugin\Capable и объявлять их возможности в методе getCapabilities (). Этот метод должен возвращать массив с ключом в качестве имени класса Composer Capability и значением в качестве собственного имени класса реализации этого модуля:

 'My\Composer\CommandProvider',
 );
 }
}

Поставщик команд #

Функция Composer\Plugin\Capability\CommandProvider позволяет регистрировать дополнительные команды для Composer:

setName('custom-plugin-command');
 }

 protected function execute(InputInterface $input, OutputInterface $output)
 {
 $output->writeln('Executing');
 }
}

Теперь команда custom-plugin доступна вместе с командами Composer.

Команды Composer основаны на компоненте консоли Symfony.

Использование плагинов #

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

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