Файлы composer json не должны быть общедоступными
Обновлено: 02.07.2024
В этой статье я постараюсь раскрыть некоторые моменты, которые часто бывают непонятны начинающим осваивать Composer пользователям. Я не буду рассказывать что такое Composer и как установить. Такой информации уже предостаточно. А вот что такое composer.lock файл или почему команда install не устанавливает указанный пакет смогут ответить не все. Поэтому давайте пробежимся по этим вопросам.
При рассмотрении возможностей Composer я буду ссылаться на фреймворк Laravel, так как пишу для пользователей MODX, которые как и я хотели бы познакомится с этим фреймворком поближе.
Минимальные требования — понимать, что такое менеджеры зависимостей и в частности Composer, и разобраться с его установкой.
Практически все современные фреймворки используют менеджеры зависимостей. И Laravel не исключение. Работа этого фреймворка построена на использовании Composer от установки до подключения пакетов. Данные для управления зависимостями Composer берёт из файла composer.json , который можно найти в корне проекта, в нашем случае сайта Laravel. В том случае, если вы клонировали исходники Laravel с GibHub, то необходимо провести её установку (будем считать Laravel женского рода :) ). Для этого в командной строке нужно выполнить одну единственную команду:
Composer install
Давайте теперь попробуем понять, что происходит при выполнении этой команды. Мы уже говорили, что все данные Composer берёт из файла composer.json . Но в случае с командой install Composer сначала ищет файл composer.lock . Это очень важный момент. Для чего это нужно мы рассмотрим дальше. А так как в репозитории Laravel этого файла нет, то Composer зачитывает информацию из composer.json . Вот этот файл:
composer.json (кликните, чтобы раскрыть)
Пакеты, которые Composer должен установить перечислены в секциях «require» и «require-dev». Это так называемые зависимости. Для каждого пакета указана версия. У многих, кстати, часто возникает вопрос по назначению этих секций. Мы это рассмотрим дальше. А пока вернёмся к установке.
Composer последовательно устанавливает указанные пакеты и разрешает зависимости уже самих пакетов. Поясню. Как правило, у пакетов есть свои зависимости и эти зависимости указываются также в composer.json самого пакета. Например, посмотрим на исходник пакета fzaninotto/faker, указанного в секции «require-dev». У него в корне можно найти файл composer.json , в котором указаны зависимости для этого пакета.
После того, как все пакеты будут установлены, Composer сформирует файл composer.lock , в котором зафиксирует установленные версии пакетов. Для чего это нужно? Если вы ведёте коллективную разработку, то ваш коллега скачав (pull) проект с гит-репозитория должен получить тоже окружение и версии всех пакетов, что и у вас. Т.е. если у вас в composer.json версия для пакета жёстко не зафиксирована, а указана через маску
и, например, на момент разработки у вас установлена версия 1.1, то в composer.lock будет указана версия 1.1. Тогда ваш коллега при установке получит ту же версию пакета, которая установлена у вас, даже если вышла новая версия 1.2. Именно поэтому практически всегда проекты имеют файл composer.lock в репозитории. Ещё один плюс — в этом файле указаны все зависимости всех пакетов, поэтому при разворачивании проекта не нужно заново определять все эти зависимости, что существенно экономит время.
Ещё раз. Выполняя команду install Composer проверяет наличие файла composer.lock . Если находит, то устанавливает пакеты согласно указанным версиям из него. Если не находит, то обращается к composer.json , устанавливает указанные пакеты и их зависимости и создаёт файл composer.lock .
Composer update
Команда update используется для обновления зависимостей. Она использует только composer.json . Например, если для пакета указана версия с маской «1.*» или "
2.3.0" или «dev-master», то Composer проверит есть ли более новая версия в репозитории для установленного пакета, и если есть, то установит её. И так для каждого пакета. После этого Composer обновит файл composer.lock .
Мы видим, что при установке проекта в случае, если файл composer.lock отсутствует, команды install и update действуют одинаково. Тогда какую же команду использовать? Запомните, при первой установке, а также когда вы загрузили из репозитория новую версию вашего проекта, всегда используйте комманду install , которая проверит изменения в файле composer.lock . А вот когда вам в рабочем проекте вам нужно установить новые пакеты, обновить установленные или удалить ненужные, то вам понадобится команда update (можно использовать альтернативные команды require и remove , которые будут рассмотрены ниже).
Команда update имеет следующий синтаксис:
Надеюсь вам всё понятно. Если да, то кивните.
Вышеописанные команды используются при работе с файлом composer.json . Но у Composer есть и другой способ работы — без использования этого файла.
Composer require
Эту команда используется, когда нужно установить один или пару пакетов. В консоли достаточно набрать
и Composer сделает всю работу — скачает указанный пакет, добавит запись в composer.json в соответствующую секцию и обновит файл composer.lock .
Можно указывать несколько пакетов подряд.
Composer remove
Команда для удаления пакетов. Она также удаляет запись из соответствующей секции зависимостей в composer.json и обновляет composer.lock . Т.е. нам ничего делать не нужно.
Никогда не удаляйте пакеты вручную из директории vendor! Это сломает зависимости Composer.
Для начала этого вполне хватит, чтобы понимать как работает Composer. В дальнейшем, когда неуверенность пройдёт, освоить другие команды будет уже проще. А теперь как и обещал расскажу чем отличаются секции «require» и «require-dev».
Зависимости «require» и «require-dev»
Давайте разберёмся для чего они нужны. В секции «require» указываются пакеты, которые необходимы для работы проекта (сайта или пакета). Это могут быть комментарии, админка, функции для работы с датами и т.п. В секции «require-dev» указывают пакеты, необходимые только для разработки и не влияющие на работу самого проекта.
Но внимательные заметят, что при установке или обновлении Composer устанавливает пакеты из обоих секций. Тогда возникает вопрос — а зачем их делить? Всё просто. Это разделение условное и им управляете вы сами. Composer сам не может определить, где он запускается — на сервере разработки или продакшене. Поэтому, при разворачивании проекта на production сервере, нужно указать Composer, чтобы он не устанавливал пакеты для разработки из секции «require-dev».
И при обновлении также указывать ключ --no-dev
Ещё очень важное замечание. Пакеты из секции «require-dev» устанавливаются только для корневого пакета. Т.е. у зависимых пакетов Composer эту секцию не учитывает. Логика простая — если вы хотите доработать какой-то пакет и вам нужны пакеты для разработки, то установите его напрямую.
Версии
При указании зависимостей в файле composer.json необходимо указать версию пакета. Давайте рассмотрим варианты определения этих версий.
Точная версия
Вы можете указать точную версию пакета. Тогда Composer установить именно эту версию. Если для других зависимостей требуется иная версия, то процедура установки или обновления прервется с ошибкой.
Диапазон
С помощью операторов сравнения вы можете указать диапазоны допустимых версий. Для этого можно использовать следующие операторы: > , >= , < , <= и != .
Вы можете определить несколько диапазонов. Диапазоны, разделенные пробелом или запятой, будут рассматриваться как логические «И». Две вертикальные черты (||) будут рассматриваться как логическое «ИЛИ». «И» имеет более высокий приоритет чем «ИЛИ».
Диапазон через дефис
Определяет диапазон с минимальной и максимальной границей версий. Если в правой части указать неполную версию, то она будет дополнена подстановочным знаком "*" (wildcard).
Подстановка (*)
Для определения любых значений можно использовать шаблон со знаком *.
Тильда (
Данный вариант похож на подстановку, но имеет одно отличие — можно указать нижнюю границу версии. Т.е. последняя цифра указанной версии может быть любой, не не ниже указанной.
Каретка (^)
Каретку ^ часто используют при семантическом версионировании и для разрешения непрерывных обновлений. Её указывают для ограничения мажорной версии, чтобы гарантировать обратную совместимость.
Ветка git
Composer в большой степени ориентирован на использование систем контроля версий, таких как git. Поэтому в качестве номера версии ему можно указать название ветки разработки используя используя специальный префикс dev- . Это может быть полезно при разработке, но в будущем может стать причиной ошибок.
Коммит
Заключение
Надеюсь, эти базовые знания помогут быстрее вникнуть в принцип работы Composer.
Для вводного ознакомления мы установим библиотеку логирования monolog/monolog . Если Вы ещё не установили Composer, обратитесь к главе Введение.
Примечание: для простоты в этом ознакомлении будем считать, что Вы выполнили локальную установку Composer
composer.json : Настройка проекта
Чтобы начать использовать Composer в Вашем проекте, всё, что Вам нужно это composer.json файл. Этот файл описывает зависимости Вашего проекта и может содержать также другие метаданные.
Первым (и часто единственным) делом укажите в composer.json ключ require . Таким образом Вы просто говорите Composer от каких пакетов зависит Ваш проект.
Как Вы можете видеть require принимает объект состоящий из имени пакета (например monolog/monolog ) и версии пакета (например 1.0.* ).
Имя пакета состоит из имени поставщика (vendor) и имени проекта (project name). Часто они будут идентичны - имя поставщика просто существует для предотвращения столкновения наименований. Это позволяет двум разным людям, создать библиотеку с одинаковым именем json , которая затем будет просто названа igorw/json и seldaek/json .
Здесь мы требуем пакет monolog/monolog , поэтому имя поставщика совпадает с именем проекта. Для проектов с уникальным именем такой подход рекомендуется. Это также позволяет позже добавить более смежные проекты в рамках того же пространства имен. Если Вы работаете с библиотекой, это сделает её более легкой и удобной к разделению на меньшие части.
В предыдущем примере мы требуем версию 1.0.* Monolog. Это означает любая версия 1.0 в ветке разработки (development branch). Это эквивалентно сказанному - версия которая соответствует >=1.0 <1.1 .
Ограничения для версий можно указать несколькими способами, читайте версии для получения более подробной информации по этой теме.
По умолчанию только стабильные релизы принимаются во внимание. Если бы Вы хотели бы также получить зависимости RC, beta, alpha или dev версий, Вы можете это сделать с помощью флагов стабильности (stability flags). Чтобы применить это для всех пакетов, вместо того чтобы делать это для каждой зависимости, Вы также можете использовать настройку минимальная стабильность (minimum-stability).
Чтобы установить зависимости для Вашего проекта просто запустите команду install
Это найдёт последнюю версию monolog/monolog , которая соответствует Вашим ограничениям для этой версии пакета, и скачает его в директорию поставщика vendor . Здесь имеет место соглашение ставить код сторонних производителей в каталог с именем vendor . В случае с Monolog, он будет располагаться в vendor/monolog/monolog .
Совет: Если Вы используете git для вашего проекта, Вам вероятней всего необходимо добавить каталог vendor в файл .gitignore . Вы же не хотите добавить весь этот код в Ваш репозиторий.
Вы заметите, что команда install также создала файл composer.lock
composer.lock - Файл блокировки
После установки зависимостей Composer пишет список точных версий в файл composer.lock . Это блокирует Ваш проект для этих конкретных версий.
composer.lock фиксирует Ваши приложения (наряду с composer.json ) в системе контроля версий.
Это важно потому, что команда 'install' проверяет присутствует ли файл блокировки, и если это так, он загружает указанные там версии (независимо от того, что говорит composer.json ).
Это означает, что любой, кто настраивает проект, будет загружать точно такие же версии зависимостей. Ваш CI сервер, рабочая машина, другие разработчики в Вашей команде, все они и всё работает на одних и тех же зависимостях, что снижает потенциал для ошибок, затрагивающих только некоторые части развертывания. Даже если Вы разрабатываете самостоятельно, через шесть месяцев при переустановке проекта, Вы можете быть уверены, что установленные зависимости по-прежнему работают даже если зависимости выпустили много новых версий с тех пор.
Если файл composer.lock не существует, Composer будет считывать зависимости и версии из composer.json и создаст файл блокировки после выполнения команды update или install .
Это означает, что если какая-либо из зависимостей выпустила новую версию, Вы не получите обновления автоматически. Для обновления до новой версии, используйте команду update . Это получит последнюю соответствующую версию (в соответствии с Вашим файлом composer.json ), а также обновит файл блокировки до новой версии.
Примечание: Composer отобразит предупреждение при выполнении команды install если composer.lock и composer.json не синхронизированы.
Если Вы хотите установить или обновить только одну зависимость, Вы можете сделать это следующим образом:
Примечание: Для библиотек не является необходимым фиксировать файл блокировки, см. также: Библиотеки - Файл блокировки.
Packagist является главным репозиторием (хранилищем) Composer. Репозиторий Composer это основной источник пакетов: место, откуда Вы можете получить различные пакеты. Packagist стремится быть центральным репозиторием который используют все. Это означает, что можно автоматически затребовать require для любого пакета который доступен здесь.
Любой проект с открытым кодом используемый с Composer рекомендуется публиковать на Packagist. Библиотекам не обязательно нужно находиться на Packagist чтобы использовать Composer, но это позволяет более быстро обнаруживать их и пробовать их другими разработчиками.
Для библиотек которые поддерживают автозагрузку Composer создаёт файл vendor/autoload.php . Вы можете просто включить этот файл в проект и библиотека автоматически загрузится.
Это делает библиотеку очень простой в использовании третьей стороной. Например: Если Ваш проект зависит от Monolog, Вы можете просто начать использовать классы из него, и они будут видны.
Вы даже можете добавить собственный код для автозагрузчика путем добавления поля autoload (автозагрузка) в composer.json .
Composer зарегистрирует PSR-4 автозагрузку для пространства имен Acme .
Вы определяете сопоставления из пространства имен в директории. Каталог src будет корнем Вашего проекта, на том же уровне, как и vendor каталог. Например файл src/Foo.php будет содержащий класс Acme\Foo .
После добавления поля autoload (автозагрузка), нужно перезапустить dump-autoload для повторного создания файла vendor/autoload.php .
Включая этот файл, он также будет возвращать экземпляр автозагрузчика, так что Вы можете хранить его возвращаемое значение в переменной и добавлять больше пространств имен. Это может быть полезно для автоматической загрузки классов в наборе тестов, например.
В дополнение к PSR-4 автозагрузке Composer также поддерживает PSR-0, classmap и файловую автозагрузку. Смотрите раздел autoload (автозагрузка) для получения большей информации.
Примечание: Composer предоставляет свой собственный автозагрузчик. Если Вы не хотите использовать его одного, Вы можете просто включить файлы vendor/composer/autoload_*.php которые возвращают ассоциативные массивы, позволяя Вам настроить свой собственный автозагрузчик.
Есть ли способ сказать композитору, что каждый раз, когда я выполняю composer update , я хочу, чтобы он игнорировал определенный пакет?
4 ответа
На самом деле я не знаю, есть ли способ указать composer исключить один конкретный пакет из обновления, но вы можете указать, какие пакеты обновлять как
Кроме того, я думаю, если вы сами не перечислите их в composer.json (удалить после установки), то они не будут обновлены, если они также не указаны в списке.
От композитора: Если вы хотите установить или обновить только одну зависимость, вы можете внести их в белый список:
Обновление: (найдено в Интернете, но не проверено)
Для этого просто удалите пакет из composer.lock
Чтобы игнорировать определенный пакет, вы можете использовать provide (если это часть вашего собственного пакета) или replace . Это сообщает Composer, что вы хотите предоставить / заменить определенный пакет, поэтому он не будет его загружать.
Вот пример файла composer.json , который должен работать:
В этом примере пакет patchwork/utf8 будет проигнорирован на composer install или update .
Обновление: доступно только для версий композитора 1.0.0-alpha6 и ниже. Использование его в версии 1.0.0-alpha7 и выше приведет к удалению всех пакетов в "require-dev".
Я считаю, что в настоящее время вы можете обмануть композитора с помощью некоторого беспорядка, если вы можете себе это позволить в своем проекте. Что-то вроде: Поместите все пакеты, которые вы не хотите обновлять, в "require-dev" и запустите обновления с composer update --no-dev
Только будьте осторожны, если вы запустите composer install , насколько я помню, они будут удалены из вашего проекта.
Все эти уловки действительно неприятны, поэтому нам следует дождаться официального способа делать такие вещи, лично я обновляю пакеты, явно указывая их
Думали ли вы об указании требуемой версии для пакета, который вы пытаетесь игнорировать? Например:
Composer – это пакетный менеджер зависимостей, предназначенный для упрощения загрузки и установки сторонних php библиотек в проект. Например, с помощью него можно очень просто добавить в разрабатываемый проект php пакеты, а также развернуть другие проекты, которые распространяются вместе с файлом «composer.json» .
«composer.json» - это текстовый файл, в котором в формате JSON описаны все сторонние пакеты от которых зависит данный проект.
Например, для того чтобы в некоторый разрабатываемый проект добавить сторонние библиотеки, в нём можно просто создать «composer.json» и описать в этом файле все необходимые зависимости. После этого для установки всех требуемых внешних php пакетов в проект достаточно будет ввести в консоли всего одну команду ( composer install ).
Другой вариант заключается в применении команды require . В этом случае самостоятельно создавать файл «composer.json» не нужно. composer require – это команда для установки php пакетов в проект посредством Composer. Кроме установки данная команда также автоматически его пропишет в файл «composer.json» . В дальнейшем для того, чтобы скопировать этот проект, например на другой компьютер, вам не нужно будет переносить туда все внешние пакеты, достаточно будет переместить туда только файл «composer.json» . Установка всех зависимостей на этом компьютере будет осуществляться уже посредством ввода всего одной команды ( composer install ).
При использовании команды require , она ещё выполняет создание файла «composer.json», если его ещё в нет проекте.
Кроме этого, Composer применяется не только для установки php библиотек. С помощью Composer осуществляется также установка различных php фреймворков (Laravel, Yii2, Symfony и др.) и CMS (Drupal, MODX 3 и др.).
Composer представляет собой обычный php скрипт, т.е. программу, написанную на языке php.
Основная цель этой программы заключается в том, чтобы предоставить веб-разработчику удобный инструмент, с помощью которого он сможет очень просто загружать и устанавливать пакеты в проект, их обновлять, а также при необходимости осуществлять их удаление. Все эти действия Composer позволяет выполнить с помощью ввода всего одной или нескольких команд. Удобно, не правда ли?
При установке php пакетов Composer не просто устанавливает их, он также устанавливает все зависимости, от которых эти пакеты зависят. Т.е., например, если загружаемая библиотека будет зависеть от 3 других пакетов, а каждая из них, ещё в свою очередь от нескольких и так далее, то Composer всё это установит автоматически. В противном случае, т.е. без использования Composer, загрузку и установку основных пакетов, а также всех зависимостей придётся выполнять самостоятельно.
Загрузку сторонних библиотек Composer выполняет в папку «vendor», которую данный php скрипт создаёт в корневой директории проекта. Кроме этого, он ещё создаёт специальный файл «autoload.php», включив который в проект вы сразу же подключите к нему все ранее загруженные им библиотеки.
Дополнительно при загрузке сторонних библиотек Composer генерирует ещё файл «composer.lock» . Если «composer.json» - это главный файл Composer, в котором содержится описание основных пакетов, включая требования к их версиям, то «composer.lock» - это файл, содержащий уже не требования, а реальные версии пакетов, которые им были установлены на компьютер пользователя.
Основное назначение файла «composer.lock» заключается в полном сохранении среды, в которой осуществлялась разработка и тестирование проекта.
Например, если вы захотите скопировать проект в какое-то другое место без переноса файла «composer.lock» , то выполнив в нём команду composer install , вы можете получить другие версии пакетов. Эта может случиться из-за выхода новых версий как основных пакетов, описанных в файле «composer.json» , так и их зависимостей, зависимостей их зависимостей и т.д. Например, представим что выход новых версий основных пакетов не произошёл, но обновились версии у пакетов, от которых зависят основные пакеты. В результате установки работающего проекта, можем получить неработоспособный, если в какой-нибудь новой версии одного из этих пакетов была допущена ошибка. Поэтому если вы хотите сохранить полностью среду, то при копировании проекта необходимо дополнительно включать в проект файл «composer.lock» .
Например, разворачивая проект на production, включающий в себя файл «composer.lock» , вы получите те же версии зависимостей, которые у вас были при разработке и тестировании.
Работа с Composer осуществляется в основном в консольном или терминальном режиме, т.е. с помощью ввода команд через командную строку.
Если вы использовали npm, то Сomposer – это нечто подобное, только не для «node.js», а для php.
Как установить Composer
Установка Composer может выполняться по-разному. Она также зависит от используемой среды и операционной системы. Рассмотрим различные варианты.
Установка Composer в Ubuntu, выполняющейся в подсистеме Windows для Linux (WSL)
Как установить локальный веб-сервер для разработки php проектов на подсистему Windows для Linux в Windows 10 можете ознакомиться в этой статье.
Для установки Composer в Windows 10 на подсистему Windows для Linux (WSL) необходимо выполнить следующие команды:
Phar — это исполняемые файлы (программы), которые выполняются посредством php интерпретатора.
Если при установке php пакетов у вас выводиться ошибки на отсутствие прав записи в каталог «
Для установки Composer глобально , т.е. чтобы он был доступен с помощью команды composer необходимо дополнительно выполнить ещё следующую команду:
Эта команда переместит файл «composer.phar» из директории пользователя в директорию «/usr/local/bin» и уберёт у него расширение «phar».
Установка Composer на OpenServer (в Windows)
В OpenServer по умолчанию уже установлен Composer. Находится он в зависимости от выбранной версии PHP (устанавливается в настройках OpenServer) в директории «OSPanel\modules\PHP_*\».
Работа с Composer в OpenServer по умолчанию осуществляется в собственной консоли. Для того чтобы открыть эту консоль необходимо нажать на значок Open Server правой кнопкой мыши в области уведомлений и в открывшемся контекстном меню найти соответствующий пункт.
В консоли для проверки того, что Composer подключен, например, можно ввести команду:
Эта команда также отобразит версию Composer.
Установка Composer на хостинг
Для установки Composer на хостинг, можно просто скачать данную программу самостоятельно, а затем загрузить её в корневую директорию проекта, например, с помощью FTP.
Самостоятельная загрузка нужной версии Composer выполняется со страницы «Download». Версии программы на данной странице расположены в разделе «Manual Download».
Выполнение команд на удалённом сервере обычно осуществляют с помощью SSH. По умолчанию на shared хостингах данный сетевой протокол выключен. Для его включения необходимо найти соответствующий пункт в панели управления, открыть его и нажать в нем на кнопку «Включить SSH».
Если вы пользователь Windows 10, то клиент SSH включен в систему по умолчанию. Поэтому для выполнения команд на удаленном сервере, можно в этой версии Windows не устанавливать никакой дополнительный софт, а например, воспользоваться программой «Командная строка» или «Windows PowerShell».
Основные команды Composer
Разберем основные команды Composer для начинающих.
Если вы используете «composer.phar» локально, то приведённые команды необходимо соответственно изменить в зависимости от того как настроено ваше окружение.
Например, если файл «composer.phar» находится в текущем каталоге и интерпретатор php доступен без указания пути к нему, то установка пакета будет осуществляться так:
Установка пакета
Установка пакета через Composer осуществляется посредством выполнения следующей команды:
vendor — это имя поставщика php пакета, а package — это его название.
Например, добавление в проект пакета twig через composer будет осуществляться так:
Команда require не только загрузит требуемую библиотеку в проект, но и пропишет её ещё в файле «composer.json», т.е. обновит его. Если устанавливаемый пакет зависит от других библиотек, то они также будут установлены или обновлены. Кроме этого ещё будет обновлён файл «composer.lock».
Установка всех пакетов в проект
Установка сразу всех пакетов в проект осуществляется посредством команды:
Эта команда работает следующим образом:
- проверяет, имеется ли файл «composer.lock»;
- если файл «composer.lock» существует, то устанавливает версии, указанные в нём;
- если файла «composer.lock» нет, то разрешает зависимости, описанные в файле «composer.json», создаёт файл «composer.lock» и устанавливает зависимости.
Обновление зависимостей
Команда для обновления установленных библиотек:
Эта команда обновит все зависимости установленные в проекте до последних версий (в соответствии с «composer.json») и файл «composer.lock».
Если необходимо обновить не все пакеты, а один или несколько, то их необходимо перечислить через пробел.
Команда для обновления одной библиотеки:
Удаление пакета
Команда Composer для удаления пакета из проекта:
Для удаления одновременно нескольких пакетов можете их перечислить через пробел:
Обновление Composer
Команда для обновления Сomposer до последней версии:
Обновление lock файла без обновления пакетов
Для обновления файла «composer.lock» без обновления самих пакетов:
Создать новый проект
Создание нового проекта из указанного пакета в текущую директорию выполняется так:
Создание нового проекта в указанную директорию выполняется так:
Вывод всех установленных библиотек
Команда для отображения всех установленных php пакетов:
Проверка валидности файла «composer.json»
Команда с помощью которой можно проверить валидность файла «composer.json»:
Вывод списка всех доступных команд
Вывести на экран все доступные команды Composer можно так:
Очистка внутреннего кэша пакетов Composer
Выполнение очистки внутреннего кэша пакетов Composer осуществляется с помощью команды:
Получение подробной справки по команде
Вывод подробной справки по команде:
Например, вывести подробную инструкцию по использованию команды require можно следующим образом:
Вывести зависимости для указанного пакета
Вывести все зависимости указанного пакета от других можно с помощью команды:
Создание базового варианта файла composer.json с помощью мастера
Примеры использования Composer для установки PHP фреймворков и CMS
Установка фреймворка Laravel в текущую директорию осуществляется через Composer посредством ввода следующей команды:
Установка последней версии фреймворка Yii2 через Composer:
Установка разрабатываемой версии MODX Revolution 3 через Composer:
Установка через Composer нового приложения Symfony, предназначенного для создания традиционных веб-приложений:
Установка Symfony для использования его для создания микросервисов, консольных приложений или API осуществляется так:
Установка Drupal через Composer:
Как удалить Composer
Composer — это файл. В большинстве случаев для удаления его достаточно просто удалить.
Если вы не помните куда был установлен Composer, то просто поищете, например, с помощью встроенной системы поиска операционной системы этот файл.
Но так удалять не всегда корректно, все зависит от того, как вы его устанавливали. Если у инструмента, с помощью которого вы его устанавливали, есть возможность и его удаление, то выполняйте это действие с помощью этого инструмента.
Например, если вы Composer устанавливали с помощью инструмента apt-get, то и используйте его для удаления этой программы.
Например, если вы устанавливали Сopmoser в Windows с помощью программы Composer-Setup.exe, то удаления программы выполняйте стандартным образом через "Приложения и возможности" (только в Windows 10) или через "Удаление или изменение программы".
Читайте также: