В этой главе будут объяснены все поля, доступные в JSON схема #У нас есть схема JSON, которая документирует формат и может также использоваться для тестирования вашего Корневой пакет #Корневой пакет - это пакет, определенный Некоторые поля применяются только в контексте корневого пакета. Одним из примеров этого является поле Заметка. Пакет может быть корневым пакетом или нет, в зависимости от контекста. Например, если ваш проект зависит от библиотеки Свойства #name #Имя пакета. Он состоит из имени поставщика и названия проекта, разделенных символом
Имя может содержать любой символ, включая пробелы, и его регистр нечувствителен ( Требуется для опубликованных пакетов (библиотек). description #Краткое описание пакета. Обычно это только одна строка. Требуется для опубликованных пакетов (библиотек). version #Версия пакета. В большинстве случаев это не требуется и должно быть опущено (см. Ниже). Это должно соответствовать формату Примеры:
Опционально, если репозиторий пакетов может выводить версию откуда-нибудь, например, имя тега VCS в репозитории VCS. В этом случае также рекомендуется опустить его. Заметка. Packagist использует хранилище VCS, поэтому приведенное выше заявление очень важно для Packagist. Определение самой версии, скорее всего, в конечном итоге создаст проблемы из-за человеческой ошибки. type #Тип упаковки. Типы пакетов используются для настраиваемой логики установки. Если у вас есть пакет, который нуждается в некоторой специальной логике, вы можете определить пользовательский тип. Это может быть набор В стандартной конфигурации Composer поддерживает четыре типа:
Используйте только настраиваемый тип, если вам нужна пользовательская логика во время установки. Рекомендуется опустить это поле и оставить его в библиотеке по умолчанию. keywords #Массив ключевых слов, с которым связан пакет. Они могут использоваться для поиска и фильтрации. Примеры:
Необязательный. homepage #URL-адрес веб-сайта проекта. Необязательный. time #Дата выпуска версии. Должно быть в формате Необязательный. license #Лицензия на пакет. Это может быть строка или массив строк. Рекомендуемая нотация для наиболее распространенных лицензий (в алфавитном порядке):
Необязательно, но мы настоятельно рекомендуем это сделать. Дополнительные идентификаторы перечислены в реестре лицензий SPDX с открытым исходным кодом. Для программного обеспечения с закрытым исходным кодом вы можете использовать Пример:
{
"license": "MIT"
}
Для пакета, когда есть выбор между лицензиями («дизъюнктивная лицензия»), несколько могут быть указаны как массив. Пример дизъюнктивных лицензий:
{
"license": [
"LGPL-2.1",
"GPL-3.0+"
]
}
В качестве альтернативы они могут быть разделены символом «или» и заключены в круглые скобки:
{
"license": "(LGPL-2.1 or GPL-3.0+)"
}
Аналогичным образом, когда необходимо применить несколько лицензий («конъюнктивная лицензия»), они должны быть отделены «и» и заключены в круглые скобки. authors #Авторы пакета. Это массив объектов. Каждый объект-автор может иметь следующие свойства:
Пример:
{
"authors": [
{
"name": "Nils Adermann",
"email": "naderman@naderman.de",
"homepage": "http://www.naderman.de",
"role": "Developer"
},
{
"name": "Jordi Boggiano",
"email": "j.boggiano@seld.be",
"homepage": "http://seld.be",
"role": "Developer"
}
]
}
Необязательно, но рекомендуется. support #Различная информация для получения поддержки по проекту. Информация о поддержке включает следующее:
Пример:
{
"support": {
"email": "support@example.org",
"irc": "irc://irc.freenode.org/composer"
}
}
Необязательный. Ссылки на пакеты #Все последующие объекты берут объект, который сопоставляет имена пакетов с версиями пакета через ограничения версии. Подробнее о версиях читайте здесь. Пример:
{
"require": {
"monolog/monolog": "1.0.*"
}
}
Все ссылки являются необязательными.
Пример:
{
"require": {
"monolog/monolog": "1.0.*@beta",
"acme/foo": "@dev"
}
}
Если одна из ваших зависимостей зависит от неустойчивого пакета, вам также нужно явно указать его, наряду с его достаточным флагом стабильности. Пример:
{
"require": {
"doctrine/doctrine-fixtures-bundle": "dev-master",
"doctrine/data-fixtures": "@dev"
}
}
Пример:
{
"require": {
"monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7",
"acme/foo": "1.0.x-dev#abc123"
}
}
Примечание. Эта функция имеет серьезные технические ограничения, так как метаданные
Также возможно inline-alias ограничение пакета так, чтобы оно соответствовало ограничению, которое иначе не было бы. Для получения дополнительной информации см. Статью о псевдонимах.
Пример:
{
"require" : {
"php" : "^5.5 || ^7.0",
"ext-mbstring": "*"
}
}
Примечание. Важно указать список расширений PHP, необходимых вашему проекту. Не все установки PHP созданы равными: некоторые могут пропускать расширения, которые вы можете считать стандартными (например, require #Выводит список пакетов, необходимых для этого пакета. Пакет не будет установлен, если эти требования не будут выполнены. require-dev (только для root) #Выводит список пакетов, необходимых для разработки этого пакета, или выполнения тестов и т. Д. Требования к установке корневого пакета устанавливаются по умолчанию. Как conflict #Перечисляет пакеты, конфликтующие с этой версией этого пакета. Они не будут установлены вместе с вашим пакетом. Обратите внимание, что при определении диапазонов, таких как replace #Выводит список пакетов, которые заменяются этим пакетом. Это позволяет разветвить пакет, опубликовать его под другим именем с собственными номерами версий, в то время как пакеты, требующие исходного пакета, продолжают работать с вашим fork, так как он заменяет исходный пакет. Это также полезно для пакетов, содержащих подпакеты, например, основной пакет symfony / symfony содержит все компоненты Symfony, которые также доступны в виде отдельных пакетов. Если вам нужен основной пакет, он автоматически выполнит любое требование одного из отдельных компонентов, так как он заменит их. При использовании замены для цели подпакета, описанной выше, рекомендуется соблюдать осторожность. В таком случае вы обычно должны заменять только provide #Список других пакетов, предоставляемых этим пакетом. Это в основном полезно для общих интерфейсов. Пакет может зависеть от некоторого виртуального пакета 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-4 #Под ключ Префиксы пространства имен должны заканчиваться на Ссылки PSR-4 объединяются во время установки / обновления в один массив key => value, который можно найти в созданном файле Пример:
{
"autoload": {
"psr-4": {
"Monolog\\": "src/",
"Vendor\\Namespace\\": ""
}
}
}
Если вам нужно найти один и тот же префикс в нескольких каталогах, вы можете указать их в виде массива как такового:
{
"autoload": {
"psr-4": { "Monolog\\": ["src/", "lib/"] }
}
}
Если вы хотите иметь резервный каталог, в котором будет искать любое пространство имен, вы можете использовать пустой префикс, например:
{
"autoload": {
"psr-4": { "": "src/" }
}
}
PSR-0 #Под клавишей Обратите внимание: декларации пространств имен должны заканчиваться на Ссылки PSR-0 объединяются во время установки / обновления в один массив key => value, который можно найти в созданном файле Пример:
{
"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, чтобы определить автозагрузку для всех библиотек, которые не следуют PSR-0/4. Чтобы настроить это, вы указываете все каталоги или файлы для поиска классов. Пример:
{
"autoload": {
"classmap": ["src/", "lib/", "Something.php"]
}
}
Файлы #Если вы хотите явно запрашивать определенные файлы для каждого запроса, вы можете использовать механизм автозагрузки файлов. Это полезно, если ваш пакет включает функции PHP, которые не могут быть загружены автоматически. Пример:
{
"autoload": {
"files": ["src/MyLibrary/functions.php"]
}
}
Исключить файлы из classmaps #Если вы хотите исключить некоторые файлы или папки из карты классов, вы можете использовать свойство «exclude-from-classmap». Это может быть полезно, например, чтобы исключить тестовые классы в вашей рабочей среде, поскольку они будут пропущены с карты классов даже при создании оптимизированного автозагрузчика. Генератор classmap игнорирует все файлы в указанных здесь путях. Пути абсолютны из корневого каталога пакета (то есть местоположения Пример:
{
"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": ["lib/"]
}
Необязательный. target-dir #УСТАРЕЛО: это присутствует только для поддержки автозагрузки старого стиля PSR-0, и весь новый код должен предпочтительно использовать PSR-4 без target-dir, а проекты с использованием PSR-0 с пространствами имен PHP рекомендуется переносить на PSR-4. Определяет цель установки. В случае, если корневой каталог пакета находится ниже декларации пространства имен, вы не можете правильно загрузиться. Примером может служить Symfony. Для компонентов имеются отдельные пакеты. Компонент Yaml находится в разделе Чтобы сделать это,
{
"autoload": {
"psr-0": { "Symfony\\Component\\Yaml\\": "" }
},
"target-dir": "Symfony/Component/Yaml"
}
Необязательный. minimum-stability (только для root) #Это определяет поведение по умолчанию для фильтрации пакетов по стабильности. По умолчанию это Все версии каждого пакета проверены на стабильность, а те, которые менее стабильны, чем параметр Доступные опции (в порядке стабильности): prefer-stable (только для root) #Когда это включено, Composer предпочтет более устойчивые пакеты над неустойчивыми, когда возможно найти совместимые стабильные пакеты. Если вам нужна версия dev или только альфа-версии для пакета, они все равно будут выбраны с учетом минимальной стабильности. Используйте repositories (только для root) #Пользовательские репозитории пакетов. По умолчанию Composer просто использует репозиторий packagist. Указав репозитории, вы можете получить пакеты из других мест. Репозитории рекурсивно не реплицируются. Вы можете добавить их только в ваш основной Поддерживаются следующие типы репозитория:
Для получения дополнительной информации по любому из них см. Репозитории. Пример:
{
"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": "pear",
"url": "https://pear2.php.net"
},
{
"type": "package",
"package": {
"name": "smarty/smarty",
"version": "3.1.7",
"dist": {
"url": "http://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 #Произвольные дополнительные данные для потребления Это может быть практически что угодно. Чтобы получить доступ к нему из обработчика событий скрипта, вы можете сделать следующее: $extra = $event->getComposer()->getPackage()->getExtra(); Необязательный. bin #Набор файлов, которые следует рассматривать как двоичные файлы и символические ссылки в Дополнительные сведения см. в статье "Двоичные файлы поставщика и каталог vendor/bin". Необязательный. archive #Набор параметров для создания архивов пакетов. Поддерживаются следующие параметры:
Пример:
{
"archive": {
"exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"]
}
}
Пример будет включать Необязательный. non-feature-branches #Список шаблонов регулярных выражений имен ветвей, которые не являются числовыми (например, «последние» или что-то еще), которые НЕ будут обрабатываться как ветви признака. Это массив строк. Если у вас есть нечисловые имена ветвей, например «последняя», «текущая», «самая стабильная» или что-то в этом роде, это не похоже на номер версии, тогда Composer обрабатывает такие ветви как ветви функций. Это означает, что он ищет родительские ветви, которые выглядят как версии или заканчиваются в специальных ветвях (таких как master), а номер версии корневого пакета становится версией родительской ветви или по крайней мере мастером или чем-то еще. Чтобы обрабатывать нечисловые именованные ветви в качестве версий вместо поиска родительской ветви с допустимой версией или специальным именем ветви, например, главной, вы можете установить шаблоны для имен ветвей, которые должны обрабатываться как ветви версии для версии. Это действительно полезно, когда у вас есть зависимости, используя «self.version», так что не dev-master, но такая же ветка установлена (в примере: последнее тестирование). Пример: Если у вас есть ветка тестирования, которая сильно поддерживается на этапе тестирования и развертывается в вашей промежуточной среде, обычно «composer show -s» предоставляет вам Если вы настроите
{
"non-feature-branches": ["latest-.*"]
}
Затем «composer show -s» предоставит вам Необязательный. |