Require dir vendor autoload php что это

Composer — менеджер зависимостей для PHP

Composer (getcomposer.org) — это относительно новый и уже достаточно популярный менеджер зависимостей для PHP. Вы можете описать от каких библиотек зависит ваш проект и Composer установит нужные библиотеки за вас! Причём Composer — это не менеджер пакетов в классическом понимании. Да, он оперирует с сущностями, которые мы будем называть «пакетами» или библиотеками, но устанавливаются они внутрь каждого проекта отдельно, а не глобально (это одно из основных отличий от старого-доброго PEAR).

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

Изначально он был спроектирован и разработан двумя людьми Nils Adermann и Jordi Boggiano, сейчас в проекте участвует более двадцати контрибьюторов, Проект написан на PHP 5.3, распространяется под лицензией MIT и доступен на github.

Первые коммиты были сделаны апреле 2011 года и на сегодняшний день Composer находится в стадии «alpha3». Однако, он уже достаточно стабилен и используется многими популярными PHP проектами (например, Symfony 2). Список проектов использующих Composer можно посмотреть на сайте packagist.org — это официальный репозиторий Composer пакетов. Кстати, на недавней конференции Devconf 2012 разработчик фреймворка Yii в своём докладе упомянул, что Yii2 скорее всего тоже будет использовать Composer.

В этой статье я кратко опишу основные возможности Composer и мы попробуем создать демонстрационный проект использующий Composer для загрузки необходимых библиотек. Все примеры будут доступны на github.com и bitbucket.org.

Что умеет Composer?

• Скачивать пакеты и их зависимости;
• по умолчанию, пакеты скачиваются из официального репозитория packagist.org. Любой человек может свободно добавить туда свой пакет, чтобы сделать его установку максимально лёгкой и удобной для всего мира;
• пакеты можно скачивать не только с packagist.org, но и из любого git, mercurial или svn репозитория;
• при скачивании пакетов с github.com или bitbucket.org не требуется установленной системы контроля версий (git или hg), Composer работает через API этих сайтов;
• git/hg/svn репозиторий с пакетом может находиться не только на одном из перечисленных выше сайтов, но в любом другом месте, например, в локальной сети предприятия или вообще на локальном жестком диске;
• кроме того, устанавливаемая библиотека не обязательно должна быть оформлена в виде Composer-пакета, вы можете сделать установку из любого git/hg/svn репозитория произвольной структуры;
• наконец, устанавливаемый пакет не обязательно должен быть git/hg/svn репозиторием, это может быть произвольный zip файл доступный по любому uri!
• все пакеты устанавливаются в текущую директорию (откуда была выполнена команда install), это позволяет иметь несколько различных версий библиотек при работе над разными проектами параллельно;
• команда update обновляет все установленные (или установит заново случайно удалённые) пакеты до свежих версий. А может и не обновлять версии до самых свежих, если создать специальный composer.lock файл — это позволяет зафиксировать комбинацию из стабильных версий всех используемых в проекте библиотек;
• после установки пакетов автоматически генерируется autoload.php, с помощью которого можно подключить установленные библиотеки в коде вашего проекта. При подготовке Composer-пакета рекомендуется использовать PSR-0 — стандарт расположения и именования php файлов, чтобы autoload смог их легко найти. В любом случае, автор пакета может описать правила, по которым autoload будет искать файлы тех или иных классов или неймспейсов. Если вы устанавливаете библиотеку, которая не оформлена как Composer-пакет (например, произвольный git репозиторий с github), то задача описания правил autoload ложится на ваши плечи. Так что никакой магии с генерируемым autoload.php нет — он умеет загружать всё (даже библиотеки с набором функций вне классов), главное, чтобы были описаны правила (автором библиотеки или вами).

Рабочий пример: используем Composer в своём проекте

Чтобы разобраться, как пользоваться Composer’ом, напишем маленький проектик на PHP: «Super Hello World». Поскольку мы не хотим изобретать велосипед и писать код «с нуля», возьмём готовые библиотеки и фреймворки.

1. микрофреймворк Silex (доступен в виде Composer пакета на packagist.org),
2. шаблонизатор Twig (доступен в виде Composer пакета на packagist.org),
3. наш собственный логер посещений SuperLogger, который я оформил в виде Composer-пакета и опубликовал на github
4. нашу старую, но любимую легаси-библиотеку superlib, которая состоит из мешанины классов без неймспейсов и функций без классов; библиотека опубликована на github, но не является оформленным Composer-пакетом

Как мы это сделаем теперь: используем Composer — он сам скачает все библиотеки и сгенерирует для нас autoload.php. Кроме того, если мы захотим показать «Super Hello World» коллегам, достаточно будет опубликовать код нашего проекта на github (или ещё где-нибудь), не включая всех требуемых библиотек в репозиторий и не готовя длинной инструкции по их установке. Нашим коллегам достаточно будет скачать (склонировать) «Super Hello World» и выполнить команду

Composer распространяется в виде одного файла composer.phar (phar — это php-архив) — по сути это PHP скприт, который может принимать несколько команд (install, update, . ) и умеет скачивать и распаковывать библиотеки.

Кстати, немного о синтаксисе запуска.
Если вы работаете под Windows, то скорее всего вы будете писать что-то вроде

Можно упростить себе жизнь, создав composer.bat и положив его в %PATH%.

В Linux и OS X можно настроить на исполнение команду типа

composer.json

Итак, мы готовы написать наш Super Hello World проект. И я его только что написал: http://github.com/pqr/superhelloworld. Код состоит из одного index.php файла в директории web и шаблона layout.twig в директории views.

Голова всему — это файл composer.json. Он должен быть в корне проекта, в нашем случае рядом с директориями web и view. В этом файле необходимо указать от каких библиотек зависит наш проект. Кроме того, если эти библиотеки не являются оформленными Composer-пакетами, то нужно указать некоторую дополнительную информацию об устанавливаемой библиотеке (например, описать правила автозагрузки классов и функций для autoload.php).

composer.json, как вы догадались, имеет формат данных JSON. На вопрос "почему именно JSON?" разработчики Composer отвечают "Потому что. Просто примите это.".

Нам нужно описать один js-объект, в котором будут находиться все инструкции. Первая и самая главная инструкция: require.

Подключаем пакеты с сайта packagist.org

Здесь я описал зависимость проекта от PHP версии 5.3.0 и выше, от silex (микрофреймворк) и от twig (шаблонизатор). Silex и Twig доступны в виде Composer-пакетов на сайте packagist.org, поэтому дополнительных настроек не требуют. Замечу, что Silex в свою очередь зависит ещё от нескольких пакетов — все они будут скачены и установлены автоматически.

Имя пакета состоит из двух частей разделёных косой чертой: названия поставщика (vendor name) и названия библиотеки. Названием поставщика зачастую является ник автора или имя компании. Иногда, название поставщика совпадает с именем самой библиотеки или фреймворка.

Для каждого пакета обязательно нужно указать номер версии. Это может быть бранч в репозитории, например, «dev-master» — приставка dev сигнализирует, что это имя бранча, а сам бранч соответсвенно называется «master». Для mercurial репозитория аналогичная запись будет выглядеть как «dev-default». В качестве номера версии можно указать и более сложные правила, используя операторы сравнения. Кстати, если вы скачиваете код из удалённого репозитория, то Composer сканирует теги и имена веток в этом репозитории на предмет чего-то похожего на номера версий, например тег «v1.2.3» будет использован как указатель на версию 1.2.3.

Подключаем на собственный Compsoer-пакет

Далее, подключим наш собственный пакет SuperLogger, который правильно оформлен, но опубликован не на packagist.org, а на github:

Чтобы Composer знал где искать пакет «mycompany/superlogger», мы добавили массив repositories со ссылкой на соотвествующий github репозиторий. Обратим внимание, что записи в массиве repositories напрямую никак не связаны с блоком require — между пакетами и репозиториями не указано соответствие. На сколько я понял, Composer ищет все требуемые пакеты во всех указанных репозиториях (в т.ч. на сайте packagist.org) и скачивает найденные совпадения по каким-то внутренним приоритетам. Более глубоко я в этом моменте ещё не разбирался, поправьте меня, если кто-то знает детали.

Подключаем произвольный git репозиторий

Теперь подключим нашу легаси-библиотеку superlib, которая лежит на github, но не является оформленным Composer-пакетом, т.к. она очень старая.

В массив repositories добавился объект, который целиком описывает пакет pqr/superlib. По сути, это то описание, которое должен был бы сделать автор библиотеки и положить его внутри своего репозитория. Но по условиям задачи, superlib не является оформленным Composer-пакетом, поэтому нам пришлось создать его описание в рамках Super Hello World проекта. Аналогичным образом можно подключить любую другую библиотеку, в т.ч. простой zip файл.

Подключаем простой zip файл

Например, вот как могло бы выглядеть описание зависимости от шаблонизатора Smarty, распространяемого в виде zip файла с исходниками в svn:

Инстукция autoload

Вернёмся к нашему проекту.
Описывая «pqr/superlib», мы добавили инструкцию autoload. В ней указан файл timer.php, в котором будущий автозагрузчик будет искать классы и указали файл с функциями lib_functions.php — он будет принудительно подключаться в начале autoload.php.

• в корне лежит файл composer.json;
• в корне находятся директории web и views;
• внутри директории web лежит файл с «бизнес-логикой» нашего приложения: index.php;
• внутри директории views лежит файл шаблона layout.twig;
• дополнительно, в папку web я положил .htaccess (для apache) и web.config (для IIS 7.5) с правилами mod_rewrite/url rewriter — непосредсвенно к настройке Composer они отношения не имеют.

Запускаем composer install

• файл autoload.php
• служебные директории .composer и composer
• pimple — пакет, который подтянулся вместе с микрофреймворком Silex
• silex — сам микрофреймворк, его мы явным образом затребовали при описании зависимостей
• symfony — некоторые компоненты из Symfony 2, которые требуются для работы Silex
• twig — шаблонизатор, который мы также явно запросили
• mycompany — внутри этой директории будет находиться репозиторий superlogger скаченный с github
• pqr — внутри этой директории будет находиться репозиторий superlib, также скаченный с github

Как создать собственный Composer пакет?

В этом проекте мы использовали Composer с точки зрения потребителя библиотек. А как самому создать Composer пакет, чтобы любой другой человек смог им воспользоваться?

На самом деле, один из таких пакетов я создал, когда подготавливал примеры для этой статьи. В корне репозитория superlogger лежит файл composer.json похожей структуры, который описывает сам пакет и его зависимости (в случае с superlogger зависимостей нет). Другие примеры: репозитории silex и twig, которые скачались в папку vendor — все они имеют файл composer.json в корне — смотрите, изучайте!

И, конечно, не забывайте про документацию на официальном сайте getcomposer.org/doc/.
Эту тему я оставлю вам для самостоятельной проработки.

Подведём итоги

В этой статье я рассказал, что такое Composer, его историю и описал основные возможности. Мы с вами попробовали создать проект, который использует Composer для установки пакетов с сайта packagist.org и из наших собственных репозиториев.

1. Скачате Composer (getcomposer.org/download/)
2. Скачате superhelloworld (git clone git://github.com/pqr/superhelloworld.git)
3. Установите зависимости (cd superhelloworld && php composer.phar install)
4. Изучите появившуюся папку vendor и сгенерированный autoload.php
5. Используте Composer в своих проектах
   …
6. PROFIT.

В своих рабочих проектах я использую систему контроля версий Mercurial. Этот пример вы также можете скачать и установить через Composer с сайта bitbucket.org: http://bitbucket.org/pqr/superhelloworld

Внимание: к сожалению, при использовании Composer с Mercurial репозиториями на Windows машине я нашел один баг. Если вы устанавливаете зависимости в проекте, который находится на диске отличном от системного диска, то получите ошибку. Например, системный диск C:, а проект вы разворачиваете где-то в папке D:\someproject и ваш проект зависит от библиотек опубликованных в виде Mercurial репозиториев — Composer не сможет правильно их прочитать. Собираюсь в ближайшее время пофиксить этот баг и отправить pull request в официальный репозиторий Composer’а.

Basic usage#

For our basic usage introduction, we will be installing monolog/monolog , a logging library. If you have not yet installed Composer, refer to the Intro chapter.

Note: for the sake of simplicity, this introduction will assume you have performed a local install of Composer.

composer.json : Project setup#

To start using Composer in your project, all you need is a composer.json file. This file describes the dependencies of your project and may contain other metadata as well. It typically should go in the top-most directory of your project/VCS repository. You can technically run Composer anywhere but if you want to publish a package to Packagist.org, it will have to be able to find the file at the top of your VCS repository.

The require key#

The first thing you specify in composer.json is the require key. You are telling Composer which packages your project depends on.

As you can see, require takes an object that maps package names (e.g. monolog/monolog ) to version constraints (e.g. 1.0.* ).

Composer uses this information to search for the right set of files in package «repositories» that you register using the repositories key, or in Packagist.org, the default package repository. In the above example, since no other repository has been registered in the composer.json file, it is assumed that the monolog/monolog package is registered on Packagist.org. (Read more about Packagist, and about repositories).

Package names#

The package name consists of a vendor name and the project’s name. Often these will be identical — the vendor name only exists to prevent naming clashes. For example, it would allow two different people to create a library named json . One might be named igorw/json while the other might be seldaek/json .

Read more about publishing packages and package naming. (Note that you can also specify «platform packages» as dependencies, allowing you to require certain versions of server software. See platform packages below.)

Package version constraints#

In our example, we are requesting the Monolog package with the version constraint 2.0.* . This means any version in the 2.0 development branch, or any version that is greater than or equal to 2.0 and less than 2.1 ( >=2.0 <2.1 ).

Please read versions for more in-depth information on versions, how versions relate to each other, and on version constraints.

How does Composer download the right files? When you specify a dependency in composer.json , Composer first takes the name of the package that you have requested and searches for it in any repositories that you have registered using the repositories key. If you have not registered any extra repositories, or it does not find a package with that name in the repositories you have specified, it falls back to Packagist.org (more below).

When Composer finds the right package, either in Packagist.org or in a repo you have specified, it then uses the versioning features of the package’s VCS (i.e., branches and tags) to attempt to find the best match for the version constraint you have specified. Be sure to read about versions and package resolution in the versions article.

Note: If you are trying to require a package but Composer throws an error regarding package stability, the version you have specified may not meet your default minimum stability requirements. By default, only stable releases are taken into consideration when searching for valid package versions in your VCS.

You might run into this if you are trying to require dev, alpha, beta, or RC versions of a package. Read more about stability flags and the minimum-stability key on the schema page.

Installing dependencies#

To initially install the defined dependencies for your project, you should run the update command.

This will make Composer do two things:

• It resolves all dependencies listed in your composer.json file and writes all of the packages and their exact versions to the composer.lock file, locking the project to those specific versions. You should commit the composer.lock file to your project repo so that all people working on the project are locked to the same versions of dependencies (more below). This is the main role of the update command.
• It then implicitly runs the install command. This will download the dependencies’ files into the vendor directory in your project. (The vendor directory is the conventional location for all third-party code in a project). In our example from above, you would end up with the Monolog source files in vendor/monolog/monolog/ . As Monolog has a dependency on psr/log , that package’s files can also be found inside vendor/ .

Tip: If you are using git for your project, you probably want to add vendor in your .gitignore . You really don’t want to add all of that third-party code to your versioned repository.

Commit your composer.lock file to version control#

Committing this file to version control is important because it will cause anyone who sets up the project to use the exact same versions of the dependencies that you are using. Your CI server, production machines, other developers in your team, everything and everyone runs on the same dependencies, which mitigates the potential for bugs affecting only some parts of the deployments. Even if you develop alone, in six months when reinstalling the project you can feel confident the dependencies installed are still working even if your dependencies released many new versions since then. (See note below about using the update command.)

Note: For libraries it is not necessary to commit the lock file, see also: Libraries — Lock file.

Installing from composer.lock #

If there is already a composer.lock file in the project folder, it means either you ran the update command before, or someone else on the project ran the update command and committed the composer.lock file to the project (which is good).

Either way, running install when a composer.lock file is present resolves and installs all dependencies that you listed in composer.json , but Composer uses the exact versions listed in composer.lock to ensure that the package versions are consistent for everyone working on your project. As a result you will have all dependencies requested by your composer.json file, but they may not all be at the very latest available versions (some of the dependencies listed in the composer.lock file may have released newer versions since the file was created). This is by design, it ensures that your project does not break because of unexpected changes in dependencies.

So after fetching new changes from your VCS repository it is recommended to run a Composer install to make sure the vendor directory is up in sync with your composer.lock file.

Updating dependencies to their latest versions#

As mentioned above, the composer.lock file prevents you from automatically getting the latest versions of your dependencies. To update to the latest versions, use the update command. This will fetch the latest matching versions (according to your composer.json file) and update the lock file with the new versions.

Note: Composer will display a Warning when executing an install command if the composer.lock has not been updated since changes were made to the composer.json that might affect dependency resolution.

If you only want to install, upgrade or remove one dependency, you can explicitly list it as an argument:

Packagist#

Packagist.org is the main Composer repository. A Composer repository is basically a package source: a place where you can get packages from. Packagist aims to be the central repository that everybody uses. This means that you can automatically require any package that is available there, without further specifying where Composer should look for the package.

If you go to the Packagist.org website, you can browse and search for packages.

Any open source project using Composer is recommended to publish their packages on Packagist. A library does not need to be on Packagist to be used by Composer, but it enables discovery and adoption by other developers more quickly.

Platform packages#

Composer has platform packages, which are virtual packages for things that are installed on the system but are not actually installable by Composer. This includes PHP itself, PHP extensions and some system libraries.

php represents the PHP version of the user, allowing you to apply constraints, e.g. ^7.1 . To require a 64bit version of php, you can require the php-64bit package.

hhvm represents the version of the HHVM runtime and allows you to apply a constraint, e.g., ^2.3 .

ext-<name> allows you to require PHP extensions (includes core extensions). Versioning can be quite inconsistent here, so it’s often a good idea to set the constraint to * . An example of an extension package name is ext-gd .

lib-<name> allows constraints to be made on versions of libraries used by PHP. The following are available: curl , iconv , icu , libxml , openssl , pcre , uuid , xsl .

You can use show —platform to get a list of your locally available platform packages.

Autoloading#

For libraries that specify autoload information, Composer generates a vendor/autoload.php file. You can include this file and start using the classes that those libraries provide without any extra work:

You can even add your own code to the autoloader by adding an autoload field to composer.json .

Composer will register a PSR-4 autoloader for the Acme namespace.

You define a mapping from namespaces to directories. The src directory would be in your project root, on the same level as the vendor directory. An example filename would be src/Foo.php containing an Acme\Foo class.

After adding the autoload field, you have to re-run this command:

This command will re-generate the vendor/autoload.php file. See the dump-autoload section for more information.

Including that file will also return the autoloader instance, so you can store the return value of the include call in a variable and add more namespaces. This can be useful for autoloading classes in a test suite, for example.

In addition to PSR-4 autoloading, Composer also supports PSR-0, classmap and files autoloading. See the autoload reference for more information.

Note: Composer provides its own autoloader. If you don’t want to use that one, you can include vendor/composer/autoload_*.php files, which return associative arrays allowing you to configure your own autoloader.

Found a typo? Something is wrong in this documentation? Fork and edit it!

Composer and all content on this site are released under the MIT license.

The magic behind autoloading php files using Composer

Software Engineering, Psychology, Starcraft, Protein, Women && Motorbikes addict.

Newsletter: 1 per week

Become an engineer

Are you creating more bugs than you’re fixing?

Do you feel uncomfortable receiving feedback on your code?

Are you stuck with complex software that needs refactoring?

Do you want to improve your skills to keep up with best practises?

The magic behind autoloading php files using Composer

Foreword

It’s been several years I didn’t start a project from scratch. I mean totally from scratch. All my projects are by default fresh Symfony installations. 2 weeks ago I was recording one of the lectures of this course and when I was preparing a super simple example I run into a Class not found error. This reminded me the good old days of using PHP require_once method so I decided to write a short article about the way Composer is making our life easier and how it actually autoloads files behind the scenes.

Thank you Nils and Jordi for the awesome dependency manager and happy birthday Jordi!

Base line

Don’t overthink what a Namespace is.

Namespace is basically just a Class prefix (like directory in Operating System) to ensure the Class path uniqueness.

Also just to make things clear, the use statement is not doing anything only aliasing your Namespaces so you can use shortcuts or include Classes with the same name but different Namespace in the same file.

Problem

I want to call a public method of a Class encapsulated in a specific Namespace from a different directory.

Об автозагрузке в PHP

Данный метод объявлен УСТАРЕВШИМ начиная с PHP 7.2.0 и его использование крайне не рекомендовано.

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

Уже при этом подходе здравый смысл подсказывал, что в одном файле должен находится один класс, а название класса должно совпадать с названием файла.

• нет возможности регистрации нескольких автозагрузчиков
• нет возможности динамически активировать/деактивировать автозагрузчики

В PHP 5.1.2 (2006 г.) эти проблемы решили через фукнции автозагрузчики.

Автозагрузка через spl_autoload_register

PHP позволяет зарегистрировать любое число функций-автозагрузчиков с помощью функции spl_autoload_register. В случае обращения к несуществующему в данный момент классу, PHP будет вызывать по очереди все зарегистрированные автозагрузчики, передавая им имя класса. Если автозагрузчик знает, где лежит этот класс, он должен подключить файл с ним, PHP увидит, что класс появился, и продолжит выполнение программы. Иначе PHP вызовет следующий автозагрузчик. Если ни один автозагрузчик не подключит файл с классом, то будет выведена ошибка об обращении к несуществующему классу.

Если подключается сторонняя библиотека, то она может зарегистрировать свой автозагрузчик для загрузки своих классов. Таким образом, каждая библиотека может устанавливать свои правила для поиска файлов со своими классами.

Есть fallback для __autoload :

Автозагрузка через composer и PSR-4

Развитием идеи в одном файле один класс стал стандарт PSR-0 (англ.) (устаревший) и его развитие PSR-4 (англ.). PSR-4 говорит как надо называть классы, чтобы по полному имени класса узнать путь к файлу (чтобы потом его подключил автозагрузчик).

Например класс Library\A\B\C следует помещать в файл Library/A/B/C.php . Надо понимать, что это лишь рекомендация, PHP не требует, чтобы имя класса совпадало с именем файла, а неймспейсы с именами папок. Но следование PSR-4 освобождает от написания своего автозагрузчика, можно взять готовый.

Пример пакета foo-bar по PSR-4

На сегодняшний день большинство PHP разработчиков пользуются загручиком из менеджера зависимостей Сomposer. Composer не является только лишь генератором автозагрузчика. Задачи, которые он выполняет намного шире.

Генерация и использование автозагрузчика из composer

В конфигурационном файле composer.json в разделе autoload необходимо указать корневой namespace проекта и корневую папку. Неймспейсы должны оканчиваться \\ , чтобы избежать конфликтов. Например просто Foo будет соответствовать классам в пространстве FooBar , а вот Foo\\ и FooBar\\ уже различны.

Пример раздела в файле composer.json говорящий, что классы из namespace’a Foo находятся в папке src, а классы из App\Plugins надо искать в plugins/.

Соответственно классы будут искаться так:

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

или при установленном composer

Команда сгенерирует файлы автозагрузчика и положит их в папку vendor. После этого надо подключить автозагрузчик в свои файлы и наслаждаться программированием.

Таким образом, следование PSR-4 и использование composer позволяет не писать свой автозагрузчик.

Похожие записи

Отладка PHP в Visual Studio Code и OpenServer

Visual Studio Code — отличный бесплатный редактор кода, который в определенных ситуациях, заменяет IDE. В частности VS Code можно использовать как альтернативу PHPStorm. По умолчанию, VS Code предоставляет статический анализатор кода. В этом посте показана настройка отладчика PHP для Visual Studio Code в среде с набором инструментов разработчика OpenServer.