Двоичные файлы поставщика и каталог vendor/bin

1. Что такое двоичный код поставщика?
2. Как он определяется?
3. Что делает определение бинарного кода поставщика в composer.json?
4. Что происходит, когда Composer запускается на composer.json, определяющем двоичные файлы поставщиков?
5. Что происходит, когда Composer запускается на composer.json, который имеет зависимости от бинарных файлов поставщика?
6. Как насчет Windows и .bat файлов?
7. Можно ли установить двоичные файлы поставщиков где-нибудь помимо vendor/bin?

Что такое двоичный код поставщика? #

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

Если пакет содержит другие сценарии, которые не нужны пользователям пакета (например, скрипты сборки или компиляции), этот код не должен быть указан как двоичный код поставщика.

Как он определяется? #

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

{
 "bin": ["bin/my-script", "bin/my-other-script"]
}

Что означает определение поставщика? Двоичные в composer.json делать? #

Он инструктирует Composer установить бинарные файлы пакета в vendor/bin для любого проекта, который зависит от этого проекта.

Это удобный способ выставить полезные сценарии, которые в противном случае были бы скрыты глубоко в каталоге vendor/.

Что происходит, когда Composer запускается на composer.json, определяющем двоичные файлы поставщиков? #

Для двоичных файлов, которые пакет определяет напрямую, ничего не происходит.

Что происходит, когда Composer запускается на composer.json, который имеет зависимости от бинарных файлов поставщика? #

Композитор ищет двоичные файлы, определенные во всех зависимостях. Символьная ссылка создается из двоичных файлов каждого зависимостей в vendor/bin.

Скажем, пакет my-vendor/project-a установил двоичные файлы следующим образом:

{
 "name": "my-vendor/project-a",
 "bin": ["bin/project-a-bin"]
}

Запуск composer install для этого composer.json не будет делать ничего с bin/project-a-bin.

Скажем, у проекта my-vendor/project-b есть требования, такие как:

{
 "name": "my-vendor/project-b",
 "require": {
 "my-vendor/project-a": "*"
 }
}

Запуск для этого composer.json будет рассматривать все зависимости проекта-b и устанавливать их в vendor/bin.

В этом случае Composer сделает vendor/my-vendor/project-a/bin/project-a-bin доступным как vendor/bin/project-a-bin. На Unix-подобной платформе это достигается созданием символической ссылки.

Как насчет Windows и .bat файлов? #

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

• Файл .bat генерируется автоматически для ссылки на двоичный файл
• Прокси-файл в стиле Unix с тем же именем, что и двоичный, генерируется автоматически (полезно для Cygwin или Git Bash)

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

Можно ли установить двоичные файлы поставщиков где-нибудь помимо vendor/bin? #

Да, есть два способа указать двоичное расположение альтернативного поставщика:

1. Установка настройки конфигурации bin-dir в composer.json
2. Установка переменной среды COMPOSER_BIN_DIR

Пример современного выглядит следующим образом:

{
 "config": {
 "bin-dir": "scripts"
 }
}

Запуск composer install для этого composer.json приведет к тому, что все двоичные файлы поставщиков будут установлены в scripts/ вместо vendor/bin/.

Вы можете установить bin-dir в ./, чтобы разместить двоичные файлы в корне проекта.