Внедряем Composer в Bitrix

Менеджер зависимостей PHP. Неотъемлемая часть мира современного PHP, сложно себе представить современный без зависимостей.

Autoloader

Composer, помимо того, что является менеджером зависимостей, еще выполяет задачу динамического подключения классов (autoloader). Для того, чтобы работал автолоадер, необходимо подключить файл /vendor/autoload.php, в котором composer сгенерировал статическую карту подключения файлов.

Карта статическая, и перегенирируется каждый раз при установке или добавлении/обновлении/удалении библиотек. Нельзя просто взять и скопировать папку в vendor

PSR4 vs Bitrix autoloader

Сообществом PHP был принят свой стандарт правил для автоматической подгрузки классов, последняя редакция которого была формализована в PSR4 (rus).

Bitrix принял свою стратегию автоладов, основнная на модулях, и которая подтвергается критике со стороны сообщества.

Можно без проблем подружить, подключив в init.php путь к autoload.php

require_once($_SERVER['DOCUMENT_ROOT'] . '/vendor/autoload.php');

И получив автолады из обоих миров.

Есть ряд компаний на рынке которые исключительно применяют PSR4 принцип автолоада, публикуя свою не модульно ориентированную библиотеку классов на уровне, к примеру, /local/myVendorDirectoryName.

Composer/installers

Composer имеет интеграцию во все FW и современные CMS (В т.ч. modx, wordpress, bitrix, joomla, drupal).

Для этого используется расширение composer/installers, которое позволяет органичено управлять сущностями FW/CMS через менеджер зависимостей.

Например адаптация composer под Bitrix позволяет нам установить через composer помимо обычных пакетов.

  • Модуль (поставит модуль в папку bitrix/modules)
  • Комонент (поставить модуль в папку bitrix/components)
  • Шаблон (хз зачем)

Для того чтобы на твой проект можно было установить bitrix пакеты через composer необходимо установить параметр директории ядра bitrix, пример:

{
    "config": {
        "bitrix-dir": "bitrix"
    }
}

Таким образом composer bitrix-модуль поставит в bitrix/modules, а остальные пакеты по умолчанию будут лежать в vendor.

Для того, чтобы написать свой модуль, который установится как bitrix модуль — необходимо указать type в параметре и завимость от composer/installers.

Работа с composer’ом в проекте.

На всех наших серверах установлен composer по умолчанию. На серверах клиентов мы тоже его устанавливаем глобально. Если он не установлен — дергаем старших или Костю с просьбой установить глобально.

Может попасться редкий случай когда composer не установлен глобально, тогда можно попробовать установить нужную зависимость через локальный файл composer.phar, который можно скачать с офф сайта composer. Но это костыль. Плюс в php может быть не установлена поддержка .phar — и тогда вообще ничего не получится.

Где должны лежать composer конфиги

Правильная структура проекта: конфиги (composer.json & composer.lock) лежат в корне, выше document_root, т.е. недоступные веб-серверу по прямой ссылке.

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

На некоторых проектах вы можете найти composer.json & vendor в local, из соображений безопасности и примитивной защиты от стандартных ботов которые парсят /composer.json на предмет уязвимостей.

Для новых проектов файлы composer.json & composer.lock нужно размещать в корне

Composer и git

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

Т.е. оба конфига нужно добавлять под отслеживание git.

Папка vendor должна быть обязательно в исключениях

Bitrix composer.json

У битрикса есть свой конфиг composer’a в корне ядра, начиная с 18.5+ версии. Называется composer-bx.json и содержит в себе зависимости ядра, которые развивает отдельно от зависимостей проекта.

Чтобы не устанавливать две дирректории, зависимостей и не ловить конфликты используется composer-merge-plugin. В основной файл проекта добавляется ссылка на битриксовый конфиг json и зависимость от плагина. Пример:

{
    "require": {
        "wikimedia/composer-merge-plugin": "dev-master"
    },
    "extra": {
        "merge-plugin": {
            "require": [
                "bitrix/composer-bx.json"
            ]
        }
    }
}

Файл с примером лежит в корне ядра bitrix с названием composer.json.example.

Разные источники

По умолчанию, можно подключить composer пакет из packagist.org. Для этого пакет должен быть публичным на github.com (к примеру).

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

Рекомендации

  • Устанавливайте в composer.json стабильность stable, и не понижайте ее
  • Устанавливайте в зависимость расширения PHP которые вы используете (phpstorm подсказывает на этот счет)
  • Устанавливайте в зависимость версию PHP на которой вы разрабатываете
  • Не используйте по возможности dev-master
  • оптимизируйте автолоад с помощью composer dump-autoload --optimize

Пример файла:

{
  "name": "test/main",
  "description": "",
  "extra": {
    "bitrix-dir": "bitrix"
  },
  "repositories": [
      {
        "type": "git",
        "url": "git@gitlab.com:test/test.git"
      }
  ],
  "require": {
    "test/test": "*",
    "php": ">=7.2",
    "monolog/monolog": "^1.24"
  },
  "minimum-stability": "stable"
}

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *