composer.json schema

Информация о материале: Родительская категория: Программы для автоматизации работы; Категория: Composer

Схема composer.json — composer.json схема

В этой главе описываются все поля, доступные в composer.json.

JSON-схема

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

Корневой пакет (root-пакет)

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

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

Примечание: Пакет может быть корневым или нет, в зависимости от контекста. Например, если ваш проект зависит от библиотеки 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 имя могло содержать любые символы, включая пробелы.

`description`

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

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

`version`

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

Версия должна иметь формат X.Y.Z или vX.Y.Z с дополнительным суффиксом -dev, -patch (-p), -alpha (-a), -beta (-b) или -RC. За суффиксами patch, alpha, beta и 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. Указание версии самостоятельно, скорее всего, приведет к тому, что в какой-то момент возникнут проблемы из-за человеческого фактора.

`type`

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

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

Из коробки Composer поддерживает четыре типа:

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

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

`keywords`

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

Примеры:

logging
events
database
redis
templating

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

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

`homepage`

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

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

`readme`

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

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

`time`

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

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

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

`license`

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

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

Apache-2.0
BSD-2-Clause
BSD-3-Clause
BSD-4-Clause
GPL-2.0-only / GPL-2.0-or-later
GPL-3.0- только / GPL-3. 0-or- later
LGPL-2.1 только / LGPL-2.1-or-later
LGPL-3.0-only / LGPL-3.0-or-later
MIT

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

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

Пример:

{
    "license": "MIT"
}

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

Пример дизъюнктивных лицензий:

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

В качестве альтернативы их можно разделить с помощью or и заключить в круглые скобки:

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

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

`authors`

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

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

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

Пример:

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

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

`support`

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

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

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

Пример:

{
    "support": {
        "email": "[email protected]",
        "irc": "irc://irc.freenode.org/composer"
    }
}

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

`funding`

Список 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 дополнительно поддерживают флаги стабильности (только для root). Они имеют форму "constraint@флаг стабильности". Они позволяют дополнительно ограничить или расширить стабильность пакета, выходя за рамки настройки minimum-stability. Вы можете применить их к ограничению или применить их к бессодержательному ограничению, если вы хотите, например, разрешить нестабильные пакеты зависимостей.

Пример:

{
    "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 дополнительно поддерживают явные ссылки (т.е. commit) для dev-версий, чтобы убедиться, что они фиксируются в заданном состоянии, даже когда вы запускаете обновление. Они работают, только если вы явно требуете dev-версию и добавляете к ссылке #<ref>. Это также функция только для root и будет игнорироваться в зависимостях.

Пример:

{
    "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` (только для root)

Карта пакетов, необходимых для разработки этого пакета, запуска тестов и т.д. По умолчанию устанавливаются dev-зависимости корневого пакета. И install, и update поддерживают опцию --no-dev, которая предотвращает установку 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": "Позволяет вести более расширенное протоколирование потока приложений",
        "ext-xml": "Необходим для поддержки формата XML в 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`

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

Пример:

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

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

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

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

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

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

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

Пример:

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

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

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

`autoload-dev` (только для root)

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

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

Поэтому хорошей идеей будет использовать выделенный путь для ваших модульных тестов и добавить его в раздел 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` (только для root)

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

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

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

`prefer-stable` (только для root)

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

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

`repositories` (только для root)

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

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

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

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

composer
- Репозиторий Composer — это файл packages.json, обслуживаемый по сети (HTTP, FTP, SSH), который содержит список объектов composer.json с дополнительной информацией о dist и/или source. Файл packages.json загружается с помощью PHP stream. Вы можете установить дополнительные опции для этого потока с помощью параметра 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` (только для root)

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

`scripts` (только для root)

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

Подробности и примеры сценариев см. в разделе Сценарии.

`extra`

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

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

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

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

`bin`

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

Дополнительные сведения см. в разделе Бинарные файлы поставщика.

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

`archive`

Набор параметров для создания архивов пакетов.

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

name
- Позволяет настроить базовое имя архива. По умолчанию (если не настроено, и --file не передан в качестве аргумента командной строки) используется preg_replace('#[^a-z0-9-_]#i', '-', name).

Пример:

{
    "name": "org/strangeName",
    "archive": {
        "name": "Strange_name"
    }
}

exclude
- Позволяет настроить список шаблонов для исключаемых путей. Синтаксис шаблона соответствует файлам .gitignore.
  - Восклицательный знак (!) приведет к тому, что все совпадающие файлы будут включены, даже если предыдущий шаблон их исключил.
  - Слэш (/) будет соответствовать только началу относительного пути к проекту.
  - Звездочка (*) не будет расширяться до разделителя каталогов.

Пример:

{
    "archive": {
        "exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"]
    }
}

Пример будет включать /dir/foo/bar/file, /foo/bar/baz, /file.php, /foo/my.test, но будет исключать /foo/bar/any, /foo/baz и /my.test.

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

`abandoned`

Указывает, был ли этот пакет не используется.

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

Примеры:

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

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

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

`non-feature-branches`

Список regex-паттернов имен ветвей, которые не являются числовыми (например, latest или что-то в этом роде), и которые НЕ будут обрабатываться как ветви функций. Это массив строк.

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

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

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

Пример:

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

Если вы настроите latest-.* как шаблон для нефункциональных ветвей, например:

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

Затем composer show -s выдаст вам versions : * dev-latest-testing.

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

Перевод с английского официальной документации Composer:
https://getcomposer.org/doc/04-schema.md

Заберите ссылку на статью к себе, чтобы потом легко её найти!
Раз уж досюда дочитали, то может может есть желание рассказать об этом месте своим друзьям, знакомым и просто мимо проходящим?
Не надо себя сдерживать! ;)

JSON-схема

Корневой пакет (root-пакет)

Свойства

name

description

version

type

keywords

homepage

readme

time

license

authors

support

funding

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

require

require-dev (только для root)

conflict

replace

provide

suggest

autoload

PSR-4

PSR-0

Classmap

Files

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

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

autoload-dev (только для root)

include-path

target-dir

minimum-stability (только для root)

prefer-stable (только для root)

repositories (только для root)

config (только для root)

scripts (только для root)

extra

bin

archive

abandoned

non-feature-branches

Горячий старт на просторы интернета

Горячий старт на просторы интернета

`name`

`description`

`version`

`type`

`keywords`

`homepage`

`readme`

`time`

`license`

`authors`

`support`

`funding`

`require`

`require-dev` (только для root)

`conflict`

`replace`

`provide`

`autoload`

`PSR-4`

`PSR-0`

`Classmap`

`Files`

`autoload-dev` (только для root)

`include-path`

`target-dir`

`minimum-stability` (только для root)

`prefer-stable` (только для root)

`repositories` (только для root)

`config` (только для root)

`scripts` (только для root)

`extra`

`bin`

`archive`

`abandoned`

`non-feature-branches`