DevTrends Logo

Как навести порядок в структуре PHP-проекта с помощью Composer Installers

01 Jun, 2026
⭐ 1,437 🔱 402 👥 45

Вы когда-нибудь задумывались, почему в одном проекте на WordPress плагины лежат в wp-content/plugins, в Drupal модули ищутся в modules, а стандартный Composer упорно пытается запихнуть всё в vendor? Если вы пишете код под конкретную CMS или фреймворк, эта «битва за папки» может изрядно подпортить нервы.

Стандартное поведение Composer — складывать зависимости в одну кучу в vendor. Это логично для библиотек, но совершенно не подходит для тем оформления, плагинов или специфических модулей расширения. Проект composer/installers — это как раз тот невидимый клей, который заставляет пакеты приземляться именно туда, где их ожидает увидеть ваша система.

Зачем это нужно, если есть стандартный vendor

Казалось бы, зачем городить огород, если можно просто подключить автозагрузку? Проблема в том, что многие системы (тот же Bitrix, WordPress или Roundcube) имеют жесткую структуру каталогов. Они физически не увидят ваш плагин, если он не лежит в конкретной папке.

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

Кстати, проект живет на GitHub уже больше десяти лет. У него больше тысячи звезд, и он стал фактически стандартом индустрии для тех, кто работает с PHP-фреймворками «старой школы» или популярными CMS.

Реклама

Continuous Integration

Как это работает на практике

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

Пример composer.json для вашего пакета:

{
    "name": "my_org/ftp_plugin",
    "type": "cakephp-plugin",
    "require": {
        "composer/installers": "~1.0"
    }
}

Когда пользователь выполнит composer install, пакет не затеряется в недрах vendor/my_org/ftp_plugin. Он автоматически отправится в папку Plugin/Ftp/. Магия? Нет, просто четко прописанные правила маппинга типов пакетов на пути в файловой системе.

Какие системы поддерживаются

Список поддерживаемых платформ в репозитории выглядит как энциклопедия PHP-разработки. Там есть всё: от гигантов вроде WordPress, Drupal и Laravel до специфических вещей вроде Shopware, MediaWiki или даже систем управления игровыми серверами.

Интересный момент: для Bitrix разработчики добавили поддержку типа bitrix-d7-module, что позволяет корректно работать с современным ядром системы. Если вы поддерживаете старые проекты на Kohana или CodeIgniter, этот инструмент тоже станет спасением — для них зарезервированы свои типы установки.

Тонкая настройка под себя

Иногда стандартные пути не устраивают. Например, вы хотите, чтобы все плагины WordPress ставились в папку content/plugins вместо стандартной wp-content/plugins. Это легко решается в основном composer.json вашего проекта (не в пакете плагина, а там, где вы его подключаете).

{
    "extra": {
        "installer-paths": {
            "content/plugins/{$name}/": ["type:wordpress-plugin"]
        }
    }
}

Здесь можно использовать переменные {$name}, {$vendor} и {$type}. Это дает гибкость: можно группировать пакеты по вендору или вовсе задавать индивидуальный путь для конкретного репозитория.

Есть ли подвох

Авторы проекта честно предупреждают: если вы создаете современное приложение с нуля на Symfony или Laravel, скорее всего, вам этот инструмент не нужен. В Composer 2.1 появилась встроенная возможность узнавать список установленных пакетов через Composer\InstalledVersions. Современный подход — оставлять всё в vendor и позволять приложению самому находить нужные плагины программно.

Однако для огромного пласта существующих CMS, которые «привыкли» к своей структуре папок, composer/installers остается незаменимым.

Еще один нюанс: проект принципиально не поддерживает динамические пути, которые мог бы задавать автор пакета. Это сделано в целях безопасности. Представьте, если бы автор библиотеки мог прописать в конфиге путь /etc/ или просто затереть корень вашего проекта при установке. Поэтому пути жестко зашиты в коде инсталлеров или переопределяются только вами как владельцем проекта.

Стоит ли использовать

Если ваша работа связана с WordPress, Drupal, Bitrix или любой другой системой из огромного списка поддержки — однозначно да. Это освобождает от написания костылей и ручного копирования файлов после каждого обновления зависимостей.

Проект стабилен, проверен временем и поддерживается самой командой Composer. Это тот случай, когда маленькая утилита решает одну конкретную проблему, но делает это идеально. Если же вы строите архитектуру нового приложения, посмотрите сначала в сторону InstalledVersions, чтобы не плодить лишние сущности вне папки vendor.

Проект на GitHub