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

Я хочу разработать пакет на PHP, но я не хочу, чтобы он сразу был доступен на GitHub или где-то еще. Достаточно легко включить файл Packagist в мой composer.json, но как добавить локальный пакет в мой composer.json? Кроме того, должен ли я строить пакет в /vendor/foo/bar (относительно корня composer.json), или я должен помещать его в другое место?

Изменить. Я думаю, мой вопрос в том, как все остальные записывают свои пакеты. Добавляет ли каждый новый пакет в Packagist, а затем, когда вы хотите протестировать свои изменения, вы передаете GitHub (или где бы то ни было), а затем вытащите его обратно через Composer? Это кажется действительно неэффективным.

Ответ 1

Поскольку у этого вопроса есть много разных компонентов/стандартов, которые будут объяснены, я постараюсь объяснить как можно больше здесь, и вы можете PM меня или просто Google для более конкретных вопросов по мере их появления.

Чтобы ответить на ваш первый вопрос: "Как добавить локальный пакет в мой composer.json?":

Если "добавить локальный пакет" означает автозагрузку вашего класса/пакета, вы можете сделать это, используя PSR-4 или PSR-0 или варианты Classmap в композиторе.

Подробнее

Вы можете использовать Google, если вам нужна дополнительная информация о PSR-0, PSR-4 и Classmap.

Пример

"autoload": {
   "psr-4": { "Core\\": "src/Core" }  ## "standard": { "namespace" : "path/to/dir"}
}

Или (изменить)

Если вы действительно хотите добавить локальный пакет:

Создайте composer.json для локального пакета, например:
```
{
   "name": "localPackage/core",
   "version": "dev-master"
}
```
Вы также можете указать другие свойства и/или зависимости по мере необходимости.
Замените пакет с помощью файла composer.json в качестве корневого файла в archive.zip и поместите его там, где хотите.
В другом проекте/пакете, где вы хотите включить локальный пакет, добавьте локальное имя пакета в требуемый параметр, например
```
"localPackage/core": "dev-master"
```
Добавьте в параметр repositories следующее:
```
"repositories" : [
    {
        "type": "artifact",
        "url": "path/to/localPackage.zip"
    }
]
```

Теперь, если у вас есть локальный пакет на git, тогда нет необходимости архивировать пакет (в основном пропустить шаг 2), и вам просто нужно заменить URL в приведенном выше примере на path/to/localPackage/.git.

(Конец редактирования)

Теперь, чтобы ответить на более широкий вопрос: "Как мне разработать и включить пакет Composer?":

Определите структуру каталогов. Обычно это выглядит следующим образом:
```
/PackageRoot
    /src/PackageCore
    composer.json   ## this is your library’s composer.json
    LICENSE
```
и настройте свой composer.json.

Пример одного из моих файлов composer.json можно найти в http://pastebin.com/tyHT01Xg.
Загрузите его в Github и tag версии. Используйте Семантическое управление версиями (убедитесь, что вы исключили/проигнорировали каталог vendor при загрузке в Github).
Зарегистрируйте пакет с Packagist (после входа в систему).

Если вы отметили свою фиксацию как v1.0.0 (или аналогичную), это будет отображаться в вашей информационной панели Packagist для этого пакета.

Теперь, если все сделано правильно, вы должны иметь возможность использовать свою библиотеку в качестве зависимости в других проектах, добавив ее в composer.json этого проекта.

Ответ 2

Вместо создания нового репозитория вы можете указать композитору использовать любой локальный путь:

https://getcomposer.org/doc/05-repositories.md#path

Например, скажем, что у вас есть проекты PHP под ~/devel/projects

У вас может быть ваш основной проект в ~/devel/projects/main_project, а ваш "локальный пакет" в ~/devel/projects/local_package

Определите конфигурацию композитора для локального пакета. В ~/devel/projects/local_package/composer.json.

{
    "name": "your_vendor_id/your_local_package",
    ...
}

Затем вы можете редактировать ~/devel/projects/main_project/composer.json и ссылаться на свой локальный пакет через репозиторий путей:

"repositories": [
    {
        "type": "path",
        "url": "../local_package",
        "options": {
            "symlink": true
        }
    }
],
"require": {
    "your_vendor_id/your_local_package": "dev-master",
    ...
}

Дополнительная информация по этой ссылке (не написана мной, но есть хорошее объяснение на эту тему):

https://carlosbuenosvinos.com/working-at-the-same-time-in-a-project-and-its-dependencies-composer-and-path-type-repository/

Ответ 3

Кажется, что большинство ответов на эту тему не "знают". Я новичок в Composer, но эти ответы вводят в заблуждение. Вопрос можно просто сформулировать так: "Как я могу разработать композиторский пакет".

Да, вы можете использовать пользовательский репозиторий или загрузить незавершенный пакет и обновить его после каждого изменения. Это не является правильным решением или ответом на вопрос.

Это не поможет, что официальная документация Composer не указала этот аванс, но вы можете увидеть заголовок на Страница документации библиотек:

Каждый проект представляет собой пакет

Это очень важно понять

composer.json:

На предыдущей странице далее указывается:

Чтобы установить этот пакет, вам нужно указать ему имя. Вы делаете это, добавляя свойство name в composer.json
{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

В этом примере до сих пор у нас есть требуемый пакет, а теперь и имя. Обратите внимание на формат vendor/name.

Итак, теперь для автоматической загрузки наших собственных файлов, которые описаны на странице Основное использование.

{
    "autoload": {
        "psr-4": {"Acme\\": "src/"}
    }
}

Это приведет к автозагрузке файлов классов с именами в каталоге src/Acme.

На радость.

Установить/обновить

Установите или обновите пакет с помощью команды:

composer update

или

php composer.phar update

Это загрузит необходимые пакеты и создаст файл autoload.php

Структура нашего проекта должна выглядеть следующим образом:

src
    Acme
        Foo.php
vendor
    monolog
        ...
composer.json

Включая

Теперь для проверки.

Включить autoload.php

require_once 'path/to/project/vendor/autoload.php';

Предполагая, что Foo.php выглядит следующим образом:

<?php

namespace Acme;

class Foo {
    public static function bar(){
        return 'baz';
    }
}

?>

мы можем вызвать это из нашего script:

echo Acme\Foo::bar(); // baz

Пожалуйста, исправьте любую вводящую в заблуждение информацию, которую я, возможно, сказал. Это то, что кажется решением широкого популярного вопроса.

Ответ 4

Здесь приведен пример решений плюс мой собственный

опубликовать на упаковке

Поскольку вы еще не хотите публиковать, вы находитесь в разработке, это плохой вариант.

загрузить github

Возможно, вы не захотите публиковать источник в библиотеке github, не хотите платить за частное репо или иметь возможность использовать внешнюю службу облака (из-за политических или сетевых политик).

zip ваша библиотека

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

Загрузка на локальный git/svn repo на вашем компьютере.

Это приближается, но вам нужно будет делать обновление композитора каждый раз, когда вы меняете свою библиотеку и хотите протестировать реализацию вашего примера. Это имитирует постановки, но громоздко. Лично я рекомендую это решение, хотя оно не безмозгло.

Автозагрузка библиотеки напрямую (sortof делает то, что вы хотите)

Это взломать, но вы можете просто добавить:

{    
  "require": {
  },
  "autoload": {
    "psr-4": { 
      "yourlibnamespace": "D:\\Code\\yourlib\\src\\" 
    }
  }

}

Обратите внимание, что вам нужно будет скопировать + вставить раздел "require" из вашей библиотеки в вашу примерную реализацию. Измените 'yourlibnamespace' на пространство имен вашей библиотеки и "D:\Code\yourlib\src \" на ваш локальный путь к источнику вашей библиотеки.

Таким образом, любые изменения немедленно отражаются. Однако вы не будете использовать или полностью протестировать свой файл composer.json библиотеки. Если вы измените требование в своей библиотеке .json, он вообще не пройдет. Таким образом, он имеет некоторые большие недостатки, но делает то, что вы хотите, чтобы немедленно протестировать реализацию библиотеки с наименьшими возможными командами.

добавьте пример реализации непосредственно в дерево вашей библиотеки (рекомендуется)

Обычно у вас есть только src\и tests \, но у многих есть примеры, где вы можете найти примеры реализации. По мере разработки вашего приложения вы можете внести вклад в эти примеры реализации. Вы можете сделать это в локальном репозитории git/svn, и у вас есть преимущество в том, что вы получаете lib 'require', плюс пространство имен автоматически. Это лучший из всех миров. Я рекомендую этот метод.

Ответ 5

Может быть, добавит пользовательский репозиторий?

https://github.com/composer/composer/blob/master/doc/05-repositories.md

Вы можете легко создать локальный репозиторий git в своей библиотеке.

Конечно, если вы используете композитор для управления зависимостями, вы должны создавать свою библиотеку где-то еще и загружать ее поставщику/через композитор coz, это все, что я думаю.

Ответ 6

Чтобы сделать разработку более эффективной, я просто символизирую репозиторий разработки в каталог, который уже установил его.

Например, если /Code/project-1 требуется пакет, который в /Code/package-1, I:

Commit package-1 для GitHub (может быть даже закрытым).
Затем я расскажу project-1, чтобы установить его с помощью специализированного репозитория (см. другие ответы для ссылки на конфигурацию репозитория).
Как только он будет установлен, я символически привяжу /Code/project-1/vendor/developer/package-1 к /Code/package-1.

Таким образом, когда я вношу изменения в /Code/package-1, он сразу отражается в /Code/project-1.

Ответ 7

Это мой поток создания и разработки нового пакета Composer локально:

Создайте новый репозиторий для пакета на GitHub (просто пример)
Добавьте его в базу данных Composer (packagist.org).
Добавьте его в свой основной проект с помощью композитора. Здесь вы начинаете задаваться вопросом, как быстро применить исправления.
Клонировать его на вашей локальной машине где-то, вот где вы его разрабатываете.
Теперь, чтобы протестировать вашу локальную версию, добавьте инструкцию php require(), в которой вы загружаете соответствующие файлы классов. Автозагрузчик не загрузит загруженный через композитор, а ваш локальный.
Когда вы закончите исправление, удалите/закомментируйте инструкцию require, чтобы вернуться к использованию версии пакета для компоновщика.
Зафиксируйте все изменения, пометьте фиксацию и нажмите GitHub; перехватывает огонь, чтобы обновить Composer. Запустите обновление композитора в вашем основном проекте, пакет обновится до вашей локальной версии.

Это все еще не идеально, но он выполняет работу для небольших и средних пакетов.