Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Многие пакеты - это приложения командной строки, еще их называют<a>cli-утилитами</a>. Пользователи по-разному взаимодействуют с ними: запускают команды, передают аргументы и опции, выводят результат. Все взаимодействие происходит интерактивным образом через терминал. Для запуска файлов из командной строки в Composer существует секция bin конфигурационного файла composer.json. Рассмотрим на примере:

2 Эта запись означает, что при установке пакета в операционной системе будет создан файл с именем php-package. Это не просто файл, а<a>символическая ссылка</a>. Запуск этого файла-ссылки приведет к запуску файла вашего проекта по адресу bin/php-package.

3 Как можно заметить, имя ссылки задается именем файла и совпадает с ним. Также обратите внимание, что ссылок может быть множество - столько, сколько вы сами укажете в секции bin.

4 Месторасположение символической ссылки и способ ее запуска из командной строки различаются в зависимости от способа установки пакета:

5 <ul><li>Локального</li>

6 <li>Глобального с командой global - например, composer global vendor/package</li>

7 </ul>Рассмотрим каждый случай отдельно.

8 <h2>Глобальная установка: генерация ссылок и запуск исполняемых файлов</h2>

9 При глобальной установке пакета Composer создает символические ссылки в каталоге $HOME/.composer/vendor/bin. Другими словами, при создании ссылок в домашнюю директорию пользователя, от имени которого запускалась установка пакета, будет добавлен каталог .composer/vendor/bin со ссылками. Это каталог по умолчанию, но путь к нему нам надо<a>самостоятельно прописать</a>в переменной окружения PATH. После этого мы можем запускать приложение по имени символической ссылки из командной строки, находясь в любой точке файловой системы. Так происходит, потому что при поиске исполняемых файлов командная оболочка ищет их последовательно по всем путям, прописанным в переменной окружения PATH.

10 В зависимости от версии Composer директория по умолчанию может различаться. Кроме того, это значение можно<a>конфигурировать</a>. Чтобы посмотреть, в какую конкретно директориюcomposerскладывает ссылки на исполняемые файлы, можно воспользоваться командой composer global config bin-dir --absolute:

11 Посмотреть содержание переменной окружения PATH в вашей системе можно с помощью команды echo:

12 <h3>Пример</h3>

13 Давайте создадим и опубликуем пакет, который для краткости и наглядности будет очень простым. Этот пакет будет состоять всего из двух исполняемых файлов, запуск которых выведет приветствие и прощание с Хекслетом.

14 Структура проекта:

15 Содержимое исполняемого файла sayHi:

16 Содержимое исполняемого файла sayBye:

17 Содержимое конфигурационного файла composer.json:

18 Обсудим исполняемые файлы немного подробнее:

19 <ol><li>Чтобы запускать файлы из командной строки, пользователь должен иметьправо на выполнение этого файла(атрибут x)</li>

20 <li>Если исполняемый файл содержит код, то надо указать интерпретатор, который будет исполнять этот код при запуске исполняемого файла. Это делается с помощью<a>шебанга</a>. В примере выше мы указалиphpв качестве интерпретатора, а путь к нему задали с помощью специальной утилиты<a>env</a>. Мы решили не указывать абсолютный путь, потому что в разных системахphpможет находиться по совершенно разным путям</li>

21 </ol>В итоге, мы подготовили пакет. После публикации он становится доступен для установки под именем hex/small-talk-with-hexlet.

22 Теперь установим этот пакет в систему глобально. Но сначала убедимся, что никаких символических ссылок в директории не существует:

23 Здесь с помощью фильтра grep мы попытались найти файлы, содержащие в своем имени строчку "say" (как наши ссылки в секции bin). Поиск не дал результатов, потому что до установки пакета таких файлов нет.

24 Далее глобально устанавливаем пакет в систему:

25 Теперь воспользуемся grep и снова проверим директорию установки исполняемых файлов:

26 Как и ожидалось, в этом каталоге находятся символические ссылки - об этом свидетельствует первый символ l, определяющий тип файла в строке атрибутов файла lrwxrwxrwx. Эти ссылки можно запускать из любой точки файловой системы:

27 Из примера видно, что мы можем успешно запускать одни и те же команды из разных директорий. Причины, по которым это происходит, мы подробно обсуждали выше.

28 <h2>Что происходит при локальной установке</h2>

29 В подавляющем большинстве случаев разработчики устанавливают пакеты не глобально, а локально. При такой установке пакеты привязываются к конкретному проекту и размещаются внутри его каталога по пути ./vendor/. При этом ссылки на исполняемые файлы устанавливаемых пакетов Composer размещает в каталоге ./vendor/bin.

30 Ссылки на исполняемые файлы локально установленных пакетов заточены под использование в скриптах, в секции scripts конфигурационного файла composer.json. Для этого существует особенный синтаксис. Эту тему мы проходили в<a>уроке, посвященном скриптам</a>.

31 Естественно, к символическим ссылкам можно также обратиться напрямую, указав нужный путь. Давайте рассмотрим это на примере, подключив к нашему разрабатываемому проекту small-talk-with-hexlet пакет<a>PHP_CodeSniffer</a>:

32 Для примера возьмем команду composer require --dev some_package. Если установить пакет с флагом --dev в корневом каталоге проекта, он автоматически добавится в зависимости проекта, то есть в секцию require-dev файла composer.json. Этой возможностью мы и воспользовались.

33 Посмотрим, какие новые файлы появились в директории проекта:

34 Как и ожидалось, появился каталог ./vendor, в котором лежит код подключенного пакета и других пакетов, от которых он зависит.

35 Как узнать место, где Composer хранит ссылки на исполняемые файлы локально подключаемых пакетов? Это можно сделать с помощью команды composer config bin-dir.

36 Обратите внимание, что здесь нет команды global. В нашем случае это каталог ./vendor/bin. Заглянем в него:

37 В коде выше видно, что при установке PHP_CodeSniffer добавилось два исполняемых файла для запуска разных программ. Давайте запустим phpcs. Этолинтер- утилита, которая проверяет код на соответствие стандартам:

38 Программа отработала корректно и завершилась молча - без дополнительного вывода отчета об ошибках. Так произошло, потому что в наших файлах не было никаких нарушений<a>оформления кода</a>.

39 Затем была попытка запустить исполняемый файл из командной строки только по имени, но она привела к неудаче - bash: phpcs: command not found. Командная оболочка просто не нашла файл - при глобальной установке все было бы по-другому.

40 <h2>Выводы</h2>

41 В этом уроке мы рассмотрели общие принципы и отдельные нюансы работы Composer с исполняемыми файлами проекта. Важно отметить, что эти принципы характерны для большинства других пакетных менеджеров из разных языков - например,<a>менеджера пакетов Node.js</a>в JavaScript. Если в будущем вам придется столкнуться с чем-то подобным, вам будет намного проще.

42 Пример глобальной установки пакета: