Run php install script

Scripts

Скрипт,в терминах Composer,может быть как обратным вызовом PHP (определяемым как статический метод),так и любой исполняемой командой командной строки.Скрипты полезны для выполнения пользовательского кода пакета или команд,специфичных для пакета,в процессе выполнения Composer.

Примечание. Выполняются только сценарии, определенные в composer.json корневого пакета . Если зависимость корневого пакета определяет свои собственные сценарии, Composer не выполняет эти дополнительные сценарии.

Event names

В процессе исполнения композитор запускает следующие именованные события:

Command Events

• pre-install-cmd : происходит перед выполнением команды install при наличии файла блокировки.
• post-install-cmd : происходит после выполнения команды install с присутствующим файлом блокировки.
• pre-update-cmd : происходит перед выполнением команды update или перед выполнением команды install без наличия файла блокировки.
• post-update-cmd : происходит после выполнения команды update или после выполнения команды install без наличия файла блокировки.
• pre-status-cmd : происходит до выполнения команды status .
• post-status-cmd : происходит после выполнения команды status .
• pre-archive-cmd : происходит перед выполнением команды archive .
• post-archive-cmd : происходит после выполнения команды archive .
• pre-autoload-dump : происходит перед сбросом автозагрузчика, либо во время install / update , либо с помощью команды dump-autoload .
• post-autoload-dump : происходит после того, как автозагрузчик был выгружен, либо во время install / update , либо с помощью команды dump-autoload .
• post-root-package-install : происходит после того, как корневой пакет был установлен во время команды create-project (но до установки его зависимостей).
• post-create-project-cmd : происходит после выполнения команды create-project .

Installer Events

• pre-operations-exec : происходит перед выполнением операций install/upgrade/.. при установке файла блокировки. Плагины, которые должны подключаться к этому событию, должны быть установлены глобально, чтобы их можно было использовать, иначе они еще не будут загружены, когда произойдет новая установка проекта.

Package Events

• pre-package-install : происходит до установки пакета.
• post-package-install : происходит после установки пакета.
• pre-package-update : происходит до обновления пакета.
• post-package-update : происходит после обновления пакета.
• pre-package-uninstall : происходит перед удалением пакета.
• post-package-uninstall : происходит после удаления пакета.

Plugin Events

• init : происходит после завершения инициализации экземпляра Composer.
• команда : происходит до того, как какая-либо команда Composer будет выполнена на CLI. Он предоставляет вам доступ к объектам ввода и вывода программы.
• pre-file-download : происходит до загрузки файлов и позволяет вам манипулировать объектом HttpDownloader до загрузки файлов на основе URL-адреса для загрузки.
• post-file-download : происходит после загрузки файлов пакета dist и позволяет при необходимости выполнять дополнительные проверки файла.
• pre-command-run : выполняется перед выполнением команды и позволяет вам манипулировать параметрами и аргументами объекта InputInterface , чтобы настроить поведение команды.
• pre-pool-create : происходит перед созданием пула пакетов и позволяет фильтровать список пакетов, которые собираются войти в решатель.

Примечание: Composer не делает никаких предположений о состоянии ваших зависимостей до install или update . Поэтому не следует указывать сценарии, для которых требуются управляемые Composer зависимости, в перехватчиках событий pre-update-cmd или pre-install-cmd . Если вам необходимо выполнить сценарии перед install или update убедитесь, что они содержатся внутри вашего корневого пакета.

Defining scripts

Корневой объект JSON в composer.json должен иметь свойство, называемое «scripts» , которое содержит пары именованных событий и соответствующие сценарии каждого события. Сценарии события могут быть определены как строка (только для одного сценария) или массив (для одного или нескольких сценариев).

• Скрипты выполняются в порядке,определенном при срабатывании соответствующего события.
• Массив скриптов,подключенных к одному событию,может содержать как обратные вызовы PHP,так и исполняемые команды командной строки.
• PHP-классы,содержащие определенные обратные вызовы,должны быть автозагружаемыми с помощью функции автозагрузки Composer.
• Обратные вызовы могут выполнять автозагрузку только классов из определений psr-0,psr-4 и схемы классов.Если определённый обратный вызов полагается на функции,определённые вне класса,то сам обратный вызов отвечает за загрузку файла,содержащего эти функции.

Пример определения сценария:

< "scripts": < "post-update-cmd": "MyVendor\\MyClass::postUpdate", "post-package-install": [ "MyVendor\\MyClass::postPackageInstall" ], "post-install-cmd": [ "MyVendor\\MyClass::warmCache", "phpunit -c app/" ], "post-autoload-dump": [ "MyVendor\\MyClass::postAutoloadDump" ], "post-create-project-cmd": [ "php -r \"copy('config/local-example.php', 'config/local.php');\"" ] > >

Используя предыдущий пример определения, вот класс MyVendor\MyClass который может быть использован для выполнения обратных вызовов PHP:

 namespace MyVendor; use Composer\Script\Event; use Composer\Installer\PackageEvent; class MyClass < public static function postUpdate(Event $event) < $composer = $event->getComposer(); // делаем что-нибудь > public static function postAutoloadDump(Event $event) < $vendorDir = $event->getComposer()->getConfig()->get('vendor-dir'); require $vendorDir . '/autoload.php'; some_function_from_an_autoloaded_file(); > public static function postPackageInstall(PackageEvent $event) < $installedPackage = $event->getOperation()->getPackage(); // делаем что-нибудь > public static function warmCache(Event $event) < // делаем кеш поджаренным > >

Примечание. Во время выполнения команды install или update Composer в среду будет добавлена ​​переменная с именем COMPOSER_DEV_MODE .Если команда была запущена с флагом —no-dev , эта переменная будет установлена ​​в 0, в противном случае она будет установлена ​​в 1. Переменная также доступна во время работы dump-autoload , и она будет установлена ​​так же, как выполнялась последняя install или update

Event classes

Когда событие вызывается, ваш обратный вызов PHP получает в качестве первого аргумента объект Composer\EventDispatcher\Event . Этот объект имеет метод getName() который позволяет вам получить имя события.

В зависимости от типов сценариев вы получите различные подклассы событий, содержащие различные методы получения с соответствующими данными и связанными объектами:

• Базовый класс: Composer\EventDispatcher\Event
• События команды: Composer\Script\Event
• События установщика: Composer\Installer\InstallerEvent
• События пакета: Composer\Installer\PackageEvent
• Plugin Events:
  • init: Composer\EventDispatcher\Event
  • command: Composer\Plugin\CommandEvent
  • pre-file-download: Composer\Plugin\PreFileDownloadEvent
  • post-file-download: Composer\Plugin\PostFileDownloadEvent

  Запуск скриптов вручную

  Если вы хотите запустить скрипты для события вручную,синтаксис таков:

  php composer.phar run-script [--dev] [--no-dev] script

  Например, composer run-script post-install-cmd запустит все определенные сценарии и подключаемые модули post-install-cmd .

  Вы также можете дать дополнительные аргументы для обработчика сценариев путем добавления — следует аргументы обработчика. напр., composer run-script post-install-cmd — —check передаст —check обработчику сценария. Эти аргументы принимаются как CLI arg обработчиками CLI, и могут быть получены как массив через $event->getArguments() обработчиками PHP.

  Запись пользовательских команд

  Если вы добавляете пользовательские сценарии, которые не соответствуют ни одному из предварительно определенных имен событий, указанных выше, вы можете либо запустить их с помощью сценария выполнения, либо также запустить их как собственные команды Composer. Например, описанный ниже обработчик можно выполнить, запустив composer test :

  Подобно команде run-script , вы можете дать дополнительные аргументы сценариям, например, composer test — —filter передаст —filter вместе со phpunit .

  Примечание. Перед выполнением сценариев bin-dir Composer временно помещается поверх переменной среды PATH, чтобы двоичные файлы зависимостей были доступны напрямую. В этом примере независимо от того, находится ли phpunit файл phpunit на самом деле в vendor/bin/phpunit или bin/phpunit , он будет найден и выполнен.

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

  • отключите его для всех команд, используя время process-timeout ключа конфигурации ,
  • отключите его для текущих или будущих вызовов composer, используя переменную окружения COMPOSER_PROCESS_TIMEOUT ,
  • для конкретного вызова с использованием флага —timeout команды run-script ,
  • используя статический помощник для конкретных сценариев.

  Отключить тайм-аут для определенных сценариев со статическим помощником непосредственно в файле composer.json:

  < "scripts": < "test": [ "Composer\\Config::disableProcessTimeout", "phpunit" ] > >

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

  Также можно установить глобальную переменную окружения,чтобы отключить таймаут всех последующих скриптов в текущем терминальном окружении:

  export COMPOSER_PROCESS_TIMEOUT=0

  Чтобы отключить тайм-аут одного вызова скрипта, вы должны использовать команду run-script composer и указать параметр —timeout :

  php composer.phar run-script --timeout=0 test

  Referencing scripts

  Чтобы разрешить повторное использование скрипта и избежать дублирования, вы можете вызвать скрипт из другого, добавив к имени команды префикс @ :

  < "scripts": < "test": [ "@clearCache", "phpunit" ], "clearCache": "rm -rf cache/*" > >

  Вы также можете обратиться к скрипту и передать ему новые аргументы:

  < "scripts": < "tests": "phpunit", "testsVerbose": "@tests -vvv" > >

  Вызов команд Композитора

  Для вызова команд Composer вы можете использовать @composer , который автоматически разрешит все, что в данный момент используется composer.phar:

  < "scripts": < "test": [ "@composer install", "phpunit" ] > >

  Одним из ограничений этого является то, что вы не можете вызывать несколько команд composer подряд, например @composer install && @composer foo . Вы должны разделить их на массив команд JSON.

  выполнение PHP-скриптов

  Для выполнения сценариев PHP вы можете использовать @php , который автоматически разрешит любой используемый в настоящее время процесс php:

  < "scripts": < "test": [ "@php script.php", "phpunit" ] > >

  Одним из ограничений этого является то, что вы не можете вызывать несколько команд подряд, например, @php install && @php foo . Вы должны разделить их на массив команд JSON.

  Вы также можете вызвать скрипт shell / bash, в котором будет PHP_BINARY путь к исполняемому файлу PHP в виде PHP_BINARY env var.

  Установка переменных окружения

  Чтобы установить переменную среды кроссплатформенным способом, вы можете использовать @putenv :

  < "scripts": < "install-phpstan": [ "@putenv COMPOSER=phpstan-composer.json", "composer install --prefer-dist" ] > >

  Custom descriptions.

  Вы можете установить собственные описания сценариев с помощью следующего в вашем composer.json :

   "scripts-descriptions":  "test": "Run all tests!" > >

  Описания используются в командах composer list или composer run -l для описания того, что скрипты делают при запуске команды.

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

  Источник