Конфигурации Composer и его сообщество

Вступление

Технология регулируется физическими законами, которые состоят из протоколов и конфигураций. В предыдущем уроке мы подробно обсудили концепции репозитория composer и то, как они работают, в этом уроке мы подробно рассмотрим важный раздел файла composer.json, который называется разделом «config».

Config является синонимом конфигурации; имя «config» дает нам общее представление о том, что делает этот раздел. Этот раздел можно рассматривать как источник силы композитора, так как мы можем перенастроить все поведение композитора по умолчанию здесь.

{
“config”:{
“config-name”: ”config-value”,
}
}

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

# process-timeout: по умолчанию это 300 секунд. Это процесс с временным интервалом, который может выполнить git clone до того, как композитор предположит, что ссылки не работают. Это может быть продлено, если у вас плохое соединение, или если загружаемый вами пакет большой.

# use-include-path: Это также по умолчанию значение false, но при включении, которое установлено в «true», оно заставляет композитора искать классы в пути и включать их.

# предпочитаемый-установить: по умолчанию «auto» и может иметь источник, dist или auto. Эта опция в основном позволяет вам установить метод установки, который Composer предпочтет использовать. При желании это может быть хэш шаблонов для более детальной установки.

# store-auths: эта опция определяет, какое действие должен выполнить композитор после аутентификации. Может быть установлено значение «истина», «ложь» или «подсказка».

# github-protocol: это список протоколов, используемых при клонировании пакета с github.com. Используемые по умолчанию протоколы: «https», «ssh», «git». Протокол git присутствует, если безопасный-http отключен. Вы можете установить любой из этих протоколов в качестве протокола по умолчанию, используемого композитором для извлечения или передачи в github.

# github-oauth: это список доменов и соответствующий «oauthtoken», который будет использоваться при доступе к этим доменам. Это важно при доступе к частным репозиториям на github. При доступе к частным репозиториям на gitlab мы вместо этого используем gitlab-oauth и gitlab-token.

# disable-tls: по умолчанию это false. Если задано значение true, все HTTPS-URL будут доступны как HTTP, и все шифрование на сетевом уровне будет отключено. Включение этого крайне нежелательно, так как это создает много угроз безопасности. Альтернативой этому является включение расширения php_openssl в php.ini.

# secure-http: по умолчанию установлено значение true, и это гарантирует, что через HTTPS можно загружать только URL-адреса HTTPS. В ситуации, когда доступ к http серьезно необходим, его можно отключить.

#cafile: указывает на место, где в системе находится файл центра сертификации. PHP 5.6 и выше обнаруживает это автоматически.

#capath: В сценарии, где cafile не указан или сертификат не найден, в каталоге, назначенном capath, ищется подходящий сертификат. Заголовок должен быть правильно хешированным каталогом сертификата.

#platform : Это позволяет вам подделывать пакеты платформы (PHP и расширения), чтобы можно было эмулировать рабочую среду или определить целевую платформу в конфигурации.

# vendor-dir: каталогом по умолчанию для сохранения пакетов является каталог vendor. Мы можем установить зависимости в другой каталог, если вы хотите. Просто установив параметры vendor-dir.

# bin-dir: по умолчанию это vendor / bin, все проекты с двоичными файлами находятся в этом каталоге.

# data-dir: этот каталог хранит старые и прошлые файлы composer.phar, чтобы иметь возможность отката к более старым версиям. Каталог по умолчанию для Windows - это «C: / Users / <пользователь> / AppData / Roaming / Composer» и «$ XDG_DATA_HOME / composer» для систем Unix, которые соответствуют спецификациям XDG Base Directory, и «$ home» в других системах Unix.

# cache-dir: в окнах по умолчанию он имеет значения «C: / Users / <пользователь> / AppData / Local / Composer» и «$ XDG_CACHE_HOME / composer» в системах Unix, которые соответствуют спецификациям XDG Base Directory, и «$ home / cache ”На других системах Unix. Хранит все кэши, используемые Composer.

# notify-on-install: Это позволяет компоновщику отправлять уведомления на URL всякий раз, когда установлен пакет. Это по умолчанию верно.

# discard-changes: у этого есть три варианта. «Правда», «ложь» и «заначка». Это позволяет нам устанавливать стиль по умолчанию для обработки грязных обновлений в неинтерактивном режиме. «True» всегда отменяет изменения в поставщиках, в то время как «stash» будет пытаться прятать и повторно применять, а «false» будет просто применять изменения.

# archive-format: указывает формат архивирования, который будет использоваться композитором. По умолчанию он использует «tar» для архивирования файлов.

# htaccess-protect: используется для ограничения composer в каталогах, в которых будут создаваться файлы htaccess. Это может быть установлено в true или false. Если установлено значение false, composer не будет создавать файлы «htaccess» в домашнем каталоге, в кэше и в каталогах данных.

Сообщество композиторов:

Composer - это проект с открытым исходным кодом, в котором каждый волен вносить свой вклад в развитие композитора. Единственное строгое правило, которому следует следовать при написании материалов для композитора, это то, что весь ваш код должен соответствовать стандарту кодирования PSR-2.

В этом уроке мы подробно обсудили конфигурации композитора и его сообщество. Я надеюсь, что это поможет вам внести свой вклад в развитие композитора.

Не забудьте поделиться этим уроком с друзьями, лайкнуть и прокомментировать в разделе комментариев. Увидимся в следующем уроке.

Предыдущая: Интерфейс и команды командной строки Composer (часть 6)
Далее: Деликатное введение в композитор в качестве менеджера зависимостей