Создавая этот вопрос, Stackoverflow уже сказал, что это субъективный вопрос, который я задаю. Тем не менее, я думаю, что это вопрос, который многие начинающие (пакетные) разработчики задали себе в какой-то момент.
Сейчас у меня есть пару лет опыта работы с Laravel. И я пришел к тому моменту, когда хочу создать пакет на основе Laravel. Я провел некоторое исследование и тонну информации, которую вы обнаружите, что она уже устарела и устарела.
У меня нет ни одного, а несколько вопросов по этому вопросу:
workbench больше? Я искренне надеюсь, что этот вопрос получит хорошие ответы, потому что текущие результаты поиска не то, что они должны быть. Конечно, не для красивой структуры, такой как Laravel.
Все, что вам нужно знать, находится в документах , как и должно быть.
Кроме того: подумайте о пакете, который должен быть в основном пакетом Composer. Вы находитесь не только на пути развития пакетов Laravel, но и на самом деле Composer, поскольку это тот, который контролирует их автозагрузку. Если пакет включает в себя поставщиков услуг, фасадов, блейдов и т. Д., То он стал пакетом с интеграцией Laravel. Это соответствует той причине, что рабочий стол был удален: иметь широкое решение PHP .
Хорошей отправной точкой будет существующий проект, в идеале с хорошим набором вариантов использования для пакета. По крайней мере, во время разработки приложения становится ясно, что можно или даже нужно разделить на пакеты / библиотеки. В качестве альтернативы создайте новый проект laravel и создайте хорошо определенные варианты использования вокруг пакета.
Ниже приведен один из возможных способов разработки пакетов (как упоминалось в SO, это субъективный вопрос), который позволяет впоследствии разрабатывать как «in-project», так и компоновку.
Отказ от ответственности: я не следил за учебниками и не искал их специально, так как документы Composer и Laravel предоставляют все необходимое. Я просто посмотрел на другие пакеты Composer в папке vendor что заставило меня поверить, что это правильный способ. Следующее решение даже не связано с Laravel – я использую тот же подход при разработке модулей Zend Framework.
Примечание . Убедитесь, что пространство имен пакета не принято в пакете, если вы хотите его опубликовать.
Настройте структуру папок, которая может быть найдена в других пакетах композитора в папке lib или packages в корне проекта.
lib/ my-namespace/ my-package/ config/ src/ Facades/ MyPackage.php Support/ helpers.php MyPackageServiceProvider.php ...
Добавьте папку src пакета (и дополнительные файлы для автоматической загрузки) в конфигурацию автозагрузки компоновщика composer.json проекта laravel. (См . Документы Composer для доступных опций)
"autoload": { "files": [ "lib/my-namespace/my-package/src/Support/helpers.php" ], "psr-4": { "MyNamespace\\": "lib/my-namespace/my-package/src/" } },
Примечание. Папка my-namespace управляется версией в собственном репозитории. Поэтому папка lib может игнорироваться на уровне проекта.
Добавьте поставщиков услуг и фасадов в конфигурацию приложения Laravel, как указано в документах.
Разработайте и используйте пакет, как описано в документах, и смотрите в других пакетах Laravel.
composer dumpautoload каждый раз, когда приложение игнорирует недавно внесенные изменения в ваш пакет / библиотеку.
Если пакет предназначен для публичного доступа (например, github / packagist), он должен включать в себя минимум обычно ожидаемых артефактов программного обеспечения и в идеале следовать семантическому управлению версиями . Грубо описано в содержимом папки:
docs/ tests/ composer.json LICENSE readme.md
Примечание. Я обычно добавляю файл composer.json в корневой каталог / библиотеку в начале. Это заставляет меня четко представлять, что этот пакет предоставляет и не предоставляет.
Чтобы опубликовать пакет / отделить его от проекта, переместите связанные части автозагрузки из проекта в библиотеку composer.json и адаптируйте пути. Затем опубликуйте проект в packagist / собственный прокси Toran. Требовать пакет с --prefer-source – таким образом, можно разрабатывать пакет во время использования, даже в нескольких разных проектах.