Разработка пакета Laravel 5: с чего начать?
При создании этого вопроса Stackoverflow уже сказал, что это субъективный вопрос, который я задаю. Тем не менее, я думаю, что этот вопрос многие начинающие (пакетные) разработчики задавали себе в какой-то момент.
У меня есть несколько лет опыта работы с Laravel. И я дошел до того, что хочу создать Laravel на основе пакет. Я провел некоторое исследование, и куча информации, которую вы обнаружите, уже устарела.
У меня есть не один, а несколько вопросов на эту тему:
- Где хорошая отправная точка? Кажется, я не могу найти, с чего начать. Я прочитал документы и, честно говоря, я все еще в неведении.
- Рекомендуется сначала создать свой пакет как обычный проект, прежде чем создавать пакет из него?
- Где должен быть разработан пакет? Каково ваше рабочее место? Обычный проект Laravel? я прочел
workbenchбольше не? - Есть ли какие-нибудь рекомендуемые уроки, которые вы читали и нашли полезными?
Я искренне надеюсь, что на этот вопрос будут получены хорошие ответы, потому что текущие результаты поиска не такие, какими они должны быть. Конечно, не для таких красивых рамок, как Laravel.
Решение
Все, что вы необходимость знать это в документах, так, как это должно быть.
Кроме того: думайте, что пакет в первую очередь является пакетом Composer. Вы не только находитесь на / ограничены путем разработки пакетов Laravel, но на самом деле Composer, поскольку именно он контролирует их автозагрузку. Если пакет включает поставщиков услуг, фасады, виды Blade и т. Д., Он становится пакетом с интеграцией Laravel. Это соответствует причине, по которой верстак был удален: иметь Широкое PHP-решение.
Хорошей отправной точкой будет существующий проект, в идеале с хорошим набором вариантов использования для пакета.
По крайней мере, во время разработки приложения становится ясно, что можно или даже следует разделить на пакеты / библиотеки.
В качестве альтернативы создайте новый проект laravel и создайте четко определенные сценарии использования вокруг пакета.
Ниже приведен один из возможных способов разработки пакетов (как уже упоминалось, это субъективный вопрос), который позволяет как в процессе разработки, так и в дальнейшем устанавливать компоновщик.
Отказ от ответственности: Я не следовал никаким учебникам и не специально искал их, так как документы Composer и Laravel предоставляют все необходимое. Я только что посмотрел на другие пакеты Composer в vendor папка, которая заставляет меня верить, что это правильный путь. Следующее решение даже не связано с Laravel — я использую тот же подход при разработке модулей Zend Framework.
Заметка: Убедитесь, что пространство имен пакета не занято в packagist, если вы хотите опубликовать его там.
Настройте структуру папок, как можно найти в других пакетах композитора в lib или же packages папка в корне проекта.
lib/
my-namespace/
my-package/
config/
src/
Facades/
MyPackage.php
Support/
helpers.php
MyPackageServiceProvider.php
...
Добавьте пакет src папку (и дополнительные файлы для автозагрузки) в конфигурацию автозагрузки composer.json проекта laravel. (Увидеть Документы композитора для доступных вариантов)
"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 — таким образом можно разработать пакет во время использования, даже в нескольких разных проектах.
Другие решения
Других решений пока нет …