как разработать и включить пакет composer?

<p>я хочу разработать пакет на php, но я не хочу, чтобы он был немедленно доступен на github или где-то еще. достаточно просто включить файл packagist в мой <code>composer.json</code>, но как мне добавить локальный пакет в мой <code>composer.json</code>? кроме того, я должен собирать пакет в <code>/vendor/foo/bar</code> (относительно корня <code>composer.json</code>), или я должен поместить его где-нибудь еще?</p><p><strong>правка</strong>: я думаю, мой вопрос о том, как все остальные пишут свои пакеты. каждый новый пакет добавляется в packagist, а затем, когда вы хотите протестировать свои изменения, вы фиксируете github (или где-либо еще), а затем возвращаете его обратно через composer? это кажется действительно неэффективным.</p>

<p>поскольку в этом вопросе есть много различных компонентов/стандартов, которые я хочу объяснить, я постараюсь объяснить как можно больше здесь, и вы можете pm мне или просто google его задать для более конкретных вопросов по мере их появления.</p><p>чтобы ответить на ваш первый вопрос: «как добавить локальный пакет в мой <code>composer.json</code>?»:</p><p>если под «добавить локальный пакет» вы подразумеваете автозагрузку вашего класса/пакета, вы можете сделать это, используя опции psr-4 или psr-0 или classmap в composer. </p><h3>прочитайте больше</h3><ul> <li> <a href="https://web.archive.org/web/20140625062725/http://petermoulding.com/php/psr">psr [petermoulding.com]</a> (через <a href="https://archive.org/">archive.org</a> )</li> <li> <a href="http://seld.be/notes/psr-4-autoloading-support-in-composer">поддержка автозагрузки psr-4 в composer [seld.be]</a> </li> <li> <a href="http://www.sitepoint.com/battle-autoloaders-psr-0-vs-psr-4/">битва автозагрузчиков: psr-0 против psr-4 [sitepoint]</a> </li> <li> <a href="https://stackoverflow.com/q/22803419">зачем использовать автозагрузку psr-0 или psr-4 в composer, если classmap на самом деле быстрее? [так]</a> </li> </ul><p>вы можете использовать google, если вам нужна дополнительная информация о psr-0, psr-4 и classmap.</p><h3>пример</h3><pre><code>"autoload": { "psr-4": { "core\\": "src/core" } ## "standard": { "namespace" : "path/to/dir"} } </code></pre><h3>или (правка)</h3><p>если вы действительно хотите добавить локальный пакет:</p><ol> <li><p>создайте <code>composer.json</code> для локального пакета, например:</p> <pre><code>{ "name": "localpackage/core", "version": "dev-master" } </code></pre> <p>вы также можете указать другие свойства и/или зависимости при необходимости.</p></li> <li><p>заархивируйте пакет с файлом <code>composer.json</code> в качестве корневого файла в <code>archive.zip</code> и поместите его в нужное место.</p></li> <li><p>в другом проекте/пакете, в который вы хотите включить локальный пакет, добавьте имя локального пакета к необходимому параметру, например </p> <pre><code>"localpackage/core": "dev-master" </code></pre> <p>добавьте следующее под параметром <code>repositories</code>:</p> <pre><code>"repositories" : [ { "type": "artifact", "url": "path/to/localpackage.zip" } ] </code></pre></li> </ol><p>теперь, если у вас есть локальный пакет на git, тогда не нужно будет архивировать пакет (в основном, пропустите шаг 2), и вам просто нужно заменить url-адрес в приведенном выше примере на <code>path/to/localpackage/.git</code>.</p><p><em>(конец редактирования)</em></p><hr><p>теперь, чтобы ответить на более широкий вопрос: «как мне разработать и включить пакет composer?»:</p><ol> <li><p>определите структуру каталогов. обычно это так:</p> <pre><code>/packageroot /src/packagecore composer.json ## this is your library’s composer.json license </code></pre> <p>и настройте свой <code>composer.json</code>.</p> <p>пример одного из моих <code>composer.json</code> файлов можно найти по адресу <a href="http://pastebin.com/tyht01xg">http://pastebin.com/tyht01xg</a> .</p></li> <li><p>загрузите его в <a href="https://github.com/">github</a> и <a href="http://git-scm.com/book/en/git-basics-tagging">отметьте версию</a> . используйте <a href="http://semver.org/">семантическое управление версиями</a> (убедитесь, что вы исключаете/игнорируете каталог <code>vendor</code> при загрузке на github).</p></li> <li><p>зарегистрируйте пакет с помощью <a href="https://packagist.org/">packagist</a> (после входа в систему).</p> <p>если вы пометили свой коммит как <code>v1.0.0</code> (или аналогичный), то это отобразится на вашей панели инструментов packagist для этого пакета.</p></li> </ol><p>теперь, если все сделано правильно, вы сможете использовать свою библиотеку в качестве зависимости в других проектах, добавив ее в <code>composer.json</code> этого проекта.</p>

<p>вместо создания нового репозитория вы можете указать composer использовать любой локальный путь:</p><p> <a href="https://getcomposer.org/doc/05-repositories.md#path">https://getcomposer.org/doc/05-repositories.md#path</a> </p><p>например, предположим, что у вас есть php проекты под <code>~/devel/projects</code></p><p>ваш главный проект может быть в <code>~/devel/projects/main\_project</code>, а ваш "локальный пакет" в <code>~/devel/projects/local\_package</code></p><p>определите конфигурацию вашего композитора для локального пакета. в <code>~/devel/projects/local\_package/composer.json</code>.</p><pre><code>{ "name": "your\_vendor\_id/your\_local\_package", ... } </code></pre><p>затем вы можете отредактировать <code>~/devel/projects/main\_project/composer.json</code> и связать свой локальный пакет с помощью пути repo:</p><pre><code>"repositories": [ { "type": "path", "url": "../local\_package", "options": { "symlink": true } } ], "require": { "your\_vendor\_id/your\_local\_package": "dev-master", ... } </code></pre><p>больше информации по этой ссылке (не написано мной, но имеет хорошее объяснение на эту тему):</p><p> <a href="https://carlosbuenosvinos.com/working-at-the-same-time-in-a-project-and-its-dependencies-composer-and-path-type-repository/">https://carlosbuenosvinos.com/working-at-the-same-time-in-a-project-and-its-dependencies-composer-and-path-type-repository/</a> </p>

<p>кажется, что большинство ответов на эту тему не "в курсе". я новичок в composer сам, но эти ответы вводят в заблуждение. вопрос можно просто сформулировать так: «как мне разработать пакет для композитора».</p><p>да, вы можете использовать собственный репозиторий или загрузить незаконченный пакет и обновлять его после каждого изменения. это ни правильное решение, ни ответ на вопрос.</p><p>не поможет то, что <a href="https://getcomposer.org/">официальная документация composer</a> не заявляет об этом заранее, но вы можете увидеть заголовок на <a href="https://getcomposer.org/doc/02-libraries.md">страница документации библиотеки</a> :</p><blockquote> <p>каждый проект представляет собой пакет</p> </blockquote><p><strong>это очень важно понять</strong></p><h3>composer.json:</h3><p>на ранее упомянутой странице указывается:</p><blockquote> <p>для того, чтобы сделать этот пакет устанавливаемым, вам нужно дать ему имя. вы делаете это, добавляя свойство name в <code>composer.json</code></p> <pre><code>{ "name": "acme/hello-world", "require": { "monolog/monolog": "1.0.*" } } </code></pre> </blockquote><p>в этом примере у нас есть требуемый пакет, а теперь имя. обратите внимание на формат <em><code>vendor/name</code></em>.</p><p>теперь перейдем к автозагрузке наших собственных файлов, что описано на странице <a href="https://getcomposer.org/doc/01-basic-usage.md">базовое использование</a> .</p><blockquote> <pre><code>{ "autoload": { "psr-4": {"acme\\": "src/"} } } </code></pre> </blockquote><p>это автоматически загрузит файлы классов пространства имен в каталоге <code>src/acme</code>.</p><p>на веселье.</p><h3>установить обновление</h3><p>установите или обновите пакет с помощью команды:</p><pre><code>composer update </code></pre><p>или же</p><pre><code>php composer.phar update </code></pre><p>это загрузит необходимые пакеты и создаст файл autoload.php</p><p>структура нашего проекта должна выглядеть следующим образом:</p><pre><code>src acme foo.php vendor monolog ... composer.json </code></pre><h3>в том числе</h3><p>теперь, чтобы проверить.</p><p>включить autoload.php</p><p><code>require\_once 'path/to/project/vendor/autoload.php';</code></p><p>предполагая, что foo.php выглядит следующим образом:</p><pre><code><?php namespace acme; class foo { public static function bar(){ return 'baz'; } } ?> </code></pre><p>затем мы можем вызвать это из нашего скрипта:</p><pre><code>echo acme\foo::bar(); // baz </code></pre><hr><p>пожалуйста, исправьте любую вводящую в заблуждение информацию, которую я мог указать. это то, что кажется решением популярного вопроса.</p>

<p>вот резюме решений плюс мой собственный</p><ol> <li>опубликовать на packagist</li> </ol><p>поскольку вы еще не хотите публиковать, вы в разработке, это плохой вариант.</p><ol start="2"> <li>загрузить github</li> </ol><p>вы можете не захотеть публиковать исходный код своей библиотеки на github, не хотите платить за частное репо или иметь возможность использовать облачный внешний сервис (из-за политических или сетевых политик).</p><ol start="3"> <li>архив вашей библиотеки</li> </ol><p>в вашем примере реализации вы можете использовать путь к хранилищу композитора, чтобы указать на локальный zip-файл в качестве выпуска. вам придется заново архивировать zip каждый раз, когда вы вносите изменения в lib, даже с командным файлом, чтобы сделать это, это неприлично.</p><ol start="4"> <li>загрузить в локальный репозиторий git/svn на вашем компьютере</li> </ol><p>это близко, но вам нужно будет обновлять композитора каждый раз, когда вы меняете свою библиотеку и хотите протестировать пример реализации. это имитирует постановки, но громоздко. лично я рекомендую это решение, хотя оно не безмозглое.</p><ol start="5"> <li>автозагрузка библиотеки напрямую (sortof делает то, что вы хотите)</li> </ol><p>это хак, но вы можете просто добавить:</p><pre><code>{ "require": { }, "autoload": { "psr-4": { "yourlibnamespace": "d:\\code\\yourlib\\src\\" } } </code></pre><p>}</p><p>обратите внимание, что вам нужно будет скопировать + вставить раздел 'require' из вашей библиотеки в пример реализации. измените «yourlibnamespace» на пространство имен вашей библиотеки, а «d:\code\yourlib\src \» - на локальный путь к источнику библиотеки.</p><p>таким образом, любые изменения немедленно отражаются. однако вы вообще не будете использовать или тестировать файл composer.json вашей библиотеки. если вы измените требование в своей библиотеке .json, оно не будет выполняться вообще. таким образом, у него есть несколько больших недостатков, но он делает то, что вы хотите, то есть немедленно тестируете реализацию вашей библиотеки с наименьшим количеством возможных команд.</p><ol start="6"> <li>добавьте пример реализации прямо в дерево библиотек<strong> (рекомендуется) </strong></li> </ol><p>обычно у вас просто есть src\и tests \, но у многих есть примеры \, где вы можете найти примеры реализаций. при разработке приложения вы можете внести свой вклад в эти примеры реализации. вы можете сделать это в локальном репозитории git/svn, и у вас есть преимущество в том, что вы автоматически получаете библиотеку 'require' плюс пространство имен. это лучшее из всех миров. я рекомендую этот метод.</p>

<p>чтобы сделать разработку более эффективной, я просто символически связываю репозиторий разработки с каталогом, в котором он уже установлен. </p><p>например, если для <code>/code/project-1</code> требуется пакет из <code>/code/package-1</code>, я:</p><ol> <li>зафиксируйте <code>package-1</code> в github (может быть даже закрытым). </li> <li>затем я говорю <code>project-1</code> установить его с помощью собственного репозитория (см. другие ответы для ссылки на конфигурацию репозитория). </li> <li>как только он будет установлен, я символическую ссылку <code>/code/project-1/vendor/developer/package-1</code> на <code>/code/package-1</code>. </li> </ol><p>таким образом, когда я делаю изменения в <code>/code/package-1</code>, это немедленно отражается в <code>/code/project-1</code>.</p>

<p>может быть, добавление собственного репозитория поможет вам?</p><p> <a href="https://github.com/composer/composer/blob/master/doc/05-repositories.md">https://github.com/composer/composer/blob/master/doc/05-repositories.md</a> </p><p>вы можете очень легко настроить локальный git-репозиторий с вашей библиотекой.</p><p>конечно, если вы используете composer для управления зависимостями, вы должны создать свою библиотеку где-нибудь еще и загрузить ее вендору/через composer, потому что это все, что я думаю.</p>

<p>это мой процесс создания и разработки нового пакета composer локально:</p><ol> <li>создайте новый репозиторий для пакета на github (просто пример)</li> <li>добавьте его в базу данных composer (packagist.org)</li> <li>добавьте его в свой основной проект через composer require. здесь вы начинаете задаваться вопросом, как быстро применить исправления</li> <li>клонируйте его где-нибудь на своей локальной машине, именно здесь вы его разрабатываете</li> <li>теперь, чтобы протестировать вашу локальную версию, добавьте оператор php require (), в который вы загружаете файлы классов, о которых идет речь. автозагрузчик загружает не тот, который был загружен через композитор, а ваш локальный. </li> <li>когда вы закончите исправление, удалите/закомментируйте оператор require, чтобы вернуться к использованию версии пакета для композитора.</li> <li>зафиксируйте все изменения, отметьте фиксацию и нажмите на github; крюк срабатывает для обновления composer. запустите обновление композитора в вашем основном проекте, пакет обновится до вашей локальной версии.</li> </ol><p>это все еще не идеально, но это делает работу для небольших и средних пакетов.</p>

<p>мой рабочий процесс не полностью отвечает на вопрос оп, но может быть полезным для других.</p><ol> <li>мне нравится разрабатывать повторно используемый пакет/lib в реальном проекте, и я не хочу проходить через git/composer локально.</li> <li>мне также не нравится загружать пакет локально по-другому по сравнению с производством (например, с помощью локального оператора require или локальной настройки composer).</li> </ol><p>итак, что я делаю просто: я добавляю пакет прямо в каталог vendor, либо напрямую, либо используя символическую ссылку.</p><h3>недостатки</h3><ol> <li>при использовании обновления/установки composer ваш пакет может быть перезаписан. (поэтому я склонен обновлять или добавлять зависимости по очереди, в течение этого времени).</li> <li>если вы не будете осторожны, установка comoser в производственной среде может установить другую версию. так что продолжайте нажимать на ваш пакет и теги версий!</li> <li>изменяя зависимости пакета и загружая его в родительский проект через обновление композитора, перезаписывает папку пакета</li> </ol>