Файлы composer json не должны быть общедоступными
Я пытаюсь загрузить библиотеку, размещенную на BitBucket, с помощью composer, как описано в официальной документации и здесь, но продолжайте получать следующую ошибку:
Вот мой проект composer.json:
И вот composer.json в моем удаленном репозитории (который, по-видимому, не может быть найден):
Я должен упомянуть, что оба файла composer.json находятся в корневом каталоге, как и должно быть.
Еще несколько замечаний:
Я также пробовал подход «некомпозиционный пакет», при котором я указываю информацию о пакете в моем проекте composer.json и опускаю composer.json из моего удаленного репозитория, как указано в документация . Это успешно клонирует основную ветку, но затем приводит к следующей ошибке:
Однако пакет загружается в / vendor, как и ожидалось, поэтому я не уверен, почему он снова пытается выполнить проверку мастера.
Я не хочу решать эту проблему таким образом (я бы предпочел использовать composer.json в удаленном репозитории), но это может помочь выявить проблему в другом месте.
Спасибо за любую помощь.
ИЗМЕНИТЬ
Пакет packages.json выглядит так:
Это единственный способ заставить это работать? Размещение моего собственного файла packages.json кажется излишним, если я собираюсь использовать только один или два собственных пакета.
Тем не менее, это дает мне ту же ошибку Git, о которой я упоминал ранее.
ИЗМЕНИТЬ 2
Принудительная ошибка (неверный пароль SSH) дает следующее:
Так что я ясно вижу, что он здесь делает. Однако кажется, что после эта команда запустит cd в каталог .git и попытается запустить:
Предположительно, чтобы избавиться от экземпляра composer, который он вытащил. Однако он запускает это в неправильном каталоге, и я не могу понять, почему ..
Поэтому файл packages.json выглядит так:
Кроме того, похоже, что запись реестра автозапуска, которая у меня была для командной строки, мешала запуску композитора.
Я только что обновил composer.json до последней версии, и проблема исчезла.
Хотя это можно считать некромантией, вчера я наткнулся на этот вопрос, когда у меня возникла такая же проблема (хотя в моем случае я запускал контейнер Ubuntu Docker, а не Windows, как OP), и подумал, что оставлю свои мысли и решение здесь если кто-нибудь еще наткнется на это.
Версия Composer для репозитория Ubuntu в настоящее время находится на уровне 1.6.x (на момент написания, я полагаю, Composer имеет версию до 1.9.1), и я получал разные ошибки в зависимости от того, запускал ли я composer install с разными уровнями Ведение журнала. Без регистрации он стонал, что не может найти действительный composer.json . При ведении журнала он стонал, что не может получить доступ к репо (несмотря на сканирование тегов).
Решение для меня заключалось в том, чтобы глобально установить последнюю версию Composer, поскольку версия репозитория Ubuntu использовала устаревшие вызовы API BitBucket (v1 устарела). Как только я обновился до более новой версии Composer, установка прошла отлично.
Поэтому проверьте свою версию Composer и, если возможно, установите обновленную версию (локальная установка / установка проекта тоже должна работать).
Я знаю, что это немного устарело, но для тех, кто может столкнуться с этой проблемой, у меня это работает так.
Очистите кеш композитора.
Повторно запустите сценарий сборки Satis.
У меня была такая же ошибка, после удаления папок из vcs все работает нормально
В Windows (как предложил @Serbu):
Очистка каталогов vcs, репо и файлов в C: \ Users \ Me \ AppData \ Local \ Composer \
Вы не должны включать спецификацию version в composer.json вашей библиотеки, если она фактически управляется поддерживаемой системой контроля версий. В настоящее время вы говорите, что ваша основная ветка IS версии 0.3 (стабильная версия), но вы пытаетесь включить «dev-master» (нестабильная версия). Composer может запутаться, если это программное обеспечение действительно «dev-master» или «версия 0.3».
Если вы действительно разрабатываете новые выпуски для серии 0.3.x в своей основной ветке, вам следует вместо этого определить псевдоним ветки. Добавьте это в свою текущую ветку разработки для версий 0.3.x:
Если вы хотите перейти к версии 0.4 или 1.0, вы должны перейти в «последнем» состоянии серии 0.3 с веткой с именем «0.3.x», а затем обновить composer.json в главной ветке, чтобы указать dev- master на новый псевдоним (например, "dev-master": "0.4.x-dev" ). Вы также можете назвать свою старую ветку 0.3 как хотите, а затем добавить псевдоним для этой ветки.
Это позволит вам потребовать последнюю разрабатываемую версию 0.3.x, например:
Это приведет к получению последней версии 0.3, которая в настоящее время будет последней фиксацией в основной ветке из-за определенного псевдонима.
То, как вы в настоящее время настроены, заставляет вас явно включать версию 0.3, которая является движущейся целью, без явного уведомления об этом факте.
Предоставление явного тега версии должно выполняться только в том случае, если нет доступной системы управления версиями, которая может дать Composer номер версии, то есть нет доступных тегов или теги не соответствуют требованиям Composer для номеров версий. Поскольку кажется, что вы контролируете эти vcs, вероятно, будет хорошей идеей привести теги в соответствие со стандартом Composers вместо того, чтобы создавать проблемы с выпуском новой версии.
Я ожидаю, что после того, как вы это исправите, ваша установка больше НЕ потребует этот файл package.json, потому что теперь этот файл устраняет проблему, созданную вами с помощью этого объявления версии. Тогда вам также больше не понадобится эта ссылка на композитора, но вы можете вернуться к упоминанию исходного репозитория, как и вы.
Если вы чувствуете, что используете слишком много частных репозиториев, для которых требуется больше частных репозиториев, и вам надоело упоминать их все в длинном списке, вы можете подумать об использовании Satis, чтобы создать такой список найденных пакетов вместо того, чтобы создавать их вручную.
I'm trying to load a library I have hosted on BitBucket using composer as explained both in the official documentation and here, but keep receiving the following error:
Here is my project composer.json:
And here is the composer.json in my remote repository (that apparently can't be found):
I should mention that both composer.json files are in the root directory as they should be.
Some other things to note:
I've also tried the "non-composer package" approach, whereby I specify the package information in my project composer.json, and omit the composer.json from my remote repository, as outlined in the documentation. This successfully clones the master branch but then results in the following error:
However, the package is downloaded to /vendor as expected, so I'm not sure why it's trying to checkout master again.
This is not the way I wish to solve this problem (as I'd rather make use of a composer.json in the remote repository), but it might help identify an issue elsewhere.
Thanks for any help.
EDIT
The packages.json looks like:
Is this the only way to get this working? It seems a bit overkill to host my own packages.json file if I'm only going to be using one or two in-house packages.
Regardless, this is giving me the same Git error as I mentioned previously.
EDIT 2
Forcing an error (invalid SSH passphrase) gives this:
So I can clearly see what it's doing here. However, it seems after this command runs it cd s into the .git directory and tries running:
Presumably to get rid of the composer instance it pulled. However, it's running this in the wrong directory and I can't figure out why..
Does the composer.json in the remote repository exist in the master branch or just a development branch? Composer (unfortunately) only looks in the master branch I believe.
Weird, the error message implies it looks in all branches. Either way, master does have the composer.json file.
Is the master branch set as the 'default branch' (The place to look for that is described in stackoverflow.com/questions/14040754/…) I've never seen anyone have to use the "reference": "master" before.
Yep, master is set as the main branch in Bitbucket. If I omit "reference" I receive an error saying that it expects the "source" to include the properties "type", "url" and "reference".
6 Answers 6
I know this is a bit old, but for some that might encounter this issue, this is how it works for me.
Clear the composer cache.
Rerun the satis build script.
Thanks. This worked for me. I ran into this issue with a package that worked just fine previously. I started getting this error only after migrating to a new computer. All I needed to do was clear the composer cache. Whew.
You must not include a version specification in your library's composer.json if it is actually managed by a supported source control system. Currently you are saying that your master branch IS version 0.3 (which is a stable version), but you are trying to include "dev-master" (which is an unstable version). Composer might get confused if that software really is "dev-master" or "version 0.3".
If you actually are developing new releases for the 0.3.x series in your master branch, you should define a branch alias instead. Add this to your current development branch for versions 0.3.x:
If you want to move on to version 0.4 or 1.0, you'd branch at the "last" state of the 0.3 series with a branch named "0.3.x" and then update the composer.json in the master branch to point dev-master to a new alias (like "dev-master": "0.4.x-dev" ). You could also name your old 0.3 branch anyway you like and then add an alias for THAT branch.
Doing this will enable you to require the latest development version of 0.3.x like this:
This will pull the latest 0.3 version - which currently would be the latest commit in the master branch because of the defined alias.
The way you are currently set up forces you to explicitly include version 0.3, which is a moving target without making that fact explicitly known.
Giving an explicit version tag should only be done if there is no version control system available that is able to give Composer the version number, i.e. there are no tags available, or the tags do not comply with Composer's requirement for version numbers. Since you seem to be in control of that vcs, it probably is a good idea to make the tags conform to Composers standard instead of making it troublesome to release a new version.
After you fixed this, I do expect your installation to NOT require that package.json file anymore, because that file now repairs the trouble you created with that version declaration. You'd then also not need that composer reference anymore, but can revert back to mentioning the original repository like you did.
If you feel you are using too many private repositories which are all requiring more private repositories, and are sick of mentioning them all in a long list, you could think about using Satis to create such a list of found packages instead of manually creating them.
Вопрос следует сформулировать более широко: насколько вообще безопасно размещение директория /vendor в структуре сайте в production-среде?
Допускаю, что кому-то это может облегчить злые намерения. Злоумышленники могут видеть версии используемых библиотек, например, что упростит для них поиски эксплоитов.
Есть ли способ вынести директорий /vendor за структуру сайта? Нужно ли (возможно ли) это? Пока я нашел только одну статью на эту тему. Если копнуть глубже, то предлагается запретить доступ к чувствительным файлам на уровне IP-фильтрации.
А есть ли альтернативные способы? Кто и как решает эту задачу в продакшене?
Ваша основная ошибка - корень сайта совпадает с корнем проекта. Перенесите то, что должно быть доступно на сайте, в подкаталог наподобие public_html и сделайте его корнем сайта, а vendor не переносите - и проблема исчезнет сама собой.
Не совсем понимаю. Я на IIS (Windows Server). Все сайты размещены в каталоге inetpub . Например: C:\inetpub\site1 и внутри site1\vendor . То есть, в ваших формулировках, да, корень сайта совпадает с корнем проекта (какого проекта? ;-)
Автоматизация сборки
Я искал решение для автоматизации сборки packages.json, и, просматривая различные источники, быстро нашел два возможных (и очень популярных) варианта: private packagist и satis. Во время моих исследований private packagist был только зарелижен и не был бесплатным для такой организации, как наша. По этой причине я решил попробовать satis (не могу не отметить, что мне очень нравится решать такие рабочие проблемы, проводить исследования, путем проб и ошибок, поэтому это решение я принимал с энтузиазмом).
Но если вы такие же любители приключений, как и я, то читайте дальше :)!
Установка Satis
Как описано в документации, чтобы установить satis, вам нужно запустить: composer create-project composer/satis:dev-master --keep-vcs .
Команда satis
Satis можно запустить командой со следующим форматом: php bin/satis build
Как вы можете заметить, эта команда состоит из трех частей. Сначала вам нужно указать путь к исполняемому файлу satis, затем вам нужно указать, какой файл конфигурации вы хотите использовать (обычно это файл satis.json, о котором мы поговорим в следующем абзаце), и, наконец, выходную папку, в которую он сгенерирует все необходимые файлы для работы вашего приватного composer, одним из которых будет файл packages.json. Он также сгенерирует веб-страницу, на которой будут представлены все ваши доступные пакеты, номера доступных версии и так далее.
Файл satis.json
Файл satis.json нужен для конфигурации satis, которая в целом заключается в передаче ему информации о месте расположения ваших приватных пакетов, чтобы он мог находить их и работать с ними. В документации есть информация о доступных параметрах. В моем файле я перечислил все GitHub URL моих приватных пакетов и посредством параметра “require-all”: true указал, что хочу собрать каждую ветку, которую Satis найдет в них. Я дам ссылку на мой файл satis.json чуть ниже.
Сейчас же мы на том этапе, когда у нас есть команда satis, управляемая настроенным файлом statis.json, который генерирует индекс для нашего приватного composer’а. Но мы все еще должны вручную запускать команду satis каждый раз, когда мы хотим обновить наш индекс. В идеале мы могли бы автоматизировать запуск команды каждый раз, когда мы проищводим коммит в любой из наших репозиториев.
Для этого нам нужно подготовить скрипт, который будет вызываться через вебхуки GitHub (или эквивалентные) каждый раз, когда мы отправляем новые коммиты или новые теги версии. Вся работа этого скрипта будет заключаться в выполнении команды satis build для повторной генерации нашего приватного индекса composer.
Скрипт для обновления индекса
Я добавил скрипт обновления в zip файл, прилагаемый к этой статье.
Давайте посмотрим, что в нем нужно конфигурировать. На 9-й строке у вас есть массив $config, где вам нужно указать, где находится ваш исполняемый файл satis (это самая первая часть команды сборки statis), где находится ваш файл satis.json (это вторая часть) и вы указываете, куда будет генерироваться индекс packagist (это третья часть).
Это единственные конфигурации, которые вам нужно произвести. Эти аргументы будут использоваться для вызова команды satis build , которую затем этот скрипт для вас выполнит.
Выполнение обновления может быть довольно долгим, и из этого факта мы можем сделать два следующих вывода:
Во-первых, нет смысла перестраивать весь индекс со всеми вашими приватными пакетами, если вы запушили только один из них. Мы должны рассмотреть возможность частичной пересборки.
Во-вторых, поскольку мы не знаем, сколько времени это займет, неплохо было бы настроить какое-то уведомление, чтобы мы знали, когда скрипт заканчивает работу. Это важно, потому что его завершение является сигналом того, что теперь вы можете выполнить обновление composer из своего проекта, чтобы получить актуальные версии ваших приватных пакетов.
Вебхуки
Разместите скрипт обновления в сети, где к нему можно будет получить доступ по URL, например. Мы будем использовать этот URL в качестве таргета для наших вебхуков.
Принимая во внимание частичные обновления индекса, в зависимости от того, как настроен вебхук, мы можем заранее знать, какого репозитория касаются изменения, и предоставлять эту информацию скрипту, чтобы он пересобирал только те части индекса, которые нужно. Пуш коммитов в репозиторий может означать, что мы добавили некоторые коммиты к существующему номеру версии или создали новый номер версии.
У Satis есть параметр –repository-url , который нужен, чтобы приказать Satis сосредоточиться на сканировании только этого конкретного репозитория. Мы связали наши вебхуки с этим параметром, чтобы все вебхуки содержали имя репозитория в специальном параметре, например. В случае с GitHub-вебхуками вам может не понадобиться передавать параметры в URL, потому что вы также получаете json со всей необходимой информацией. Вся идея состоит в том, чтобы, когда скрипт обновления получал вебхук, он знал URL репозитория, который он должен обновить. Это улучшение ускорило выполнение нашего скрипта в 20 раз (потому что на то время у нас было около 20 приватных репозиториев), так что, это колоссальное улучшение производительности.
Уведомление
Поначалу, когда скрипт обновления запускался, я был более чем уверен в том, что он запускается должным образом благодаря вебхукам, но я понятия не имел, завершился ли он, или все еще работает. Таким образом, я наудачу запускал composer update в своем проекте, и в половине случаев он выдалвал мне “нечего обновлять или устанавливать”, а в другой он начинал обновлять или устанавливать обновленные зависимости.
Чтобы не заниматься этим бессмысленным выжиданием, я настроил простое уведомление в выделенном канале, которое предупреждало всех, кто следит за этим каналом, о том, что индекс одного пакета был обновлен и теперь доступен для всех. Так дела пошли намного лучше, и я настоятельно рекомендую вам сделать что-то подобное в вашей собственной среде.
Ссылка на ваш приватный packagist внутри ваших проектов
Теперь, когда у вас есть доступный в онлайне индекс приватного composer, откройте файл composer.json вашего проекта и найдите раздел repositories. Затем добавьте запись с типом composer и URL вашего индекса подобно тому, как показано ниже:
Trying out to make a private composer index
2 ответа 2
Серверному коду в document_root вебсервера вовсе нечего делать. В document_root должен быть index.php . И всё, всё остальное здесь не нужно и размещается где-то уровнем выше.
By setting basic/web as the document root, you also prevent end users from accessing your private application code and sensitive data files that are stored in the sibling directories of basic/web. Denying access to those other folders is a security improvement.
The public directory is the home of all of your application's public and static files, including images, stylesheets and JavaScript files. It is also where the front controller (index.php) lives.
The public directory serves as the document root when configuring your web server. In the examples below, the public/ directory will be the document root. This directory is /var/www/project/public/.
Что там ещё из популярного? Уверен что найдёте в документации всё то же самое: document_root вашего веб-сервера должен смотреть куда-то внутрь проекта, но не в корень. Следовательно, вас вовсе никак не волнует что кто-то попытается загрузить что-то. Пусть пытается, для веб-сервера существуют файлы в document_root, где лежит только то что вы сами решили публиковать.
Иначе говоря, нормальная структура проекта:
Веб-сервер смотрит строго в public .
а webconfig должен настроить перенаправление всего, что приходит, в webroot . Правила описываются в разделе
Далее мы рарзрешаем доступ ко вложенным директориям и некоторым файлам, например css, js и т.п.
а все остальные запросы мы перенаправляем в index.php (что в целом справедливо для любого фреймворка)
таким образом клиент может обратиться только к содержимому папки webroot , и не видит ни composer.json ни vendor и ничего иного, чего ему не положено видеть.
в общем говоря, если вы используете какой-либо фреймворк, то ознакомьтесь с инструкциями по его разворачиванию на IIS, примеры конфигураций должны быть в документации. А если не используете, то возьмите подход, описанный в каком-либо фреймворке и следуйте ему в своем проекте.
Как у организации, создающей вручную несколько качественных сайтов в год, у нас быстро возникла необходимость извлечения максимальной выгоды из определенного набора базовых средств. Несмотря на то, что некоторые из них были публичными или аутсорсными, как, например, наш фреймворк Wonderwp или библиотека pew.js, остальные мы бы хотели по возможности оставить приватными.
Главным техническим средством в наших процессах сборки является Composer. Мы используем его из-за удобства управления нашими зависимостями, поэтому мы бы очень хотели, чтобы он позаботился и о наших приватных плагинах. Поэтому первым нашим шагом стало изучение официальной документации composer относительно приватных репозиториев. Ниже приведена некоторая квинтэссенция информации, как мне кажется, релевантной для нашей ситуации:
По умолчанию, когда вам требуется установить зависимость, первым делом composer будет искать ее в своем собственном индексе packagist. Если ваша библиотека или репозиторий отсутствует в этом индексе, как в случае с приватными репозиториями, вы должны показать composer’у, где их можно найти, с помощью раздела repositories в вашем файле composer.json.
У вас есть выбор между разными типами репозиториев, но в нашем случае это либо vcs, либо composer. Другими словами, либо вы добавляете запись vcs для каждой приватной зависимости в ваш файл composer.json, чтобы composer знал, где найти ваши приватные репозитории, либо вы можете создать свой собственный приватный composer.
В наших проектах мы обычно задействуем от 6 до 10 приватных зависимостей. Таким образом, выбрав vcs, нам нужно будет вручную добавить столько vcs-записей, сколько приватных зависимостей мы задействовали. Как это выглядит, можно посмотреть в этом примере. Эти vcs-записи должны содержать полный GitHub-путь, а машина, которая будет выполнять вызов composer install, обязательно должна быть аутентифицирована на GitHub ключом ssh для получение доступа к извлечению пакетов. Как видите, это достаточно трудоемкий процесс, ведь количество работы пропорционально (растущему) списку наших приватных пакетов. Но наверняка существует более удобный способ.
Оказалось, composer — это и есть тот самый более удобный способ. Я не знаю, читали ли вы соответствующий параграф в официальной документации, я, в свою очередь, после прочтения не смог похвастаться полным пониманием происходящего. Но так как это больше всего остального походило на то, что мы искали, я решил попробовать, и вот что из этого получилось.
Заключение
Хостинг собственного приватного packagist может оказаться довольно сложной задачей, если вы никогда раньше этим не занимались. Я надеюсь, что это небольшое руководство поможет облегчить этот процесс. Например, поскольку я не был специалистом по composer, мне потребовалось несколько дней исследований, проб и ошибок, прежде чем я достиг уровня готовности для продакшена. Это можно рассматривать как неплохую инвестицию. Я очень надеюсь, что благодаря этой статье вы разберетесь во всем быстрее, чем я.
И как только вы все настроите и запустите, вашим разработчикам будет намного проще использовать приватные репозитории. Помимо дополнительной строки, которую нужно поместить в раздел репозиториев вашего проекта, запрос приватных зависимостей будет почти таким же простым, как и публичных. В этом и заключается весь смысл этой затеи.
Composer произвел революцию в управлении пакетами в PHP и помог разработчикам по всему миру создавать независимый от фреймворков и разделяемый код. Но все же мало кто выходит за рамки основ его функционала, так что данная статья постарается осветить некоторые полезные приемы его использования.
Глобальная установка (Global)
Несмотря на то, что данная опция доступно описана в документации, Composer может (а в большинстве случаев должен) быть установлен глобально. Глобальная установка означает, что вместо:
Вы можете в любом проекте просто ввести:
Это позволяет очень просто создавать новые проекты (например, с помощью команды create-project) в любом месте вашей файловой системы.
Для установки Composer глобально, следуйте этим инструкциям.
Правильная установка зависимостей
Just add the following to your composer.json file:
Но данный подход имеет несколько недостатков. Во-первых, простой копипаст может привести к возникновению ошибок. Во-вторых, для новичка может быть не очевидно, где разместить данный код, если у него и так уже имеется обширный файл composer.json, и это также привести к ошибке. Наконец, некоторые люди будут иметь дело с Composer впервые, а возможно и впервые столкнутся с командной строкой. Поэтому хорошей практикой будет освещение всевозможных случаев, в которых новички могут чувствовать себя неуверенно (есть ли у них графический редактор или они будут использовать командную строку? Если второе, установлен ли в ней текстовый редактор, и если да, то какой? Объясняете ли вы саму процедуру редактирования файла? А что если файла composer.json ещё не существует в проекте? Описываете ли также принцип создания нового файла?).
Это добавит все необходимое в файл зависимостей, минуя ручное вмешательство.
Если вам нужно добавить пакеты в раздел require-dev, добавьте в команду опцию --dev:
Также, команда require поддерживает добавление нескольких пакетов одновременно, для этого просто разделите их пробелом.
Файлы блокировок
Файл composer.lock сохраняет текущий список установленных зависимостей и их версии. Таким образом, на момент, когда версии зависимостей уже будут обновлены, другие люди, которые будут клонировать ваш проект, получат те же самые версии. Это позволяет убедиться в том, что каждый, кто получает ваш проект, имеет “пакетное окружение”, идентичное тому, которое вы использовали при разработке, и помогает избежать ошибок, которые могли бы возникнуть из-за обновления версий.
Файл composer.lock почти всегда должен быть добавлен в систему контроля версий (не всегда).
Также, файл composer.lock содержит хэш файла composer.json, так что, если вы даже просто обновляете данные об авторе проекта, вы получите предупреждение о том, что файл блокировки не соответствует .json файлу. В таком случае, поможет команда composer update --lock, которая обновит только сам файл блокировки, не касаясь ничего другого.
Версионирование
- указание тильды (~1.2.3) будет включать в себя все версии до 1.3 (не включительно), так как в семантическом версионировании это является моментом внедрения новых функциональных возможностей. В данном случае будет получена последняя из стабильных минорных версий. Как гласит документация, при данном указании изменяться может только последняя цифра версии.
- указание знака вставки (^1.2.3) буквально означает “опасаться только критических изменений” и будет включать в себя версии вплоть до 2.0. Применительно к semver, изменение мажорной версии является моментом внесения в проект критических изменений, так что версии 1.3, 1.4 и 1.9 подходят, в то время как 2.0 — уже нет.
Локальная и глобальная конфигурация
Значения параметров по-умолчанию не высечены на камне. Подробное описание возможных параметров конфигураций (config) см. по ссылке.
вы заставляете Composer оптимизировать classmap после каждой установки или обновления пакетов (или, другими словами, всякий раз, когда генерируется файл автозагрузки классов). Это немного медленнее, чем создание автозагрузчика по-умолчанию, и замедляется при росте проекта.
Ещё одним полезным параметром может быть cache-files-maxsize. В больших проектах (как eZ Publish или Symfony) кэш может заполниться довольно быстро. Увеличение размера кэша позволить Composer работать быстро дольше.
Профилирование и подробный вывод (verbose)
Если вы добавите параметр --profile к любой команде при использовании Composer в командной строке, то в выводе будет содержаться не только конечный результат, например:
Но также в начало каждой строки вывода будет добавлено время выполнения команды и использованный размер памяти:
Я использую данную опцию для определения “медленных” пакетов и для наблюдения за улучшением или ухудшением производительности на разных версиях PHP.
Подобно предыдущему, параметр --verbose заставит Composer выводить больше информации о каждой выполняемой операции, давая вам понять, что именно происходит в данный момент. Некоторые люди даже устанавливают composer --verbose --profile псевдонимом команды composer по-умолчанию.
Пользовательские источники
Если ваш проект ещё не на Packagist, иногда вам нужно просто установить пакет с GitHub (например, если пакет ещё находится в разработке). Для этого см. наше руководство.
Когда у вас есть своя версия популярного пакета, от которого зависит ваш проект, вы можете использовать пользовательские источники в сочетании с контекстными псевдонимами (inline aliasing), чтобы подставить собственную ветку для публичного пакета, как здесь описал Matthieu Napoli.
Ускорение Composer
Используя отличный метод, описанный Mark Van Eijk, вы можете ускорить выполнение Composer, вызывая его через HHVM.
Ещё один способ — с помощью параметра --prefer-dist, при установке которого Composer будет скачивать стабильные, запакованные версии проекта, вместо клонирования из системы контроля версий (что значительно медленнее). Этот параметр используется по-умолчанию, так что вам не нужно включать его на стабильных проектах. Если вам нужно загрузить проект из исходников, используйте параметр --prefer-source. Подробнее об этом можно узнать в разделе install здесь.
Уменьшение размера проекта Composer
Если вы разработчик «Composer-friendly» проектов, данная часть вас также заинтересует. По этому посту в Reddit, вы можете с помощью файла .gitattributes игнорировать некоторые файлы и папки во время упаковки пакета для режима --prefer-dist.
Как это работает? Когда вы загружаете проект на GitHub, он автоматически делает доступным ссылку “Download zip”, с помощью которой вы можете скачать архив вашего проекта. Более того, Packagist использует эти автоматически сгенерированные архивы для скачивания зависимостей с опцией --prefer-dist, которые он затем локально разархивирует (намного быстрее клонирования исходных файлов проекта). Если вы при этом добавите в .gitattributes тесты, документацию и прочие файлы, не имеющие отношения к логике работы проекта, указанные архивы не будут их содержать, став гораздо легче.
При этом людям, которые захотят отладить вашу библиотеку или запустить тесты, нужно будет указать параметр --prefer-source.
PhpLeague приняла этот подход и включила его в свой «скелет пакета» (Package skeleton), так что любой основанный на нем проект автоматически будет “dist friendly”.
Если вы вдруг забыли, какую версию PHP или его расширения используете, или вам нужен список всех установленных проектов (с описанием каждого) с их версиями, вы можете использовать команду show с параметрами --platform (-p) и --installed (-i):
Репетиции (Dry Runs)
Чтобы просто посмотреть, пройдет ли установка новых зависимостей успешно, вы можете использовать параметр --dry-run для команд install и update. Composer в данном случае выведет все потенциальные проблемы без непосредственного выполнения самой команды. Никаких реальных изменений в проекте не произойдет. Этот прием отлично подходит для тестирования сложных зависимостей и настройки изменений перед реальным их внесением.
Создание проекта
Последнее, но не менее важное, что мы должны упомянуть — это команда create-project.
Команда создания проекта принимает в качестве аргумента имя пакета, который она затем клонирует и выполняет composer install внутри него. Это отлично подходит для инициализации проектов — не нужно больше искать Url нужного пакета на GitHub, клонировать его, самому переходить в папку и выполнять команду install.
Крупные проекты, такие как Symfony и Laravel, уже используют данный подход для инициализации своих «skeleton» приложений, и многие другие также присоединяются.
Например, в Laravel это используется следующим образом:
В команду create-project можно передать еще два параметра: путь, в который нужно установить проект (если не указан, используется имя пакета), и версия (будет использована последняя, если не указать).
Заключение
Надеюсь, данный список советов и приемов использования оказался для вас полезным. Если мы что-то упустили, расскажите нам об этом, и мы обновим статью. И помните, если вы забыли какие-либо команды или опции, просто загляните в шпаргалку. Happy Composing!
Создаем индекс для приватного composer’а
Как я уже говорил выше, когда я впервые прочитал документацию, я был немного сбит с толку. Но я был полон уверенности, что разберусь что к чему, стоит только начать работу. Итак, сначала нам нужно создать файл packages.json, в который мы поместим всю информацию о приватных репозиториях, а затем добавим ссылку на этот файл в наш файл composer.json, чтобы composer тоже знал о них.
Также я обратил внимание на информацию о том, что называлось определением минимального пакета (minimal package definition). Выглядит это примерно так:
Что можно приблизительно перевести как следующее: “Composer, если потребуется smarty/smarty версии 3.1.7, zip можно найти здесь. Часть dist также может являться URL размещенного на виртуальном узле git-репозитория, но это, вероятно, больше про проприетарные приватные пакеты.
Итак, чтобы создать наш файл packages.json, нам нужно составить список определений пакетов. Для каждой приватной библиотеки, которую мы собираемся использовать, мы должны добавить одно определение пакета под каждый номер версии (и их количество может быть довольно большим).
Заметная разница между репозиториями vcs и zip заключается в том, что вам также необходимо указать в части dist номер ссылки, который на самом деле является id коммита. И это очень важно, потому что необходимость следить за правильностью и актуальностью этой ссылки, а также то, что для каждой версии библиотеки необходимо отдельное определение пакета, ясно намекают, что нам нужен такой инструмент, как private packagist или satis, для автоматизации сборки packages.json, что необходимо, чтобы сделать эту фичу composer’а пригодной для экплуатации.
Без автоматизированного решения вам приходится заниматься редактированием файла packages.json каждый раз, когда вы добавляете новую версию в один из ваших репозиториев, и, что еще хуже, каждый раз, когда вы добавляете новые коммиты в любую версию, чтобы обновить номер версии. Делать все это вручную — чистой воды безумие.
Читайте также: