Схема composer.json

В этом разделе будут объяснены все поля, доступные в composer.json.

Схема JSON

У нас есть схема JSON, которая документирует формат и может быть использована для проверки вашего composer.json. На самом деле, она используется командой validate. Вы можете найти её по адресу: https://getcomposer.org/schema.json

Основной пакет

Основной пакет — это пакет, определённый в composer.json в корне вашего проекта. Это основной composer.json который определяет требования вашего проекта.

Некоторые поля применяются только в контексте основного пакета. Пример — поле config. Только основной пакет может определять конфигурацию. Конфигурация зависимостей игнорируется. Это делает поле config root-only.

Примечание: Пакет может быть основным или нет, в зависимости от контекста. Например, если ваш проект зависит от библиотеки monolog, ваш проект является основным пакетом. Однако, если вы клонируете monolog с GitHub для исправления ошибки, то monolog является основным пакетом.

Свойства

name

Имя пакета. Оно состоит из имени поставщика и имени проекта, разделенных /. Примеры:

monolog/monolog
igorw/event-source

Имя должно быть в нижнем регистре и состоять из слов, разделённых -, . или _. Полное имя должно соответствовать ^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]?|-{0,2})[a-z0-9]+)*$.

Свойство name требуется для опубликованных пакетов (библиотек).

Примечание: До версии Composer 2.0 имя могло содержать любые символы, включая пробелы.

описание

Краткое описание пакета. Обычно оно состоит из одной строки.

Требуется для опубликованных пакетов (библиотек).

версия

Версия пакета. В большинстве случаев это не требуется и следует опустить (см. ниже).

Она должна соответствовать формату X.Y.Z или vX.Y.Z с необязательным суффиксом -dev, -patch (-p), -alpha (-a), -beta (-b) или -RC. К суффиксам исправления, альфа, бета и RC также может быть добавлено число.

Примеры:

1.0.0
1.0.2
1.1.0
0.2.5
1.0.0-dev
1.0.0-alpha3
1.0.0-beta2
1.0.0-RC5
v2.0.4-p1

Необязательно, если репозиторий пакета может определить версию из такого источника, как имя тега VCS в репозитории VCS. В этом случае рекомендуется её опустить.

Примечание: Packagist использует репозитории VCS, поэтому вышесказанное полностью относится и к Packagist. Указание версии самостоятельно в большинстве случаев приведёт к проблемам из-за человеческой ошибки.

тип

Тип пакета. По умолчанию library.

Типы пакетов используются для пользовательской логики установки. Если у вас есть пакет, для которого требуется специальная логика, вы можете определить пользовательский тип. Это может быть symfony-bundle, wordpress-plugin или typo3-cms-extension. Эти типы будут специфичны для определённых проектов, и они должны предоставлять установщик, способный устанавливать пакеты этого типа.

По умолчанию Composer поддерживает четыре типа:

library: Это значение по умолчанию. Он скопирует файлы в vendor.
project: Это обозначает проект, а не библиотеку. Например, оболочки приложений, такие как Symfony standard edition, системы управления контентом, такие как SilverStripe installer, или полные приложения, распространяемые как пакеты. Это может, например, использоваться IDE для предоставления списков проектов для инициализации при создании новой рабочей области.
metapackage: Пустой пакет, содержащий требования и запускающий их установку, но не содержащий файлов и ничего не записывающий в файловую систему. Таким образом, для его установки не требуется ключ dist или source.
composer-plugin: Пакет типа composer-plugin может предоставить установщик для других пакетов, которые имеют пользовательский тип. Подробнее читайте в посвящённой статье.

Используйте пользовательский тип только в том случае, если вам нужна пользовательская логика во время установки. Рекомендуется опустить это поле и использовать значение по умолчанию library.

ключевые слова

Массив ключевых слов, относящихся к пакету. Они могут использоваться для поиска и фильтрации.

Примеры:

logging
events
database
redis
templating

Примечание: Некоторые специальные ключевые слова запускают composer require без опции --dev, чтобы запросить у пользователей, хотят ли они добавить эти пакеты в require-dev вместо require. К ним относятся dev, testing, static analysis.

Необязательно.

веб-сайт

URL веб-сайта проекта.

Необязательно.

readme

Относительный путь к документу readme.

Необязательно.

время

Дата выпуска версии.

Должно быть в формате YYYY-MM-DD или YYYY-MM-DD HH:MM:SS.

Необязательно.

лицензия

Лицензия пакета. Это может быть строка или массив строк.

Рекомендуемый формат для наиболее распространённых лицензий (в алфавитном порядке):

Apache-2.0
BSD-2-Clause
BSD-3-Clause
BSD-4-Clause
GPL-2.0-only / GPL-2.0-or-later
GPL-3.0-only / GPL-3.0-or-later
LGPL-2.1-only / LGPL-2.1-or-later
LGPL-3.0-only / LGPL-3.0-or-later
MIT

Необязательно, но настоятельно рекомендуется. Дополнительные идентификаторы перечислены в реестре открытых лицензий SPDX.

Примечание: Для закрытых программного обеспечения вы можете использовать "proprietary" в качестве идентификатора лицензии.

Пример:

{
    "license": "MIT"
}

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

Пример для разделительных лицензий:

{
    "license": [
        "LGPL-2.1-only",
        "GPL-3.0-or-later"
    ]
}

Или они могут быть разделены «или» и заключены в скобки;

{
    "license": "(LGPL-2.1-only or GPL-3.0-or-later)"
}

Аналогично, при необходимости применения нескольких лицензий («соединительная лицензия»), их следует разделять «и» и заключать в скобки.

авторы

Авторы пакета. Это массив объектов.

Каждый объект автора может иметь следующие свойства:

name: Имя автора. Обычно настоящее имя.
email: Электронный адрес автора.
homepage: URL веб-сайта автора.
role: Роль автора в проекте (например, разработчик или переводчик)

Пример:

{
    "authors": [
        {
            "name": "Nils Adermann",
            "email": "naderman@naderman.de",
            "homepage": "https://www.naderman.de",
            "role": "Developer"
        },
        {
            "name": "Jordi Boggiano",
            "email": "j.boggiano@seld.be",
            "homepage": "https://seld.be",
            "role": "Developer"
        }
    ]
}

Необязательно, но настоятельно рекомендуется.

поддержка

Различная информация для получения поддержки проекта.

Информация о поддержке включает следующее:

email: Электронный адрес для поддержки.
issues: URL трекера задач.
forum: URL форума.
wiki: URL вики.
irc: IRC-канал для поддержки, например, irc://server/channel.
source: URL для просмотра или скачивания исходного кода.
docs: URL документации.
rss: URL ленты RSS.
chat: URL канала чата.

Пример:

{
    "support": {
        "email": "support@example.org",
        "irc": "irc://irc.freenode.org/composer"
    }
}

Необязательно.

финансирование

Список URL-адресов, по которым авторы пакета могут получить финансирование для технического обслуживания и разработки новой функциональности.

Каждая запись состоит из следующего

type: Тип финансирования или платформа, через которую можно предоставить финансирование, например, patreon, opencollective, tidelift или github.
url: URL-адрес веб-сайта с подробностями и способом финансирования пакета.

Пример:

{
    "funding": [
        {
            "type": "patreon",
            "url": "https://www.patreon.com/phpdoctrine"
        },
        {
            "type": "tidelift",
            "url": "https://tidelift.com/subscription/pkg/packagist-doctrine_doctrine-bundle"
        },
        {
            "type": "other",
            "url": "https://www.doctrine-project.org/sponsorship.html"
        }
    ]
}

Необязательно.

Ссылки на пакеты

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

Пример:

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

Все ссылки — необязательные поля.

require и require-dev также поддерживают флаги стабильности (только для корневого пакета). Они принимают форму "ограничение@флаг стабильности". Это позволяет вам дополнительно ограничивать или расширять стабильность пакета, выходя за рамки параметра минимальной стабильности. Вы можете применить их к ограничению или применить их к пустому ограничению, если, например, вы хотите разрешить нестабильные пакеты зависимости.

Пример:

{
    "require": {
        "monolog/monolog": "1.0.*@beta",
        "acme/foo": "@dev"
    }
}

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

Пример:

Предполагая, что doctrine/doctrine-fixtures-bundle требует "doctrine/data-fixtures": "dev-master", то в корневом composer.json вам необходимо добавить вторую строку ниже, чтобы разрешить выпуск dev для пакета doctrine/data-fixtures:

{
    "require": {
        "doctrine/doctrine-fixtures-bundle": "dev-master",
        "doctrine/data-fixtures": "@dev"
    }
}

require и require-dev дополнительно поддерживают явные ссылки (например, коммит) для версий dev, чтобы убедиться, что они заблокированы на определённом состоянии, даже при запуске обновления. Они работают только если вы явно требуете версию dev и добавляете ссылку с помощью #<ref>. Эта функция также является только для корневого пакета и будет игнорироваться в зависимостях.

Пример:

{
    "require": {
        "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7",
        "acme/foo": "1.0.x-dev#abc123"
    }
}

Примечание: Эта функция имеет серьёзные технические ограничения, так как метаданные composer.json всё ещё будут читаться из имени ветки, указанного вами до хэша. Поэтому вы должны использовать её только как временное решение во время разработки для устранения временных проблем, пока не перейдёте к помеченным выпускам. Команда Composer не поддерживает эту функцию и не будет принимать отчёты об ошибках, связанные с ней.

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

require и require-dev также поддерживают ссылки на конкретные версии PHP и расширения PHP, необходимые для успешной работы вашего проекта.

Пример:

{
    "require": {
        "php": ">=7.4",
        "ext-mbstring": "*"
    }
}

Примечание: Важно перечислить PHP-расширения, необходимые для вашего проекта. Не все установки PHP одинаковы: некоторые могут отсутствовать расширения, которые вы считаете стандартными (например, ext-mysqli , который не установлен по умолчанию в системах Fedora/CentOS с минимальной установкой). Отсутствие перечисления необходимых PHP-расширений может привести к плохому пользовательскому опыту: Composer установит ваш пакет без ошибок, но затем произойдёт сбой во время выполнения. Команда composer show --platform перечисляет все доступные на вашей системе PHP-расширения. Вы можете использовать её для составления списка используемых и необходимых расширений. В качестве альтернативы вы можете использовать сторонние инструменты для анализа вашего проекта и определения списка используемых расширений.

require

Карта пакетов, необходимых для этого пакета. Пакет не будет установлен, если эти требования не могут быть выполнены.

require-dev (только для корневого пакета)

Карта пакетов, необходимых для разработки этого пакета или для выполнения тестов и т. д. Требования к разработке корневого пакета устанавливаются по умолчанию. Как install, так и update поддерживают опцию --no-dev, которая предотвращает установку зависимостей разработки.

conflict

Карта пакетов, которые конфликтуют с этой версией этого пакета. Они не будут установлены вместе с вашим пакетом.

Обратите внимание, что при указании диапазонов, таких как <1.0 >=1.1 в conflict ссылке, это указывает на конфликт со всеми версиями, которые меньше 1.0 и равны или новее 1.1 одновременно, что, вероятно, не то, что вам нужно. В этом случае, вероятно, лучше использовать <1.0 || >=1.1.

replace

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

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

При использовании replace для подпакетов, описанных выше, следует проявлять осторожность. Обычно вы должны использовать self.version в качестве ограничения версии, чтобы убедиться, что основной пакет заменяет только подпакеты этой конкретной версии, а не любой другой версии, что было бы неправильно.

provide

Карта пакетов, которые предоставляются этим пакетом. Это в основном полезно для реализации общих интерфейсов. Пакет может зависеть от некоторого виртуального пакета, например, psr/logger-implementation, любой библиотека, реализующая этот интерфейс логгера, должна перечислить его в provide. Исполнители могут быть найдены на Packagist.org.

Использование provide с именем фактического пакета, а не виртуального, подразумевает, что код этого пакета также поставляется, в этом случае replace обычно является лучшим выбором. Общая практика для пакетов, предоставляющих интерфейс и полагающихся на другие пакеты для реализации (например, PSR-интерфейсы), заключается в использовании суффикса -implementation для имени виртуального пакета, соответствующего пакету интерфейса.

suggest

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

Формат аналогичен ссылкам на пакеты выше, за исключением того, что значения являются текстом, а не ограничениями версий.

Пример:

{
    "suggest": {
        "monolog/monolog": "Allows more advanced logging of the application flow",
        "ext-xml": "Needed to support XML format in class Foo"
    }
}

autoload

Карта автозагрузки для автозагрузчика PHP.

PSR-4 и PSR-0 автозагрузки, classmap генерация и files включения поддерживаются.

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

PSR-4

В ключе psr-4 вы определяете соответствие между именами пространств имён и путями, относительно корня пакета. При автозагрузке класса, например, Foo\\Bar\\Baz, префикс пространства имён Foo\\, указывающий на директорию src/, означает, что автозагрузчик будет искать файл с именем src/Bar/Baz.php и включать его, если он присутствует. Обратите внимание, что в отличие от старого стиля PSR-0, префикс (Foo\\) не присутствует в пути к файлу.

Префиксы пространств имён должны оканчиваться на \\, чтобы избежать конфликтов между похожими префиксами. Например, Foo будет соответствовать классам в пространстве имён FooBar, поэтому обратные слэши решают проблему: Foo\\ и FooBar\\ различны.

Все ссылки PSR-4 объединяются во время установки/обновления в один массив ключ => значение, который можно найти в сгенерированном файле vendor/composer/autoload_psr4.php.

Пример:

{
    "autoload": {
        "psr-4": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": ""
        }
    }
}

Если вам нужно искать один и тот же префикс в нескольких директориях, вы можете указать их как массив:

{
    "autoload": {
        "psr-4": { "Monolog\\": ["src/", "lib/"] }
    }
}

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

{
    "autoload": {
        "psr-4": { "": "src/" }
    }
}

PSR-0

В ключе psr-0 вы определяете соответствие между именами пространств имён и путями, относительно корня пакета. Обратите внимание, что это также поддерживает соглашение PEAR-стиля без пространств имён.

Обратите внимание, что объявления пространств имён должны оканчиваться на \\, чтобы убедиться, что автозагрузчик реагирует точно. Например, Foo будет соответствовать в FooBar, поэтому обратные слэши решают проблему: Foo\\ и FooBar\\ различны.

Все ссылки PSR-0 объединяются во время установки/обновления в один массив ключ => значение, который можно найти в сгенерированном файле vendor/composer/autoload_namespaces.php.

Пример:

{
    "autoload": {
        "psr-0": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": "src/",
            "Vendor_Namespace_": "src/"
        }
    }
}

Если вам нужно искать один и тот же префикс в нескольких директориях, вы можете указать их как массив:

{
    "autoload": {
        "psr-0": { "Monolog\\": ["src/", "lib/"] }
    }
}

Стиль PSR-0 не ограничивается только объявлениями пространств имён, но может быть задан даже на уровне класса. Это может быть полезно для библиотек, содержащих только один класс в глобальном пространстве имён. Если php исходный файл также расположен в корне пакета, например, он может быть объявлен так:

{
    "autoload": {
        "psr-0": { "UniqueGlobalClass": "" }
    }
}

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

{
    "autoload": {
        "psr-0": { "": "src/" }
    }
}

Classmap

Все ссылки classmap объединяются во время установки/обновления в один массив ключ => значение, который можно найти в сгенерированном файле vendor/composer/autoload_classmap.php. Эта карта создаётся путём сканирования классов во всех файлах .php и .inc в заданных директориях/файлах.

Вы можете использовать поддержку генерации classmap для определения автозагрузки для всех библиотек, которые не следуют PSR-0/4. Для настройки этого вы указываете все директории или файлы для поиска классов.

Пример:

{
    "autoload": {
        "classmap": ["src/", "lib/", "Something.php"]
    }
}

Поддерживаются шаблоны (*) в путях classmap, и они расширяются для соответствия любому имени директории:

Пример:

{
    "autoload": {
        "classmap": ["src/addons/*/lib/", "3rd-party/*", "Something.php"]
    }
}

Файлы

Если вы хотите явно потребовать определённые файлы при каждом запросе, вы можете использовать механизм автозагрузки files. Это полезно, если ваш пакет содержит PHP-функции, которые не могут быть загружены автоматически PHP.

Пример:

{
    "autoload": {
        "files": ["src/MyLibrary/functions.php"]
    }
}

Правила автозагрузки файлов включаются всякий раз, когда включён vendor/autoload.php, сразу после регистрации автозагрузчика. Порядок включения зависит от зависимостей пакетов, так что если пакет A зависит от B, файлы в пакете B будут включены первыми, чтобы убедиться, что пакет B полностью инициализирован и готов к использованию, когда будут включены файлы из пакета A.

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

Файлы из корневого пакета всегда загружаются последними, и вы не можете использовать автозагрузку файлов самостоятельно, чтобы переопределить функции из ваших зависимостей. Если вам нужно это сделать, мы рекомендуем включить свои функции до включения Composer's vendor/autoload.php.

Исключение файлов из classmap

Если вы хотите исключить некоторые файлы или папки из classmap, вы можете использовать свойство exclude-from-classmap. Это может быть полезно, чтобы исключить тестовые классы в рабочей среде, например, так как они будут пропущены из classmap даже при создании оптимизированного автозагрузчика.

Генератор classmap проигнорирует все файлы в указанных путях. Пути являются абсолютными от корня пакета (т.е. местоположения composer.json) и поддерживают * для сопоставления всего, кроме слэша, и ** для сопоставления всего. ** неявно добавляется в конец путей.

Пример:

{
    "autoload": {
        "exclude-from-classmap": ["/Tests/", "/test/", "/tests/"]
    }
}

Оптимизация автозагрузчика

Автозагрузчик может существенно повлиять на время ответа вашего запроса (от 50 до 100 мс на запрос в крупных фреймворках, использующих множество классов). Подробнее о том, как уменьшить это влияние, см. в статье об оптимизации автозагрузчика.

autoload-dev (только для корневого пакета)

Этот раздел позволяет определять правила автозагрузки для целей разработки.

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

Поэтому целесообразно использовать отдельную директорию для ваших юнит-тестов и добавить её в раздел autoload-dev.

Пример:

{
    "autoload": {
        "psr-4": { "MyLibrary\\": "src/" }
    },
    "autoload-dev": {
        "psr-4": { "MyLibrary\\Tests\\": "tests/" }
    }
}

include-path

УСТАРЕВШЕЕ: Этот раздел присутствует только для поддержки старых проектов, и весь новый код предпочтительно должен использовать автозагрузку. Как таковой, это устаревшая практика, но сама функция, вероятно, не исчезнет из Composer.

Список путей, которые должны быть добавлены к include_path PHP.

Пример:

{
    "include-path": ["lib/"]
}

Необязательно.

target-dir

УСТАРЕВШЕЕ: Этот раздел присутствует только для поддержки устаревшего стиля автозагрузки PSR-0, и весь новый код предпочтительно должен использовать PSR-4 без target-dir. Проектам, использующим PSR-0 с именованными пространствами имён PHP, рекомендуется перейти на PSR-4.

Определяет целевой каталог для установки.

В случае, если корень пакета находится ниже объявления пространства имён, правильная автозагрузка невозможна. target-dir решает эту проблему.

Пример Symfony. Есть отдельные пакеты для компонентов. Компонент Yaml находится в Symfony\Component\Yaml. Корень пакета находится в директории Yaml. Для возможности автозагрузки необходимо убедиться, что он не установлен в vendor/symfony/yaml, а в vendor/symfony/yaml/Symfony/Component/Yaml, чтобы автозагрузчик мог загрузить его из vendor/symfony/yaml.

Для этого autoload и target-dir определяются следующим образом:

{
    "autoload": {
        "psr-0": { "Symfony\\Component\\Yaml\\": "" }
    },
    "target-dir": "Symfony/Component/Yaml"
}

Необязательно.

minimum-stability (только корневой пакет)

Это определяет поведение по умолчанию для фильтрации пакетов по стабильности. По умолчанию это stable, поэтому если вы полагаетесь на пакет dev, вы должны указать его в своём файле, чтобы избежать неожиданностей.

Все версии каждого пакета проверяются на стабильность, и те, которые менее стабильны, чем значение minimum-stability, будут игнорироваться при разрешении зависимостей вашего проекта. (Обратите внимание, что вы также можете указать требования к стабильности для каждого пакета, используя флаги стабильности в ограничениях версий, которые вы указываете в блоке require (подробнее см. ссылки на пакеты).

Доступные варианты (в порядке стабильности) — dev, alpha, beta, RC, и stable.

prefer-stable (только корневой пакет)

При включении этого параметра Composer будет отдавать предпочтение более стабильным пакетам перед менее стабильными, когда возможно найти совместимые стабильные пакеты. Если вам нужна версия dev или доступны только альфа-версии пакета, они всё равно будут выбраны, если это разрешено параметром minimum-stability.

Для включения используйте "prefer-stable": true.

repositories (только корневой пакет)

Пользовательские репозитории пакетов для использования.

По умолчанию Composer использует только репозиторий packagist. Указывая репозитории, вы можете получать пакеты из других источников.

Репозитории не разрешаются рекурсивно. Вы можете добавлять их только в ваш основной composer.json. Объявления репозиториев зависимостей composer.json игнорируются.

Поддерживаются следующие типы репозиториев:

composer: Репозиторий Composer — это packages.json файл, предоставляемый по сети (HTTP, FTP, SSH), который содержит список composer.json объектов с дополнительной dist и/или source информацией. Файл packages.json загружается с помощью PHP потока. Вы можете установить дополнительные параметры для этого потока, используя параметр options.
vcs: Репозиторий системы контроля версий может извлекать пакеты из репозиториев git, svn, fossil и hg.
package: Если вы зависите от проекта, который вообще не поддерживает Composer, вы можете определить пакет встроенно, используя репозиторий package. Вы по сути встраиваете объект composer.json.

Дополнительную информацию об этих репозиториях см. в Репозитории.

Пример:

{
    "repositories": [
        {
            "type": "composer",
            "url": "http://packages.example.com"
        },
        {
            "type": "composer",
            "url": "https://packages.example.com",
            "options": {
                "ssl": {
                    "verify_peer": "true"
                }
            }
        },
        {
            "type": "vcs",
            "url": "https://github.com/Seldaek/monolog"
        },
        {
            "type": "package",
            "package": {
                "name": "smarty/smarty",
                "version": "3.1.7",
                "dist": {
                    "url": "https://www.smarty.net/files/Smarty-3.1.7.zip",
                    "type": "zip"
                },
                "source": {
                    "url": "https://smarty-php.googlecode.com/svn/",
                    "type": "svn",
                    "reference": "tags/Smarty_3_1_7/distribution/"
                }
            }
        }
    ]
}

Примечание: Порядок здесь имеет значение. При поиске пакета Composer будет искать от первого до последнего репозитория и выбирать первую найденную совпадающую запись. По умолчанию Packagist добавляется последним, что означает, что пользовательские репозитории могут переопределять пакеты из него.

Также возможно использование JSON-формата. Однако пары ключ/значение JSON не упорядочены, поэтому гарантии согласованного поведения нет.

{
    "repositories": {
        "foo": {
            "type": "composer",
            "url": "http://packages.foo.com"
        }
    }
}

config (только корневой пакет)

Набор параметров конфигурации. Он используется только для проектов. Подробное описание каждого отдельного параметра см. в Конфигурация.

scripts (только корневой пакет)

Composer позволяет вам подключаться к различным частям процесса установки с помощью скриптов.

Подробную информацию о событиях и примерах см. в Скрипты.

extra

Произвольные дополнительные данные для использования scripts.

Это может быть практически всё. Чтобы получить доступ к нему из обработчика событий скрипта, вы можете сделать следующее:

$extra = $event->getComposer()->getPackage()->getExtra();

Необязательно.

bin

Набор файлов, которые должны обрабатываться как двоичные файлы и предоставляться в bin-dir (из конфигурации).

Дополнительную информацию см. в Двоичные файлы вендора.

Необязательно.

abandoned

Указывает, является ли этот пакет заброшенным.

Это может быть булевым значением или именем/URL пакета, указывающим рекомендуемую альтернативу.

Примеры:

Используйте "abandoned": true для обозначения того, что этот пакет заброшен. Используйте "abandoned": "monolog/monolog" для обозначения того, что этот пакет заброшен, и что рекомендуемая альтернатива — monolog/monolog.

По умолчанию false.

Необязательно.

non-feature-branches

Список регулярных выражений имён ветвей, которые не являются числовыми (например, «latest» или что-то подобное), которые не будут обрабатываться как ветви функций. Это массив строк.

Если у вас есть имена ветвей, которые не являются числовыми, например, «latest», «current», «latest-stable» или что-то подобное, которые не похожи на номер версии, Composer обрабатывает такие ветви как ветви функций. Это означает, что он ищет родительские ветви, которые выглядят как версия или заканчиваются на специальных ветвях (например, master), и номер версии корневого пакета становится номером версии родительской ветви или, по крайней мере, master или что-то подобное.

Чтобы обращаться с именами ветвей, которые не являются числовыми, как с версиями вместо поиска родительской ветви с допустимой версией или специальным именем ветви, таким как master, вы можете установить шаблоны для имён ветвей, которые должны обрабатываться как ветви dev-версий.

Это очень полезно, когда у вас есть зависимости, использующие «self.version», чтобы установить не dev-master, а ту же ветку (в примере: latest-testing).

Пример:

Если у вас есть ветка testing, которая активно поддерживается во время этапа тестирования и развертывается в вашей тестовой среде, обычно composer show -s даст вам versions : * dev-master.

Если вы настраиваете latest-.* в качестве шаблона для non-feature-branches следующим образом:

{
    "non-feature-branches": ["latest-.*"]
}

Тогда composer show -s даст вам versions : * dev-latest-testing.

Необязательно.

← Интерфейс командной строки | Репозитории →

Схема composer.json

Схема JSON

Основной пакет

Свойства

name

описание

версия

тип

ключевые слова

веб-сайт

readme

время

лицензия

авторы

поддержка

финансирование

Ссылки на пакеты

require

require-dev (только для корневого пакета)

conflict

replace

provide

suggest

autoload

PSR-4

PSR-0

Classmap

Файлы

Исключение файлов из classmap

Оптимизация автозагрузчика

autoload-dev (только для корневого пакета)

include-path

target-dir

minimum-stability (только корневой пакет)

prefer-stable (только корневой пакет)

repositories (только корневой пакет)

config (только корневой пакет)

scripts (только корневой пакет)

extra

bin

archive

abandoned

non-feature-branches